EC CAs being signed with RSA

[eccgecko]

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)

[ecrist]

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.

[eccgecko]

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.

[Antagonym]

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?

[eccgecko]

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

[ecrist]

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

[eccgecko]

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).

[ecrist]

The lastest version of MacOS uses LibreSSL, which is problematic due to some restrictions on environment variables.

[ecrist]

This issue should be resolved release v3.0.5, with added support for LibreSSL.

[MoultonLava]

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!