Expired server cert not shown as error message

[bflesch]

Today the server.pem key of my openvpn server expired, with the effect that all client connections to the vpn server were lost. Client reconnects resulted in weird "TLS Timeout" error messages on the server, as shown in ​https://gist.github.com/bf/360541252c2a24a41e50 .

After multiple openvpn restarts I joined #openvpn and after various resolution attempts dazo told me to check the server.pem file via "openssl x509 -dates -in server.pem". This way we found out the key had in fact expired.

In retrospect I would have expected openvpn to report a warning or error message to its logfile, which would have made me aware of the expired key. The lack of such message made us do troubleshooting with regard to connectivity issues, and even using tcpdump.

In my eyes this trouble would have been saved if a simple check for expiry of keys supplied to openvpn via the "key XY.pem" command, and a subsequent log message.

My openvpn server config is as follows:

---

port 3824

proto udp
#proto tcp-server

dev tun

ca ca.pem
cert server.pem
key server.key
crl-verify crl.pem

dh dh2048.pem

server 10.44.11.0 255.255.255.0

#ifconfig-pool 10.44.11.10 10.44.11.99

ifconfig-pool-persist ipp.txt

# Client config dir for specific configurations for "special" clients
client-config-dir ccd

client-to-client

keepalive 5 120

comp-lzo

persist-key
persist-tun

status /var/log/openvpn/openvpn-status.log

log /var/log/openvpn/openvpn.log

# log verbosity
verb 4

---

My server OS is ubuntu 14.04 with openvpn 2.3.2-7ubuntu3.1.

Thanks for your time. Thousand thanks again to dazo who helped me out very kindly in #openvpn.

Beni

[Gert Döring]

Throwing at syzzer... can we do that? Either have the client report "oh, the server cert has expired!" (why doesn't it do that? The server reports "client cert expired!" just fine...?!), or have the server self-check itself and log a warning if the current time is outside the valid range...

[Steffan Karger]

Yes, we should be able to do something like this. Checking the validity of our own cert on start-up should not be too difficult.

Right now the client checks the server cert, and the server checks the client cert. So, I expect that the client will report about expired server certificates, and the server will report about expired client certificates.

(I'm not yet making any promises about implementing this myself; there is too much unfinished stuff on my stack already...)

[Gert Döring]

This has now been done :-)

commit dfd940bb008feb2fe981ceab3ed66fdb3cf21bdb
Author: Steffan Karger <steffan@…>
Date: Sat Dec 19 12:39:29 2015 +0100

Warn user if their certificate has expired

Previously, client certificate expiry warnings would only visible in the
server log, and server certificate expiry warnings in the client log.
Both after a (failed) connection attempt. This patch adds a warning to
log when a users own certificate has expired (or is not yet valid) to ease
problem diagnosis / error reporting.

Note that this is just a warning, since on some systems (notably embedded
devices) there might be no correct time available.

The SSL_CTX_get0_certificate() function is available in OpenSSL 1.0.2+
only. Older versions seem to not have a useful alternative, and the
certificate reference we need is hidden in an opaque struct. The
remaining option would then be to add extra workaround code for the select
group of people that do use an up-to-date openvpn, but do not update their
openssl. I don't think that's worth it. So just disable the code for
older openssl versions.

(This is a combination of commits 091edd8e and 644f2cdd from the master
branch, adjusted to apply to the release/2.3 branch cleanly)

... which will be part of the upcoming 2.3.10 release. So, done. Thanks :-)

(Just as a side note to the original reporter: the *key* never expires, it's just a heap of bits. The *cert* has an expiry date)