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. [code]2018-02-25 15:12:22 VERIFY FAIL -- The certificate is signed with an unacceptable key (eg bad curve, RSA too short). : depth=0[/code] ... [code]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][/code] 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 [code]Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit EC, curve: secp384r1[/code] 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.

[quote=jimdoe post_id=77114 time=1519576340 user_id=42070] VERIFY FAIL -- The certificate is signed with an unacceptable key (eg bad curve, RSA too short). : depth=0 [/quote]You would do well to report this on your ticket: https://community.openvpn.net/openvpn/ticket/1026

[quote=TinCanTech post_id=77115 time=1519578323 user_id=37053] [quote=jimdoe post_id=77114 time=1519576340 user_id=42070] VERIFY FAIL -- The certificate is signed with an unacceptable key (eg bad curve, RSA too short). : depth=0 [/quote]You would do well to report this on your ticket: https://community.openvpn.net/openvpn/ticket/1026 [/quote] 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.

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.

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

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.

[quote=ordex post_id=77136 time=1519606819 user_id=39103] are the key/certs embedded in the ovpn profile? or are you loading them via a .ovpn12? [/quote] 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.

[quote=ordex post_id=77137 time=1519607162 user_id=39103] 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. [/quote] 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.

[quote=jimdoe post_id=77139 time=1519607607 user_id=42070] [quote=ordex post_id=77137 time=1519607162 user_id=39103] 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. [/quote] 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. [/quote] 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 [code]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[/code] This is the exact same .ovpn file that works fine when using openSSL on the Mac and Windows openVPN clients.

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: [code]openssl x509 -in servercertificate.crt -text -noout[/code] ?

[quote=ordex post_id=77170 time=1519696047 user_id=39103] 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: [code]openssl x509 -in servercertificate.crt -text -noout[/code] ? [/quote] Sure. [code]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[/code] 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.

TLS hanshake failing with EC

ordex

ECDSA/ECDHE is used because the certs represent proper priv/pub EC keys. The fact that the cert is signed with RSA does not affect the algorithm being used later.

If you want, you could file a ticket to mbedTLS on GitHub reporting what we have found out. They may consider it a bug since it creates an "interoperability" issue.

jimdoe

Yeah, sure, I can do that.
I'm curious, what version of EasyRSA are you using? And what is the output for your CA when you use the same command?

ordex

last time I created the EC PKI with easyRSA from the master branch which I think was 3.0.3 with a bunch of patches at that time.
Sure, my output is:

$ openssl x509 -in ca.crt -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            a3:46:d7:8c:e2:7a:b7:0e
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=Easy-RSA CA
        Validity
            Not Before: Dec 15 09:42:30 2017 GMT
            Not After : Dec 13 09:42:30 2027 GMT
        Subject: CN=Easy-RSA CA
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub: 
                    04:31:a7:4f:dc:21:69:16:51:f8:e8:dd:2f:9a:aa:
                    c3:1c:33:aa:89:d2:63:ec:85:b7:0f:64:a3:c2:54:
                    6f:a2:d2:ed:8f:68:55:fc:cd:6d:e7:fa:1a:0d:0a:
                    70:db:47:55:91:6d:f1:3b:08:c4:cc:f3:ea:5d:81:
                    cb:60:91:75:d8:41:24:14:cc:5c:57:6e:df:c5:71:
                    34:52:63:1a:be:7a:5a:bf:87:35:f2:92:99:7d:8e:
                    08:69:f7:25:5a:96:7f
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                73:AC:E8:3E:1D:FD:24:BF:AF:8F:9F:ED:73:6E:30:06:D9:AF:4F:95
            X509v3 Authority Key Identifier: 
                keyid:73:AC:E8:3E:1D:FD:24:BF:AF:8F:9F:ED:73:6E:30:06:D9:AF:4F:95
                DirName:/CN=Easy-RSA CA
                serial:A3:46:D7:8C:E2:7A:B7:0E

            X509v3 Basic Constraints: 
                CA:TRUE
            X509v3 Key Usage: 
                Certificate Sign, CRL Sign
    Signature Algorithm: ecdsa-with-SHA256
         30:65:02:30:5a:c1:25:57:49:58:f3:29:59:bc:44:a9:e9:74:
         4f:85:d8:ec:72:06:2f:07:21:92:95:ce:c9:ff:42:6f:94:0a:
         f0:32:d3:77:e0:95:f1:d2:81:7c:e0:44:3a:f9:d0:30:02:31:
         00:d1:d5:06:ab:74:57:2e:fa:b6:14:d7:61:57:2f:89:f2:18:
         01:8e:8a:84:41:b3:04:b9:39:df:12:95:4e:de:fc:82:e7:b1:
         78:c7:6f:5d:b1:77:97:ba:b8:43:67:d0:48

now that I look at it, I see I also have an additional:

NIST CURVE: P-384

But that attribute shouldn't make a difference, I think.

ordex

feel free to report here the issue #, should you decide to open one at mbed TLS.

jimdoe

I think it might be a bug with EasyRSA. For this batch I used EasyRSA 3.0.5, whereas before I was using the master branch of EasyRSA, which I can see was on 3.0.0 and 3.0.3 for each respective CA I built at the time. I have checked those other server CAs using your command, and all the CAs made with each of the older EasyRSAs show that ec was used for signing the CA. I shall report it to the EasyRSA github.

I shall also report the interoperability issue to the mbedTLS github too and report the ticket number here.

Thanks again for all your help.

jimdoe

ordex wrote feel free to report here the issue #, should you decide to open one at mbed TLS.

Reported to mbedTLS GitHub with issue number #1411 https://github.com/ARMmbed/mbedtls/issues/1411

ordex

I was just told that easyRSA 3.0.5 has not been released yet but only exists in git. Maybe you should use a stable/released version and recreate the PKI 🙂

jimdoe

ordex wrote I was just told that easyRSA 3.0.5 has not been released yet but only exists in git. Maybe you should use a stable/released version and recreate the PKI 🙂

Ah ha! Really? :lol: You know, I was actually wondering why the version I downloaded this time was called EasyRSA-3.0.5 when all the times I previously downloaded it it was called EasyRSA-Master. Certainly makes sense why this would suddenly change. My mistake for accidentally downloading a test branch. I'm going to start again using the master branch and will let you know the reslts

TinCanTech

In fact, you really want a release version:
https://github.com/OpenVPN/easy-rsa/releases

But testing the development version is also useful :mrgreen:

jimdoe

TinCanTech wrote In fact, you really want a release version:
https://github.com/OpenVPN/easy-rsa/releases

But testing the development version is also useful :mrgreen:

Now I'm just embarrassed that I've been downloading the master build naively thinking that was the release build! :oops: 🙂

Thought I would just follow up that I went back to basics, built a whole new CA using the release of EasyRSA (3.0.4), and I am happy to report my server is now up and running and my iOS clients can connect to it using ECDSA and ECDHE 😃 Thanks for all your help ordex.

I reported this to EasyRSA github with issue #196 https://github.com/OpenVPN/easy-rsa/issues/196. Apparently it has now been fixed by commits made yesterday, but I haven't had a chance to test it out yet.

« Previous Page