Today all LE certs have a minimum and maximum 90 day life span.
Should LE consider allowing the certs to have shorter durations or even longer ones?
Or maybe “scale” them automatically… So that all new certs start at 30 day life span.
Then each renewal would increase it by X number of days (until it reached the maximum allowed).
While always giving the end-user the ability to request a specific length.
LE would always auto-correct those excessively short and those excessively long request times - to match allowed range:
Minimum days: 40?
Maximum days: 120?
There has been extensive discussion on the subject of certificate lifetime. I recon you’re not trying to do this discussion all over again.
On the item of “dynamic” or “scaling” certificate length: what problem would this fix? I.e., what is the issue with the current lifetime, what would be fixed with “scaling” lifetimes?
If you allowed clients to nominate their own certificate expiry, I have no doubt that the overwhelming majority would default to the maximum (as would all tutorials). Hell, that’s what I would do. In that case, there would be even more OCSP responses that would need to be kept current, than today.
The scaling thing on its own is clever, I don’t mind it, but it might cause chaos and confusion for new users.
Yes, many would ask for more time - maybe only a few would ask for less time.
But the control of how much time you actually get is maintained by LE.
Don’t follow the “rules” and you could get days cut from your (future) cert limits.
All would still get certs and the rate limits would remain in place.
Simply put: Misusers’/Abusers’ certs would just expire a lot sooner.
Keep abusing/misusing and the cert life continues to decrease.
Do it right and you could be “rewarded” and have to do it less often (if you so chose).
For myself, I would like to see them auto-renew every quarter (365/4) ~91 days.
So it would have to have at least (91 +15|30 days cushion) 106 to 121 days.
Then why issue a cert for 90 days and have to maintain it for 90 days?
Always start low and move up as needed.
If they never renew the phising site, then you only issued one 30 day cert.
A very simple approach would be to start every cert with 30 day limit.
Only allow it to be renewed after 2/3 life time (round to nearest day).
And for each correct renewal increase the new cert life limit +1 day.
For each “forced” renewal or “duplicate set of names” or any other known negative action then -1 day from new cert life limit.
It would basically auto adjust all on its’ own.
Never exceeding the maximum allowed life limit.
And never falling below the minimum allowed life.
There would only be one extra column for each cert maintained (to keep the current life number).
Overall cert life limits can then be set globally based on capacity.
We would all be able to go further or we would all be limited to a reasonable lite time (one that can be maintained by the current infrastructure, etc.).
This type of scaling system would benefit most those who can automate their renewals.
Given, that once they are fully automated, the cert life, expiration, and renewals become essentially irrelevant.
So, who cares how long a cert last?
Basically only those that have to do it manually.
But over time, as the good renewals get longer, the “overlap” (those last 30 days when a cert gets renewed but the previous one is still valid) becomes less of a load:
30/60 = 1/2 << yes, this would add more, but is offset by earlier removals of unused “testing” / mistakes.
30/90 = 1/3 << LE is currently here
30/120 = 1/4 << 8.3% less overlap
So maybe a 30 day start for ALL new certs would be way too low for anyone forced to renew manually.
That may need to start higher - like 60 day.
And then good renewals may need to add more than +1 (maybe +5 days)
But that would have to be outweighed by an equal decrease to bad cases (-5 days)
The absolute low could still be 30 days, just doesn’t seem like an ideal place to start everyone with.
This sounds like an exceptional amount of complexity to add for very little benefit. Indeed, the sheer confusion it would create for users is enough for me to oppose it (for what that’s worth.) This would be a rather monumental and difficult-to-understand change for the average user, and would require a lot of changes for large integrators. How often each certificate must be renewed is a lot to keep track of when you have thousands of certificates with varying lifespans. What about when these get combined onto different certs? E.g., an integrator who lumps 100 random names onto a cert, a la CloudFlare style? if they shift these around, or if the domain owners take actions that change the lifespan for their FQDN, the integrator would have to account for this on all renewals or new issuances.
Even for individuals with a single website, taking advantage of this “correctly” would break the idea of automation, as the sysadmin would need to adjust their renewal parameters with every renewal to take advantage of a constantly-changing lifespan.
If the goal is to get HTTPS spread as far as possible, I strongly believe that this is counter to that objective. I don’t see how this would help that mission, aside from a marginal savings on HSM time.
I think the whole point is to push towards automation - where you don't need to know when a cert will be expiring.
That should fall to the lowest current number from the list of names or the limits could be easily bypassed.
I fail to follow this logic (maybe you can expound on it):
It would bring emphasis in getting things done correctly - the sooner the better.
And foremost automation - which seems to be a bit of a "sticking point" these days.
For Certbot, yes. However, it's important to keep in mind that the client itself is still determining how long before expiry to actually attempt renewal. In Certbot's case, it's in the config files to renew, by default, 30 days before expiry. Otherwise, it never actually does anything at all. But this wouldn't be recommendable for shorter lifespans, and in fact would end up causing rate limit issues on the extreme end. Large integrators often use their own packages to renew at their desired frequency. Nothing prevents renewals every 80 days, or every 10.
So I could have 50K certs and it’s ok for me to renew them every 10 days?
(even though they are good for 90 days)
That is a whole lot of overlap/waste.
It’s not ideal and should be discouraged, but if it were a problem, it should be handled by rate limits. I don’t see how your suggestion prevents this at all. If I’m a poorly-behaving user with lifespans of 30 days, I can still renew every 10 days. In fact, I’m almost encouraged to, so as to give me time to fix issues if renewals fail.
Yes but…
10/30 = 3 active renewals (with 2 overlapping)
10/90 = 9 active renewals (with 8 overlapping)
Comparing 30 days to 90 days the overlap is reduced 75%.
Since no one has even come close to agreeing with having a longer life…
Maybe we can focus solely on the shorter part.
Does it make sense to scale down the cert life (based on any as yet undetermined criteria) in order to “reduce the noise” created by IMHO mostly those that should have been using the staging system to figure things out, but it can cover all others who seem to get it wrong (and are apparently very slow learners)?
[wow was that all just one question?]