Re: I have a question about Easy-RSA

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

_______________________________________________
Openvpn-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-users