| 192 |
- |
1 |
Upgrading to Easy-RSA 3 from earlier versions
|
|
|
2 |
=========
|
|
|
3 |
|
|
|
4 |
People upgrading to Easy-RSA 3 from a 2.x version should note some important
|
|
|
5 |
changes starting with version 3. For a better overview of version 3 in general,
|
|
|
6 |
see the Readme in the doc/ directory.
|
|
|
7 |
|
|
|
8 |
List of important changes
|
|
|
9 |
----
|
|
|
10 |
|
|
|
11 |
* nsCertType extensions are no longer included by default. Use of such
|
|
|
12 |
"Netscape" attributes have been deprecated upstream and their use is
|
|
|
13 |
discouraged. Configure `EASYRSA_NS_SUPPORT` in vars if you want to enable
|
|
|
14 |
this legacy behavior.
|
|
|
15 |
|
|
|
16 |
Notably, this is important for OpenVPN deployments relying on the
|
|
|
17 |
`--ns-cert-type` directive. Either have OpenVPN use the preferred
|
|
|
18 |
`--remote-cert-tls` option, or enable legacy NS extensions.
|
|
|
19 |
|
|
|
20 |
* The default request Subject (or DN, Distinguished Name) includes just the
|
|
|
21 |
commonName. This is more suitable for VPNs and environments that don't wish
|
|
|
22 |
to include info about the Country/State/City/Org/OU in certs. Configure
|
|
|
23 |
`EASYRSA_DN` in vars if you want to enable the legacy behavior.
|
|
|
24 |
|
|
|
25 |
* The 3.0 release lacks PKCS#11 (smartcard/token) support. This is anticipated
|
|
|
26 |
to be supported in a future point-release to target each platform's need.
|
|
|
27 |
|
|
|
28 |
* The -utf8 option has been added for all supported commands. This should be
|
|
|
29 |
backwards compatible with ASCII strings.
|
|
|
30 |
|
|
|
31 |
* The default private key encryption has been changed from 3des to aes256.
|
|
|
32 |
|
|
|
33 |
|
|
|
34 |
Some new concepts
|
|
|
35 |
----
|
|
|
36 |
|
|
|
37 |
Easy-RSA 3 has some new concepts compared to the prior v2 series.
|
|
|
38 |
|
|
|
39 |
### Request-Import-Sign workflow
|
|
|
40 |
|
|
|
41 |
v3 is now designed to support keypairs generated on the target system where
|
|
|
42 |
they will be used, thus improving security as no keys need to be transferred
|
|
|
43 |
between hosts. The old workflow of generating everything in a single PKI is
|
|
|
44 |
still supported as well.
|
|
|
45 |
|
|
|
46 |
The recommended workflow when using Easy-RSA as a CA is to import requests,
|
|
|
47 |
sign them, and return the issued & CA certs. Each requesting system can use
|
|
|
48 |
Easy-RSA without a CA to generate keypairs & requests.
|
|
|
49 |
|
|
|
50 |
### "Org"-style DN flexibility
|
|
|
51 |
|
|
|
52 |
When using Easy-RSA in the "org" DN mode, it is no longer required to match
|
|
|
53 |
some of the field values. This improves flexibility, and enables easier remote
|
|
|
54 |
generation as the requester doesn't need to know the CA's values in advance.
|
|
|
55 |
|
|
|
56 |
Previously in v2, the Country, State, and Org values all had to match or a
|
|
|
57 |
request couldn't be signed. If you want the old behavior you can change the
|
|
|
58 |
OpenSSL config to require it or simply look over the DN at signing time.
|