Streisand: Help: openvpn certificates expire in 30 days

[damko]

All my clients can't connect anymore to openvpn because certificates have expired.
Here's the client log:

Sun Dec  3 21:55:01 2017 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 25 2017
Sun Dec  3 21:55:01 2017 library versions: OpenSSL 1.0.2m  2 Nov 2017, LZO 2.08
Sun Dec  3 21:55:01 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Dec  3 21:55:01 2017 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Dec  3 21:55:01 2017 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Dec  3 21:55:01 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]188.x.y.z:8757
Sun Dec  3 21:55:01 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun Dec  3 21:55:01 2017 UDP link local: (not bound)
Sun Dec  3 21:55:01 2017 UDP link remote: [AF_INET]188.x.y.z:8757
Sun Dec  3 21:55:01 2017 TLS: Initial packet from [AF_INET]188.x.y.z:8757, sid=d90e6ef8 5e2b6775
Sun Dec  3 21:55:01 2017 VERIFY ERROR: depth=1, error=certificate has expired: C=US, ST=California, L=Beverly Hills, O=ACME CORPORATION, OU=Anvil Department, CN=ca-certificate
Sun Dec  3 21:55:01 2017 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Sun Dec  3 21:55:01 2017 TLS_ERROR: BIO read tls_read_plaintext error
Sun Dec  3 21:55:01 2017 TLS Error: TLS object -> incoming plaintext read error
Sun Dec  3 21:55:01 2017 TLS Error: TLS handshake failed
Sun Dec  3 21:55:01 2017 SIGUSR1[soft,tls-error] received, process restarting
Sun Dec  3 21:55:01 2017 Restart pause, 5 second(s)

I've noticed that in /etc/openvpn/openssl.cnf there are these two lines:

default_days = 1825
default_crl_days= 30

which might be the reason of the premature expiration.

However, now I'm trying to figure out how to revalidate my keys but I'm kind of lost (possibly without regenerating the .ovpn files for the clients).

Does anyone have any tip where to start from?

[cpu]

Hi @damko,

I believe you've run into a bug we mistakenly introduced. See https://github.com/StreisandEffect/discussions/issues/69 for more information & a command line test to verify for sure.

If so, your best course of action is to provision a new Streisand instance. Apologies about the hassle.

[damko]

@cpu thanks for the quick reply. yes, I'm definitely affected. I'm trying to figure out if there is a workaround before wiping the entire VPS

[damko]

@cpu I'm pretty sure that regenerating ca.crt using ca.key won't compromise clients certificates. Am I wrong?

[alimakki]

Hi @damko,

You would have to sign new client certificates in that case, and update all of your client configuration files. The easiest course of action would be to spin up a new instance from the current master.

Again, terribly sorry for the inconvenience.

[cpu]

@cpu I'm pretty sure that regenerating ca.crt using ca.key won't compromise clients certificates. Am I wrong?

Unfortunately as @alimakki says you would have to reissue the client certificates from the new CA cert & update all of the previously generated client configs.

I'm going to close this issue since we've identified the root cause and there isn't anything to fix in-repo. Thanks!