On 07.01.24 21:20, Bo Berglund wrote:
If you have a couple of OpenVPN servers operating off of certs and keys generated back in 2014 (like I have), then these are probably set to expire this year 2024 because I think that the easyrsa I used back then sets a 10 year life of these.What is the proper procedure to refresh these so the servers will continue to operate into the future? I assume there are things that needs to be done on the server side, right? But do you additionally have to create updated OVPN files for the clients as well? Or is there some other procedure that can be used?
In a nutshell, if a specific CA certificate is used(!) in the config of whatever OpenVPN peer and is about to expire, you'll need to have it replaced, yes, *in every such config*.
There are various methods to do that, though, and which may be viable for your case or not does depend on the details. Probably the very *first* question you'll need to answer is whether your *remote* peers - usually "the clients" - need to still have a working VPN connection to you to get the updates rolled out, or have some out-of-band management access for you, or need to be updated (or an update *scheduled* to whatever downtime is convenient for them) by someone ("customer admin") who is on site, or ... .
David already described the "issue new CA cert for the same keypair" and "launch an entirely new CA (-> keypair -> cert)" approaches; I'd like to add that when we're talking about a CA created *10+ years ago*, one should think hard about whether the keypair (and algorithms) are still up to today's definition of "good enough".
(Yes, we have a CA cert still in use that's signed with MD5, and the only reason it hasn't ceased to work quite a while ago is that its cert has been self-signed back then, rather than issued by an offline root CA, like we do nowadays.)
Another possibility is to make CA cert rollover a normal part of a VPN peer's ("product") lifecycle, just like replacing the peer's own cert (hopefully) is. In one line of our products, peers usually have *two* certs (and corresponding, even shorter-lived CRLs) for every CA they need to know; one cert (age < lifetime/2) actually issuing child certs (with their lifetime := CA cert's lifetime / 2), and one (age ≥ lifetime/2) only "maintaining" the child certs it issued "back in its day" - by a) still existing and being valid, and b) continuing to issue CRLs.
(Pro tip: Make your cert lifetimes a multiple of seven days (or else your CA cert replacement tasks will "wander" through the weekdays and, assuming you have the weekends off, eventually pile up on Fridays) and allow every pair of n-th and (n+2)-nd cert to have a *bit* of overlap, i.e., at least a week, giving you some leeway to fix unexpected problems.)
Yes, that makes your product more complex. (A bit - you likely need some mechanism to roll out other kinds of updates, anyway. And if you do not *today*, you might want to note the EU's upcoming Cyber Resilience Act¹.) On the flip side, there IMHO is an advantage in that this approach pretty much *forces* you to implement CA cert updates "early" in the product's lifecycle, when there's still the required know-how and a development budget around ... way *before* things like "whoops, now we have leaf certs whose lifetime exceeds that of the CA's²" or "our CA privkey got leaked, we need to create and distribute a new keypair+cert TODAY, whaddya mean we have no process for that!?" happen.
¹ https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act ² i.e., the leaf cert will turn inoperational when the *CA* cert expires, *not* on the (later) day the leaf cert's notAfter states Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
