How to solve OpenVPN errors after upgrading OpenSSL

I went on upgrading OpenVPN and OpenSSL on an old production system, but after restarting the service, the clients would not connect. There were two different problems a “CRL expired” error and after fixing that a “CRL signature failed” error.

CRL expired

The OpenVPN server logs were reporting:

Mon Nov  6 10:04:22 2017 TCP connection established with [AF_INET]192.168.100.1:19347
Mon Nov  6 10:04:23 2017 192.168.100.1:19347 TLS: Initial packet from [AF_INET]192.168.100.1:19347, sid=150b3618 b004e9a4
Mon Nov  6 10:04:23 2017 192.168.100.1:19347 VERIFY ERROR: depth=0, error=CRL has expired: C=IT, ST=PR, L=Parma, O=domain, OU=domain.eu, CN=user, name=user, emailAddress=info@stardata.it
Mon Nov  6 10:04:23 2017 192.168.100.1:19347 OpenSSL: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
Mon Nov  6 10:04:23 2017 192.168.100.1:19347 TLS_ERROR: BIO read tls_read_plaintext error
Mon Nov  6 10:04:23 2017 192.168.100.1:19347 TLS Error: TLS object -> incoming plaintext read error
Mon Nov  6 10:04:23 2017 192.168.100.1:19347 TLS Error: TLS handshake failed
Mon Nov  6 10:04:23 2017 192.168.100.1:19347 Fatal TLS error (check_tls_errors_co), restarting
Mon Nov  6 10:04:23 2017 192.168.100.1:19347 SIGUSR1[soft,tls-error] received, client-instance restarting

This is a common problem on older systems, the culprit is in the OpenSSL configuration used to generate the CRL, that is limited to just 30 days by default.

So, I had to regenerate my CRL after increasing the default_crl_days parameter in the ssl config to 180 (for our use case is more than enough), using:

$ openssl  ca  -gencrl  -keyfile keys/ca.key  \
               -cert keys/ca.crt  -out keys/crl.pem \
               -config easy-rsa/openssl-1.0.0.cnf

CRL signature failed

Due to the vulnerabilities found in MD5, this hashing routine has been disabled by default on modern SSL. Our certificates, though, were still using it, so the new error message (after fixing the CRL), became:

Mon Nov  6 10:14:40 2017 TCP connection established with [AF_INET]192.168.100.1:18463
Mon Nov  6 10:14:41 2017 192.168.100.1:18463 TLS: Initial packet from [AF_INET]192.168.100.1:18463, sid=13fdd1fe 5d82d4d6
Mon Nov  6 10:14:42 2017 192.168.100.1:18463 VERIFY ERROR: depth=0, error=CRL signature failure: C=IT, ST=PR, L=Parma, O=domain, OU=domain.eu, CN=user, name=user, emailAddress=info@stardata.it
Mon Nov  6 10:14:42 2017 192.168.100.1:18463 OpenSSL: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
Mon Nov  6 10:14:42 2017 192.168.100.1:18463 TLS_ERROR: BIO read tls_read_plaintext error
Mon Nov  6 10:14:42 2017 192.168.100.1:18463 TLS Error: TLS object -> incoming plaintext read error
Mon Nov  6 10:14:42 2017 192.168.100.1:18463 TLS Error: TLS handshake failed
Mon Nov  6 10:14:42 2017 192.168.100.1:18463 Fatal TLS error (check_tls_errors_co), restarting
Mon Nov  6 10:14:42 2017 192.168.100.1:18463 SIGUSR1[soft,tls-error] received, client-instance restarting

This one was trickier to solve. It turns out that you can re-enable MD5 as a workaround using two environment variables: NSS_HASH_ALG_SUPPORT=+MD5 and OPENSSL_ENABLE_MD5_VERIFY=1. In my case, I just added them to openvpn init script because the system is going to be decommissioned soon.

References

Advertisements