I have a weak desire for shorter certificates, but I worry about how to roll it out.
For example, if Let’s Encrypt unilaterally started issuing 45 day certificates, Certbot users with the default configuration would wind up renewing them every 15 days, and users who configure the cron job to run infrequently, against recommendations, might end up with their certificates expiring.
I’d probably be happy with 60-day certificates for my own use.
7 day certificates or something would be fun for an organization with 24/7 sysadmins and developers, but…
If the next 90 day cert renewal becomes 89 days who would really notice?
Then if that 89 became 88 who would really care?
And if the 88 was then 87 (at least 6 months have passed since it was 90)...
[People have short attention spans.]
…
What are we talking about?
IMO, the juice isn’t worth the squeeze. It would break a great many clients who have depended on a ~90-day cert lifetime to set their default renewal time (30 days before expiration). Against that, the (IMO, again) marginal benefit of the phishing site’s cert not being valid for as long.
This too can be overcome.
Over time.
Change will require updates to handle the change.
But change is the only constant.
Yes, every client will have to handle the possibility of a lower starting life time.
But if they clock it back from the date of expiration, instead of the date issued, they can correct most of those inconsistencies.
Most clients (at least that I've seen) do this, but they default to 30 days. If your initial cert lifetime is 30 days or less, you're renewing every day (or even twice a day) and rate limits come into play. Yes, it can be adjusted. Is it worth the trouble? IMO (for what that's worth, which isn't much), no.
Even in the “worst case scenario” you presented.
They would be renewing twice a day and will hit rate limits in 2.5 days
Which should auto-adjust to 2.5 days blocked every 5 days [50% issuance]
Which would produce about 15 certs per month and have a very high overlap rate >90%
But the actual time consumed by those overlaps would be about 125 days (or about +178% above the norm).
The average/default setup today is +33%.
That may seem significantly greater… read on.
A user that issues 5 duplicate certs in a 90 days window (for 90 day certs) would consume >+400%
A user that is misconfigured and goes unchecked can issue (5 certs every 5 days) a cert per day and that’s about +9000% and goes totally unchecked?
Is that not more concerning?
I think everyone is under estimating the power/benefit of shortening the life span of the BAD certs.
In simple comparisons:
Misconfigured system A renewal daily and is issued 30 day certs.
Misconfigured system B renewal daily and is issued 90 day certs.
What is the net difference?
If you say they are “basically the same” or “should be close to the same”, then you really don’t understand my point nor the math this comparison presents.
Are there any Math majors in the house?
Compare:
A. sum{1…30} = 465
B. sum{1…90} = 4095
Adjusted to equal length of time (90 days):
A. 465 * 3= 1395
B. 4095*1= 4095
The limit is five duplicate certs per seven days, no? In that case, all your numbers change. You go to 35% issuance rather than 50%, and others change correspondingly.
...or perhaps you are over-estimating it. But without any data, we're both just operating on gut feelings.
Math is not politics, nor religion, nor astrology...
Math can, and should always, be debated; because Math can be proven.
Perhaps, I never claimed to be a Math major.
If you feel I'm over-estimating my results, then show your Math.
I am more than willing to learn the "truth" (especially in Math).
(I did try to show mine)
Math results are not "gut feelings".
The "gut feeling" may have pointed me to look in this direction; but the "finding" are based on Math.
Any the "findings" can be verified or corrected by any Math major; Who can accurately determine a comparison of the "worst case" scenarios:
Both UserA and UserB: Attempts to renew hourly and can successfully get a new cert.
Both users are bound by the same rate limits (5 per week).
They only differ in cert time life span:
UserA gets 30 day certs.
UserB gets 90 day certs.
Questions:
How many certs can each user obtain over the same course of time?
[This should be the same answer for both]
How many concurrent valid certs can each user have?
[This should NOT be the same answer for both]
It is in that difference in the second answer that we can see the overall benefit of the shorter cert life span.
If my Math is off, then it is off; But it and can easily be proven to what is the correct Math answer.
But the logic/reasoning is in the benefit of that difference is sound:
The 90 day cert client would have 3 times as many concurrently valid certs than the 30 day cert client.
That's 3 times as many OCSP signatures for the exact same misconfigured client.
Is it a fruitless undertaking, or just entirely impossible, for an ACME client to request less than a 90 day cert?
If not, I would be happy to be first (guinea pig) in that line.
I would request them for 45 days; and renew them every month.
(If for nothing else, just to help show the overall affect it would have on the system)
Let’s Encrypt has talked about reducing certificate lifetimes in the future, although I don’t think this is on the horizon at this exact moment. An interesting question is whether any particular things are likely to become entrenched that would make this kind of change difficult (e.g., a lot of people doing manual renewals, or a lot of software that has hard-coded assumptions about 90-day certificate lifetimes).
This is probably a question that could be studied empirically based on CT records and maybe some statistics about ACME clients. The former are publicly available, while ISRG may be able to release some statistics about the latter to researchers after confirming that they’ve been aggregated in a way that protects privacy. For example, someone could do a study to figure out which renewals appear to be fully automated based on the relationship between expiry time and renewal time. Then another important question might be which users are using clients that receive updates (since someone who’s using a non-updating client that makes inflexible assumptions about certificate lifetimes would be in for trouble if the certificate lifetimes changed).
Another thing that would help make this look more feasible would be finding ways to do more and more automated integrations so that fewer and fewer people are renewing manually.
(I don’t know what the server side folks’ priorities are about this—I’m just speculating at a high level.)