Expired CRLs will prevent clients from re-connecting

[kylemanna]

I encountered an error with an old CRL from a long time ago that prevents clients from connecting

May 30 12:28:53 test1 docker:  Tue May 30 19:28:53 2017 1.2.3.4:55195 TLS: Initial packet from [AF_INET]1.2.3.4:55195, sid=50cd0150 294bdcea
May 30 12:28:53 test1 docker:  Tue May 30 19:28:53 2017 1.2.3.4:55195 VERIFY ERROR: depth=0, error=CRL has expired: CN=someserver
May 30 12:28:53 test1 docker:  Tue May 30 19:28:53 2017 1.2.3.4:55195 OpenSSL: error:140360B2:SSL routines:ACCEPT_SR_CERT:no certificate returned
May 30 12:28:53 test1 docker:  Tue May 30 19:28:53 2017 1.2.3.4:55195 TLS_ERROR: BIO read tls_read_plaintext error
May 30 12:28:53 test1 docker:  Tue May 30 19:28:53 2017 1.2.3.4:55195 TLS Error: TLS object -> incoming plaintext read error
May 30 12:28:53 test1 docker:  Tue May 30 19:28:53 2017 1.2.3.4:55195 TLS Error: TLS handshake failed

Manually regenerating the CRL and copying it in to place resolved the issue. Only people who generate a CRL and then let is expire without re-generating it (primarily by revoking certs) will encounter this bug.

I'm not sure how to handle this as re-generating the CRL will require the CA private key passphrase and can't be done automatically.

[buchdag]

Crap, I totally​ overlooked this.

Easy RSA default CRL validity is 180 days, a fast and dirty fix would be to set the env var EASYRSA_CRL_DAYS to 3650 days by default, meaning that CRLs will outlive the CA (if easy RSA CA validity hasn't been set beyond the default ten years).

I think it might be less dirty than going down the "unattended script having access to plaintext CA private key passphrase at some point" route.

[kylemanna]

Setting the ENV var in the docker container to 10 years seems reasonable given the use case of this image. I don't know that the expiration date of a CRL on the same machine as the server referencing it and often (except in paranoid case) hosting the PKI really means anything.

[tomaspapan]

Can you write steps how to regenarate it manually?

[buchdag]

edited :

docker exec -it your_openven_container easyrsa gen-crl

docker exec -it your_openvpn_container cp -f "/etc/openvpn/pki/crl.pem" "/etc/openvpn/crl.pem"

And you are good to go for another 180 days.

If you are using a version prior to 861ed05 and never generated a CRL, there is nothing to fix.

[kylemanna]

@buchdag you forgot the step where you copy the CRL

docker exec -it your_openven_container easyrsa gen-crl
docker exec -it your_openvpn_container cp -f "/etc/openvpn/pki/crl.pem" "/etc/openvpn/crl.pem"

[buchdag]

@kylemanna I just forgot that prior to #251 a container restart would only pick up a modified CRL once, I guess I'm getting tired. Force copying the new CRL with docker exec is indeed the better way and won't require a container restart, I'm editing my answer.

[kylemanna]

Force copying the new CRL with docker exec is indeed the better way and won't require a container restart, I'm editing my answer.

I think it potentially will require a restart still. The OpenVPN daemon seems to hold an open file descriptor to the file and re-reads it everytime a client connects. If the copy replaces the file then the file descriptor that OpenVPN holds is still pointing to the deleted file and won't re-open the file until after it restarts. If the copy operation truncates the file and then writes the new file over place, then it would work without restarting.

Ultimately we could fix this by changing the way EasyRSA operates as described here.

That said, I just restart the container to avoid all headache currently. If someone has many clients on their OpenVPN server then they'd be interested in updating the file correctly as described.

[kylemanna]

Closed by #281 Thanks @buchdag