Error connecting using ECDSA certificates

[corrideat]

I attempted to replace my current OpenVPN RSA certificates with EC cryptography because of its greater strength at much smaller key sizes. However, I run into some connectivity issues, which I am certain are unrelated to configuration as it works just fine for RSA certificates.

I control both the server and the client, so I am including the minimal configuration I created to reproduce the issue below:

# SERVER
auth none
ca /etc/openvpn/ssl/ca.crt
cert /etc/openvpn/ssl/xxxx.crt
client-to-client
dev tun
dh dh4096.pem
ifconfig-pool-persist ipp.txt
keepalive 10 120
key /etc/openvpn/ssl/xxxx.key  # This file should be kept secret
max-clients 10
mute 20
persist-key
persist-tun
port 1194
proto tcp
server 172.16.54.0 255.255.255.0
status openvpn-status.log
tls-server
verb 4
 
 
# Client
auth none
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
client
dev tun
key client.pem
persist-key
persist-tun
proto tcp
remote 106.186.123.168 1194
nobind
verb 9
tls-client

My certificate looks like this:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: X (0xX)
    Signature Algorithm: ecdsa-with-SHA1
        Issuer: XXXX
        Validity
            Not Before: Jul  1 00:00:00 2015 GMT
            Not After : Jan  1 00:00:00 2022 GMT
        Subject: XXXXX
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (521 bit)
                pub: 
                    04:01:...
                ASN1 OID: secp521r1
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Cert Type: 
                SSL Server
            X509v3 Subject Key Identifier: 
                4D:66:B2:...
            X509v3 Authority Key Identifier: 
4

    Signature Algorithm: ecdsa-with-SHA1
         30:81:88:....

[corrideat]

Client Connection Log

[corrideat]

Server Connection Log

[Gert Döring]

To my uneducated eye, it looks like the server receives something it does not like, and closes the TCP socket - so the client gets "Connection reset" and retries. No idea why that might be, though... could you bump up the server log level a bit?

Handing the ticket to syzzer, because he understands EC crypto :)

[Steffan Karger]

Unfortunately, I do not see the problem in these logs.

A couple of questions:

• Are both client and server running git-master?
• Can you add a complete and higher-verbosity server log too? (--verb 9, like the client, is ok)
• Why on earth do you use 'auth none'. If you are looking for a secure setup, you are certainly not achieving that with this setting.

[corrideat]

Are both client and server running git-master?

Yes.

Can you add a complete and higher-verbosity server log too? (--verb 9, like the client, is ok)

Added.

Why on earth do you use 'auth none'. If you are looking for a secure setup, you are certainly not achieving that with this setting.

Because I didn't want the setting to interfere, as before I was using RSA-SHA256. However, I experimented with different values and I got the same results.

Note: if I swap the certificates/keys with RSA certificates (which I've been using before I decided to go with ECC, these connection issues go away. So, I'm thinking it's safe to say this is a TLS issue.)

[Steffan Karger]

Replying to corrideat:

Can you add a complete and higher-verbosity server log too? (--verb 9, like the client, is ok)

Added.

Thanks. Though these do not show any of the hints I was hoping to see (specifically, some openssl error). So at this point, there's just hunches. Have you tried using a different curve? If possible, try P-384, it is the one I did my tests with. Also, you could try using a larger certificate hash, at least SHA256.

Why on earth do you use 'auth none'. If you are looking for a secure setup, you are certainly not achieving that with this setting.

Because I didn't want the setting to interfere, as before I was using RSA-SHA256. However, I experimented with different values and I got the same results.

Good, just make sure to never use auth none in production. auth applies to digest used for the data channel, and if used, openvpn's tls-auth. Disabling tls-auth during tests wrt TLS makes sense, but disabling auth will not make a difference if tls-auth is not used.

Note: if I swap the certificates/keys with RSA certificates (which I've been using before I decided to go with ECC, these connection issues go away. So, I'm thinking it's safe to say this is a TLS issue.)

I sure seems that way, yes.

[Gert Döring]

So, how do we proceed with this?

[Steffan Karger]

This is working just fine on a number of setups I have here.

To figure out what is failing here, could you:

1. Post the client and server platforms and openssl versions
2. Provide a key/certificate test set (CA+client+server) that fails for you (just to be absolutely clear: this should obviously not be certs you would ever use).

That might help me reproduce.

[MichaelCowles]

SPAM

[Gert Döring]

since all we got in the last 3 years is a single SPAM *and* this is working for people, closing as "worksforme"