TLS hanshake failing with EC

jimdoe

I have been holding fire on setting up a new server with EC parameters to use my iOS devices, but having seen the flurry of updates lately for the iOS connect app, I decided it was about time to give it a go, so I went ahead and used Easy RSA to build a CA and server and client key pairs using EC.

However, I am running into a problem and for the life of me I can't figure out what it is. This issue only occurs when I try to connect to my server using the iOS OpenVPN Connect app.

2018-02-25 15:12:22 VERIFY FAIL -- The certificate is signed with an unacceptable key (eg bad curve, RSA too short). : depth=0

...

2018-02-25 15:12:22 Transport Error: mbed TLS: SSL read error : X509 - Certificate verification failed, e.g. CRL, CA or signature check failed
2018-02-25 15:12:22 EVENT: CERT_VERIFY_FAIL mbed TLS: SSL read error : X509 - Certificate verification failed, e.g. CRL, CA or signature check failed [ERR]

I can connect to the server using exactly the same ovpn config when using two different desktop OpenVPN apps, and a connection is estalished using EC corrrctely

Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit EC, curve: secp384r1

so it is definitely something to do with the iOS app. Can anyone shed any light on this? I have a feeling it's to with the use of mbed TLS on iOS compared with openssl on desktop, but beyond that I have no idea.

TinCanTech

jimdoe wrote VERIFY FAIL -- The certificate is signed with an unacceptable key (eg bad curve, RSA too short). : depth=0

You would do well to report this on your ticket:
https://community.openvpn.net/openvpn/ticket/1026

jimdoe

TinCanTech wrote
jimdoe wrote VERIFY FAIL -- The certificate is signed with an unacceptable key (eg bad curve, RSA too short). : depth=0
You would do well to report this on your ticket:
https://community.openvpn.net/openvpn/ticket/1026

Well I think they're separate issues. The issue I reported on my ticket was to do with the password field not appearing when the private key is encrypted (which it used to do on previous versions of the app). But I gave up on that issue, as there isn't really anything I can do on my end to make the password field appear, so I went ahead and used easyrsa to generate a completely new ca without any private key encryption on any of the key pairs, and so this problem is unrelated to my ticket.

jimdoe

Of course, if you think they're related, I can report it on the ticket, but as this was a different error and occurring with a completely different ca, I didn't think they were related.

ordex

are the key/certs embedded in the ovpn profile? or are you loading them via a .ovpn12?

ordex

another thing: if you are testing also with linux, could you please confirm if this also works when using OpenVPN+mbedTLS ? The latter is what the iOS app uses for its SSL backend, thus it would help understanding if there is something unsupported at the library layer or not.

jimdoe

ordex wrote are the key/certs embedded in the ovpn profile? or are you loading them via a .ovpn12?

It is happening with both options. First it was happening when I was using a cert and encrypted key loaded using a .ovpn12 file, but as it was not working, I thought the problem was with that. So I then made a new CA (and this time without encrypting the private keys), and tried it first using a .ovpn12 file, and then embedded into the .ovpn config file. Unfortunately the same error comes up on both though.

jimdoe

ordex wrote another thing: if you are testing also with linux, could you please confirm if this also works when using OpenVPN+mbedTLS ? The latter is what the iOS app uses for its SSL backend, thus it would help understanding if there is something unsupported at the library layer or not.

I have so far only tested it with macOS and Windows openvpn clients. Viscosity and Tunnelblick on the Mac, and Viscosity on Windows. All worked with exactly the same config files as when using the iOS app.

I can try testing it on a Linux VM tomorrow, but I have never used mbedTLS before so it might take some getting used to.

jimdoe

jimdoe wrote
ordex wrote another thing: if you are testing also with linux, could you please confirm if this also works when using OpenVPN+mbedTLS ? The latter is what the iOS app uses for its SSL backend, thus it would help understanding if there is something unsupported at the library layer or not.
I have so far only tested it with macOS and Windows openvpn clients. Viscosity and Tunnelblick on the Mac, and Viscosity on Windows. All worked with exactly the same config files as when using the iOS app.

I can try testing it on a Linux VM tomorrow, but I have never used mbedTLS before so it might take some getting used to.

So I installed OpenVPN using the mbedTLS library on a Linux VM, and have tested the .ovpn file with the embedded cert and key.
It doesn't work, so I guess it is indeed something to do with the mbedTLS library.
On the Linux log I am getting the following errors

Mon Feb 26 13:02:44 2018 VERIFY ERROR: depth=0, subject=CN=iOSServer2: The certificate is signed with an unacceptable key (eg bad curve, RSA too short).
Mon Feb 26 13:02:44 2018 TLS_ERROR: read tls_read_plaintext error: X509 - Certificate verification failed, e.g. CRL, CA or signature check failed
Mon Feb 26 13:02:44 2018 TLS Error: TLS object -> incoming plaintext read error
Mon Feb 26 13:02:44 2018 TLS Error: TLS handshake failed
Mon Feb 26 13:02:44 2018 SIGUSR1[soft,tls-error] received, process restarting

This is the exact same .ovpn file that works fine when using openSSL on the Mac and Windows openVPN clients.

ordex

Yeah, so it looks like you are using something that is not yet supported by mbedTLS (maybe the curve you are using? I can only wildly guess).

Could you please post the output of:

openssl x509 -in servercertificate.crt -text -noout

jimdoe

ordex wrote Yeah, so it looks like you are using something that is not yet supported by mbedTLS (maybe the curve you are using? I can only wildly guess).

Could you please post the output of:
openssl x509 -in servercertificate.crt -text -noout
?

Sure.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            d4:04:6a:42:7d:c4:79:2d:20:aa:6c:d0:34:24:2c:d3
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=VPNServer2
        Validity
            Not Before: Feb 26 12:28:01 2018 GMT
            Not After : Feb 24 12:28:01 2028 GMT
        Subject: CN=Server
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
            EC Public Key:
                pub: 
                    04:7b:09:30:d2:e4:56:b0:4a:da:b9:89:eb:ae:79:
                    2a:fb:d7:6b:81:a0:49:06:aa:cc:a7:97:4d:a4:0a:
                    c2:8a:af:cf:d9:5e:90:d3:df:bd:9e:82:cc:9b:64:
                    e6:95:e1:33:bf:ca:0b:22:84:37:2c:9f:79:b5:78:
                    a1:7d:e6:0e:ac:71:6b:18:7d:fd:f0:81:7e:73:a9:
                    75:92:3c:2c:fd:0e:ed:dc:05:6e:d2:8e:39:14:1f:
                    e7:ee:51:f7:bf:68:29
                ASN1 OID: secp384r1
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Subject Key Identifier: 
                25:D1:6F:38:10:6A:01:07:18:60:CA:98:DD:08:03:48:20:F0:EE:38
            X509v3 Authority Key Identifier: 
                keyid:BA:08:86:D0:8E:E7:79:8D:B5:8E:41:4A:FF:1E:17:16:39:37:B1:45
                DirName:/CN=VPNServer2
                serial:AD:4D:8D:F9:22:F6:74:8C

            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
            X509v3 Subject Alternative Name: 
                DNS:Server
    Signature Algorithm: sha256WithRSAEncryption
        77:70:85:83:fc:cc:fe:4c:1f:b3:57:70:b9:7a:a4:0d:8c:d7:
        05:88:29:c5:2b:c1:59:82:a8:f5:7f:90:35:d4:df:c0:19:c5:
        42:5c:74:57:2f:f2:d0:29:ce:cf:81:43:33:d1:4e:20:c5:4f:
        23:8d:e1:c7:76:e4:97:0b:f0:52:b5:9a:90:8c:da:85:e8:d0:
        98:ec:6a:43:92:1b:7b:f2:08:28:ab:be:76:ec:c5:4d:d3:96:
        04:58:3f:d2:18:cb:15:99:38:2f:96:1e:de:17:86:78:9f:5e:
        29:51:4b:ee:ae:49:03:d1:5a:ed:9d:1b:dc:1f:94:0a:7c:c7:
        19:11:68:14:ac:3f:a1:27:41:d5:3d:ca:90:77:3f:f4:64:78:
        fc:07:e2:9a:5d:85:de:8b:bd:a9:47:10:69:4e:01:d3:6f:2c:
        9f:99:ec:da:f1:20:3c:4b:11:15:30:59:cd:a7:39:ac:fa:c4:
        e5:3f:43:13:92:11:8e:73:bd:04:4c:b8:a4:5a:1b:b2:f6:08:
        60:3e:35:82:44:d2:50:bf:00:44:38:e5:88:10:db:11:d3:40:
        a2:52:41:ac:a7:0b:04:70:f4:6e:58:44:7b:74:df:87:01:e5:
        5f:52:ca:6d:1b:14:f0:80:d4:9e:42:91:cb:38:9f:28:e9:f9:
        2a:12:f1:fc

I can't figure out what I did that wouldn't be supported. I didn't do anything special when creating the certificates, just used the standard EC settings using EasyRSA.

ordex

I just checked my testing EC PKI and my server certificate is signed with a different algorithm:

Signature Algorithm: ecdsa-with-SHA256

Which actually makes more sense since we are not using RSA. This doesn't mean your certificate is "not correct", but only that it is using an interesting combinations of algorithms (I believe).

Did you re-create your CA using EC as well before creating the certs?

jimdoe

ordex wrote I just checked my testing EC PKI and my server certificate is signed with a different algorithm:
Signature Algorithm: ecdsa-with-SHA256
Which actually makes more sense since we are not using RSA. This doesn't mean your certificate is "not correct", but only that it is using an interesting combinations of algorithms (I believe).

Did you re-create your CA using EC as well before creating the certs?

Interesting! Well, we're definitely starting to get to the bottom of this at least.
Yes, each time I created a new cert and key pair, I began by using a whole new CA, using the init-pki command and then build-ca command on EasyRSA.
I'm wondering if the difference between the output of ours is because I used a password for the build-ca command, and so the CA needs to be unencrypted when building a new client and server cert/key pair?

ordex

I am not sure about that, because once the CA is unencrypted it is like any other one, so it should affect the way you create certs.

May you please run the same command on the ca.crt file? I am curious to see how it looks like.

jimdoe

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ad:4d:8d:f9:22:f6:74:8c
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=VPNServer2
        Validity
            Not Before: Feb 26 12:27:26 2018 GMT
            Not After : Feb 24 12:27:26 2028 GMT
        Subject: CN=VPNServer2
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:a5:e3:d0:8d:e8:6c:87:f1:8a:f0:35:d8:3a:7a:
                    91:06:65:97:77:ec:ba:bc:db:33:90:de:dd:5c:27:
                    e7:ce:c8:11:ec:09:5a:1a:8c:4f:eb:fe:e9:f6:de:
                    5a:ad:27:20:c1:ee:a7:cd:22:d3:7f:e5:ab:f5:c6:
                    6c:25:2e:4e:23:b9:b1:69:72:c0:27:ba:47:42:16:
                    13:1e:fd:03:af:82:46:94:47:2d:62:0f:93:f3:bb:
                    a9:4e:83:fb:31:28:09:4c:0d:95:12:fa:cc:6e:97:
                    10:d0:9c:3a:d7:41:58:bc:1d:c3:5a:34:b6:90:b7:
                    55:97:65:9e:9c:71:dd:7e:bb:e3:11:33:58:a7:8d:
                    c1:ef:b7:63:3c:25:28:2e:fb:19:e1:55:07:4c:b1:
                    ef:7d:ba:ec:64:fe:2b:ee:56:39:3a:d0:c7:91:7e:
                    68:96:e2:64:29:09:29:6f:8d:f4:cf:63:12:55:1a:
                    f5:eb:04:be:9a:a8:3d:34:3a:91:c0:f4:fe:0f:08:
                    93:69:2e:f4:57:77:59:56:44:2d:53:4b:1d:c6:a4:
                    79:83:6d:48:91:b9:84:b7:ba:d6:a5:ea:2c:87:fc:
                    67:0c:c3:7c:25:76:54:e4:a3:87:01:49:41:3f:e9:
                    e0:6d:58:ae:0d:8d:eb:a9:4d:db:91:82:28:ae:8a:
                    7f:31
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                BA:08:86:D0:8E:E7:79:8D:B5:8E:41:4A:FF:1E:17:16:39:37:B1:45
            X509v3 Authority Key Identifier: 
                keyid:BA:08:86:D0:8E:E7:79:8D:B5:8E:41:4A:FF:1E:17:16:39:37:B1:45
                DirName:/CN=VPNServer2
                serial:AD:4D:8D:F9:22:F6:74:8C

            X509v3 Basic Constraints: 
                CA:TRUE
            X509v3 Key Usage: 
                Certificate Sign, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption
        25:e0:df:2c:41:95:64:8c:a2:bd:91:80:f4:e7:5f:2c:bc:ca:
        d8:f9:35:73:81:40:3d:91:b5:5e:f4:f8:c0:42:e6:8d:85:bd:
        f4:79:31:1f:62:11:82:cd:92:ca:71:2c:33:aa:6d:3c:f9:17:
        28:1e:ba:42:51:33:3c:e7:7c:40:b0:ab:8e:10:d7:08:94:80:
        dc:55:84:00:dc:11:29:ce:89:fa:93:e0:a5:41:04:00:cd:17:
        d8:34:e8:f8:75:16:31:64:6c:6c:90:67:bc:db:57:66:d5:ed:
        67:66:62:a8:29:f9:7e:32:f7:18:0a:26:bf:38:f1:1b:29:fc:
        ea:4b:a9:69:b6:b0:f2:15:4c:55:7d:2c:7f:8c:fe:26:21:9b:
        06:bc:e3:69:3b:e4:68:ab:74:04:7a:e2:cb:d3:17:85:96:7a:
        8d:ab:c6:af:b7:87:24:8b:9a:3d:de:36:d8:8f:55:93:ec:42:
        bb:34:7b:af:7b:ff:ea:10:f9:b4:a7:57:50:02:79:0a:87:c0:
        22:fa:b7:80:f5:8a:40:eb:4b:d5:88:4a:e1:ba:30:97:6a:c3:
        0c:9f:24:88:56:35:90:88:ed:78:3a:51:86:8f:5c:76:56:7b:
        fa:2a:b5:57:e0:8a:c3:e5:5a:cb:01:43:cd:99:e3:07:0e:60:
        76:c6:90:b1

OK, so I'm guessing this is because EasyRSA is using RSA 2048 for the CA then? I have no idea why that is. I have checked my EasyRSA vars file and I have all RSA options commented out and only the ec options are uncommented.

ordex

yes, looks like that. The CA is an RSA cert thus it's not signing new certs using ecdsa.
That is probably what is upsetting mbedTLS during the server certificate verification.

I also created my EC PKI with easyRSA, therefore there must be a way to avoid RSA at all (can't remember right now).

ordex

just had a quick look at the code and it seems that you should only need to ensure EASYRSA_ALGO is set to "ec".

jimdoe

ordex wrote just had a quick look at the code and it seems that you should only need to ensure EASYRSA_ALGO is set to "ec".

That's what I have

# 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

Do you think I need to file a bug on the EasyRSA github?

ordex

That's an option, or try to ask somebody else on IRC in the #openvpn channel.
At least we have clarified where the problem is coming from.

jimdoe

ordex wrote That's an option, or try to ask somebody else on IRC in the #openvpn channel.
At least we have clarified where the problem is coming from.

Very true! Thanks for your help in getting to the bottom of this strange behaviour! 🙂
One question though: why is it that the OpenVPN desktop clients that use OpenSSL are able to connect using the same CA and client/key pairs, and report that ECDSA and ECDHE are being used?