Repository navigation
Lower leaf cert validity 397 -> 47 days #10437
Description
Activity
Interesting. That news didn't contain our "397" days, but "398" as the previous value. Likewise, our new limit is likely 46/99/199 days, respectively.
I, and only if(!), no customer complains about the 47 days in prod, let's introduce LE-style shortlived certs! Then basically only the CA master would absolutely require an up-to-date CRL file – for everyone else, the cert lifetime would do the job.
Eventually, you'll run into an issue: the renew interval. Currently, certificates are renewed if their remaining validity is less than 30 days:
icinga2/lib/base/tlsutility.hpp
Line 39 in f876403
With ~47 days of validity, this would already become questionable, as you will renew every ~17 days, way less than even half the validity. On the other hand, these 30 days are also the time span for which a node/agent can be offline without risking that it's certificate expires.
Regarding the original suggestion:
The CA/Browser-Forum requires this
We are not bound to these guidelines and the Icinga CA doesn't satisfy their guidelines, by far. So just picking some aspect without other providing reasoning why this makes little sense. Realistically speaking: how much do we actually gain by just renewing certificates more often while keeping the node's private key unchanged?
Reacted by Dominik Riva and Andreas ZieglerCurrently, certificates are renewed if their remaining validity is less than 30 days
This would have to be adjusted,
obviouslyofc.We are not bound to these guidelines and the Icinga CA doesn't satisfy their guidelines, by far.
Yet, as discussed in other context, we explicitly supported browsers as API clients from day one. Guess what they use as guidelines...
So just picking some aspect without other providing reasoning why this makes little sense.
It's customers that are picking, if at all, e.g one picked #9179 which reduced certain lifetime to... 397 days! Coincidence? I don't think so.
At least I am not picking one thing. I also want e.g to extract CN from SAN.
Realistically speaking: how much do we actually gain by just renewing certificates more often while keeping the node's private key unchanged?
Correct me, but AFAIK it's enough to put the certificate on our CA-master's CRL for the node not to get any renewal anymore. This means, all other nodes trust it only until the cert expires. And the shorter the duration, the better.
We are not bound to these guidelines and the Icinga CA doesn't satisfy their guidelines, by far.
Yet, as discussed in other context, we explicitly supported browsers as API clients from day one. Guess what they use as guidelines...
I'm sorry but that makes no sense at all. These are guidelines that are relevant if you want to get your CA into the default trust stores of browsers, something that's never a goal for an Icinga CA. If browsers were to entirely refuse certificates with a validity longer than a specific duration even for locally configured CAs, that would be a reason to consider this, not just because the CA/B guidelines say so.
Reacted by Andreas Ziegler and Alvar
Is your feature request related to a problem? Please describe.
Describe the solution you'd like
Describe alternatives you've considered
Additional context
https://www.heise.de/news/47-Tage-CAs-und-Browserhersteller-beschliessen-kuerzere-Laufzeit-fuer-Zertifikate-10352867.html?utm_source=chatgpt.com