Closed eccgecko closed 5 years ago
Can you try with the latest v3.0.5 code? I think this may have been fixed in commits made yesterday. Also, please note that v3.0.5 is not production ready.
I’ll fix GitHub so it defaults to v3.0.4.
Eric
On Feb 27, 2018, at 04:51:17, eccgecko notifications@github.com wrote:
I've been having an issue with EasyRSA 3.0.5 that is causing an interoperability issue when using mbedTLS.
When creating a new CA using EC, the CA is being signed with RSA 2048, not ecdsa.
I have three CAs, one created using 3.0.0, one using 3.0.3, and one using 3.0.5.
On the first 2, the CAs reports Signature Algorithm: ecdsa-with-SHA256 Public Key Algorithm: id-ecPublicKey
However, with the CA created using 3.0.5, it instead reports Signature Algorithm: sha256WithRSAEncryption Public Key Algorithm: rsaEncryption
I am using the same settings in the vars file regarding EC
`# Choose a size in bits for your keypairs. The recommended value is 2048. Using
2048-bit keys is considered more than sufficient for many years into the
future. Larger keysizes will slow down TLS negotiation and make key/DH param
generation take much longer. Values up to 4096 should be accepted by most
software. Only used when the crypto alg is rsa (see below.)
set_var EASYRSA_KEY_SIZE 2048
The default crypto mode is rsa; ec can enable elliptic curve support.
Note that not all software supports ECC, so use care when enabling it.
Choices for crypto alg are: (each in lower-case)
rsa
ec
set_var EASYRSA_ALGO ec
Define the named curve, used in ec mode only:
set_var EASYRSA_CURVE secp384r1`
Is there a reason this is the case on 3.0.5? It is causing an issue when using OpenVPN built using mbedTLS (I am also reporting a bug to mbedTLS because OpenVPN using OpenSSL can connect using the same CA cert/key pairs just fine)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenVPN/easy-rsa/issues/196, or mute the thread https://github.com/notifications/unsubscribe-auth/ABt4P1ujYF58iAHPrL_NnHPBBJ1AfaERks5tY94lgaJpZM4SUueb.
Yeah I didn't realise until I was told today that I wasn't using the release branch, so that was my bad.
I have created a new CA with the latest 3.0.5 code and it certainly seems to be an improvement. The signature algorithm for the CA is now using ecdsa, so that's good. However, it seems that on 3.0.4 it uses ecdsa-with-SHA256, whereas on 3.0.5 it uses ecdsa-with-SHA1. Not that SHA1 is inherently unsafe, but it does seem like it is a regression, and it is probably safer for the default to be SHA256 where possible.
When I get some time tomorrow I will create a new openvpn server using the new 3.0.5 CA and client/key pairs and will report on whether mbedTLS can connect with the ecdsa signed CA.
I've just tried this on 9bd3241a (HEAD on v3.0.5 branch at the time of this writing) and could not reproduce this.
The vars
file used was a copy of vars.example
, the only differences being:
set_var EASYRSA_ALGO ec
set_var EASYRSA_CURVE secp384r1
After that I executed the following commands:
$ ./easyrsa init-pki
[... cut output ...]
$ ./easyrsa build-ca
[... cut output ...]
$ openssl x509 -in pki/ca.crt -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
f7:be:bf:1b:62:18:2e:2d
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN = Easy-RSA CA
Validity
Not Before: Mar 5 15:22:42 2018 GMT
Not After : Mar 2 15:22:42 2028 GMT
Subject: CN = Easy-RSA CA
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:d2:21:c1:77:2a:57:1e:f3:41:74:07:52:ab:d4:
be:28:d9:29:7b:a7:89:30:5d:70:31:c6:c8:8b:b3:
0a:36:38:f8:5c:6b:1a:f8:e7:3c:87:19:b5:bb:9b:
c7:fe:61:a9:48:bf:ef:e4:eb:3f:49:fd:8f:f8:c8:
be:65:72:cc:5a:6b:f9:b4:fc:a2:0c:31:25:e4:86:
53:cb:84:45:37:4b:67:8a:40:89:74:b7:2d:86:8d:
e7:ca:4d:5f:c0:b3:98
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Subject Key Identifier:
88:BF:97:E1:0C:BE:2C:76:B2:F9:A9:AD:B4:14:33:D2:6F:6C:F6:7B
X509v3 Authority Key Identifier:
keyid:88:BF:97:E1:0C:BE:2C:76:B2:F9:A9:AD:B4:14:33:D2:6F:6C:F6:7B
DirName:/CN=Easy-RSA CA
serial:F7:BE:BF:1B:62:18:2E:2D
X509v3 Basic Constraints:
CA:TRUE
X509v3 Key Usage:
Certificate Sign, CRL Sign
Signature Algorithm: ecdsa-with-SHA256
30:65:02:30:4b:fc:5c:5c:e0:5e:a5:22:64:b5:5f:e4:5a:f3:
7f:94:6d:97:34:7f:6b:5f:f8:5b:5e:20:35:0c:10:64:d2:b2:
61:37:2b:09:a1:fe:41:d6:ac:79:51:14:58:c3:d4:bc:02:31:
00:d9:17:55:35:c3:aa:9d:16:37:ea:1d:9f:4c:12:b5:2e:b3:
00:b6:27:b0:34:2c:77:ec:33:a5:01:71:50:ae:85:14:e0:eb:
36:80:7e:99:01:86:85:e9:22:bf:46:2d:0c
As you can see, the signature algorithm is ecdsa-with-SHA256
. Can you please check if the issue still persists for you on the commit I mentioned?
Ok, so I performed exactly the same actions as you, and on the same commit.
For some reason, on MacOS Sierra 10.12.6, the problem persists, and the latest 3.0.5 commit is signing the CA using ecsda-with-SHA1
However, on Linux Ubuntu 17.10, the output is the same as yours, and it signs using ecdsa-with-SHA256
What's interesting is that on MacOS 10.12.6, EasyRSA 3.0.4 signs EC CAs with ecdsa-with-SHA256
What is the difference in versions of OpenSSL?
Eric F Crist
On 2018-03-05 11:43, eccgecko wrote:
Ok, so I performed exactly the same actions as you, and on the same commit.
For some reason, on MacOS Sierra 10.12.6, the problem persists, and the latest 3.0.5 commit is signing the CA using ecsda-with-SHA1
However, on Linux Ubuntu 17.10, the output is the same as yours, and it signs using ecdsa-with-SHA256
What's interesting is that on MacOS 10.12.6, EasyRSA 3.0.4 signs EC CAs with ecdsa-with-SHA256
-- You are receiving this because you commented. Reply to this email directly, view it on GitHub [1], or mute the thread [2].
*
Links:
[1] https://github.com/OpenVPN/easy-rsa/issues/196#issuecomment-370501874 [2] https://github.com/notifications/unsubscribe-auth/ABt4P6QMsmPqsdjpqQD_JMx77xRXxCImks5tbXlHgaJpZM4SUueb
Ah, that's it. I am sorry - I completely forgot that I edited the openssl directory on the 3.0.4 vars to use an openssl binary contained in the latest version of a Homebrew installed LibreSSL package. My mistake. I see that adding that directory to the 3.0.5 vars fixes the SHA1 issue.
I believe that if you run EasyRSA on MacOS without having a newer OpenSSL version installed via brew, and the openssl directory linked in the vars file, then this problem will continue, as Apple have deprecated OpenSSL in favour of their own managed crypto libraries, so the version of OpenSSL installed in /usr/bin/openssl is quite old (0.9.8zh).
The lastest version of MacOS uses LibreSSL, which is problematic due to some restrictions on environment variables.
This issue should be resolved release v3.0.5, with added support for LibreSSL.
I understand this is an old thread; however, I came across the same issue recently using easy-rsa 3.0.8 and openssl 3.0.2 under Ubuntu 22.04. I was following a howto on DitialOcean, which recommended creating symlnks to /usr/share/easy-rsa vs "copying the easy-rsa package files into your PKI directory". Unfortunately, the easyrsa script can NOT be a symbolic link or for some reason, the resulting CA will be created using SHA256 RSA, even if you specify otherwise in the vars file. As such, I copied the easyrsa script symlink, creating a regular file (i.e., easyrsa.sh) and used that script over the symlink, and VOILA, all good!
I've been having an issue with EasyRSA 3.0.5 that is causing an interoperability issue when using mbedTLS.
When creating a new CA using EC, the CA is being signed with RSA 2048, not ecdsa.
I have three CAs, one created using 3.0.0, one using 3.0.3, and one using 3.0.5.
On the first 2, the CAs report
Signature Algorithm: ecdsa-with-SHA256 Public Key Algorithm: id-ecPublicKey
However, with the CA created using 3.0.5, it instead reports
Signature Algorithm: sha256WithRSAEncryption Public Key Algorithm: rsaEncryption
I am using the same settings in the vars file regarding EC
`#set_var EASYRSA_KEY_SIZE 2048
set_var EASYRSA_ALGO ec
set_var EASYRSA_CURVE secp384r1`
Is there a reason this is the case on 3.0.5? It is causing an issue when using OpenVPN built using mbedTLS (I am also reporting a bug to mbedTLS because OpenVPN using OpenSSL can connect using the same CA cert/key pairs just fine)