How to allow (some) expired client certificates in OpenVPN?

Question

I would like to prepare for the case that client certificates get expired and wondered if there's any option/hook one can use to tell OpenVPN to accept client certificates even if they have been expired?

Looking at the reference manual, I only found things which could be checked alternatively or additionally and then mostly after OpenVPN itself validated certificates already. But I can't find anything to tell that OpenVPN should do its normal certificate validation, but in case a certificate has been expired simply still allow it or optionally ask me by using some script.

–tls-verify cmd runs only after all other tests have passed already, but in case of an expired certificate things fail. The same seems to be the case for -management-client-auth. Something like –verify-client-cert none|optional|require sounds promising, but there simply doesn't seem to be the case I need. Using username+password wouldn't help my use case, because that would involve re-configuring lots of clients, in which case I could simply change certificates as well. I need something which relies on certificates but gives me some additional influence.

So is that possible at all currently? From what I've read it sounds like the answer is no. Thanks!

Answer 1

Got into that situation recently; unfortunately it seems that the project stance is that this ability would be a potentially abusable breach so they won't do it: https://sourceforge.net/p/openvpn/mailman/message/26580749/

One idea was proposed in the same post - to temporarily wind back the clock on the server, which may be counterproductive in general case, but would allow the certificate to look like it is "current".

On similar note, there are libraries to wind back the clock or set it to static value, as reported by libc date-related functions which this library would hijack if linked via LD_PRELOAD. This is often used in reproducible package builds so such variables as current time do not make each build unique. In my case, https://github.com/wolfcw/libfaketime worked (I just looked at the arguments of the running openvpn server, stopped it, and re-ran same command line inside the faketime wrapper program) - and it is packaged in many distributions so yours might just have it.

Note that if your VPN server thinks that the right clock is from a week or month ago, it would deny access to well-maintained clients whose certificates are newer than that timestamp and their validity did not start "yet". If your VPN like the one I helped bring up sends out certificate in batches (e.g. once a year) you may get into a loophole that:

• server won't start because its rewound/faked clock does not trust its too-new certificate
• so you tweak the config and use the previous certificate
• clients you are trying to reach do not trust the obsoleted server certificate - their clocks are all right

You may succeed by issuing an additional VPN server certificate that is valid in both time ranges you are interested in. Not sure if easyrsa makes that easy... but faketime wrapping it might ;) or just direct work with openssl.

Another idea might be to devise a patch for openvpn code to relax its checks, and temporarily run this build with a deliberate backdoor as your server. Then fix it back (run the original implementation) to be safe, as soon as you update the overlooked clients with newer certificates.