The original post about 90 day lifetimes says that Let’s Encrypt will explore shorter lifetimes once renewal tools are widely deployed. What’s the progress on that?
I’d like to switch to Let’s Encrypt, but would prefer to have 21-35 day (~1 month) certificates.
A post from earlier this year indicates that hopefully we would see some movement on shorter lived certificates sometime this year, but I haven’t seen anything yet.
The post you linked is a pretty good summary. We think it’s an interesting area for exploration, but haven’t been pursuing it actively due to other priorities. Your feedback that you’d find shorter certificates useful is very valuable, thanks!
You can renew 90 day certs every 30 days (today).
Unfortunately early renewal doesn’t solve the problem we’re trying to address – limiting the lifetime of an exposed certificate.
The certificate itself is public in any way (you may download it on https://crt.sh/), the private key must be kept safely. If the key gets exposed, you can revoke a certificate at any time.
Revocation isn't very reliable, though.
I Think the lifetime shouldn’t be shortened forcefully. But there could be a option to select a shorter lifetime if you want. Maybe via something like a TXT record you can set with _acme-options.example.org = “max-lifetime=X;” which will limit issuances for your domain to X Days. (but the 90 day limit cannot be exceeded regardless of X)
Absolutely NOT below ~35 Days, because that would limit the usefullness of using cron to renew certificates.
Currently you can run */2 on crontab to get renew each 60 Days. Doing this below 1 months will require renew on the week level and that is pretty harsh.
Could you explain that?
AFAIK the renew cronjob runs twice a day per default when using certbot.
This is the correct recommended best practice.
This is not recommended. Best practices recommended by Let's Encrypt/Certbot teams are to run Certbot renew twice daily. It will only attempt to renew certificates expiring in 30 days, by default.
Isn’t that a bit unneccessary to run the software when its not neccessary? Better to run the client */2 on the month tab with forced renew.
Thus you will just run whatever ACME client you are using only as much as neccesary.
(And then you can do other automated tidy-ups aswell in the same script, as resigning DNSSEC data etc)
Lets assume renewal fails for some reason, the next try will then be executed 60 days later. This could easily result in expired certificates.
Futhermore, running forced renewals every 60 days clusters all certificate renewals in disregard of actual certificate lifetime. IMHO, its always better to distribute renewals over the longest possible time period.
I can confirm it’s better to run Certbot (or other client software) in a twice daily cron job than every two months, for the reasons people have cited here: If one run fails (for instance because it falls during a maintenance or outage), you still get many chances for subsequent runs to succeed automatically.
Like @mnordhoff said, revocation doesn't really work with today's browsers; shorter lived certificates help combat an inevitable key exposure. I have some optimism that things will get better with OCSP Expect Staple, but neither server nor client support is great today.
If the private key is not required to be changed (which it isn’t), shortening the renewal life really does nothing to remove the problem you seem to be facing.
I disagree with you there. I believe thinker’s concern would be adequately mitigated as long as they had the option to change the key with each renewal. It’s a question of whether the option was available to them or not.
Yes, with other CAs, we rotate keys at the same time we rotate certificates. Validation is trivial so if it’s a matter of doing a new issuance vs a renewal each time, it’s worth it to me to get fresh keys on every renewal.
Good news for you, Certbot uses a new private key every renewal unless you explicitly define a CSR.
That may depend on the client used.
I have seen where: If you specify the private key file, and it already exists, it will not overwrite it.
That’s why I specified Certbot. However, the option being available is the concern for thinker, it seems.
OK I think I do now see what you've seen all along:
He doesn't want to renew and manually change the private key early, he wants the cert to expire sooner.
To ease his fears of "exposure".
I can't say I understand the fear, nor the use case, but I do see the request now for what that's worth.
And I do agree that if 90 days is the maximum, then we should be allowed to request less than an 90 day expiration. For his case he should be allowed to request his certs for 30 days and renew them every 21 days.
More choices always equals happier customers 