Absolutely. Especially with the advent of protocols like ACME it just makes sense.
Here's a nice blogpost from smallstep (not affiliated) on this topic: https://smallstep.com/blog/passive-revocation/
Why do you think the maximum lifetime was reduced from two years to one?
Does it make a lick of difference if you’re man-in-the-middled for just one year instead of two? What kind of argument is that!?
“Oh, they got every active user credential and form that was submitted ages ago, but no worries! This won’t go on for another year! Just months to go now…”
No, obviously the CA cartel just wanted to extract 2x the rent.
The whole thing is just absurd on its face and needs to stop, but there are billions of dollars worth of rent seekers that say…
“No.”
The reduction to 398 days was imposed by Apple, unilaterally, although in practice the ecosystem went along with it. It actually took a few weeks to get clarity on exactly what Apple intended, they just basically blurted it out at a meeting.
- One year instead of two? Yep
- 3 months instead of 1 year? Yep.
- 1 week instead of 3 months? Yep.
The reason certificates have traditionally been so long is because it was a manual process. Using ACME it is possible to expire certificates every hour if you wanted to do that.
Now it seems that revocation is supposed to help the CA covering up mistakes made by the CA.
Maybe we actually need a better CA.
Go for it. Start one and tell us how it went.
So okay, maybe you don't have certs revoked and you don't need to restart your Traefik but are you really sure everything is okay?
1. Supposedly more secure challenge types such as TLS-ALPN-01 are far from stable, as the current incident shows. Your cert can be revoked at any time through no fault of your own. After being burned by TLS-SNI-01 the last time, now I refuse to use anything other than plain old HTTP-01 and DNS-01.
2. As soon as the version of the Linux distro I was using (not in my power to change!) reached EOL, certbot suddenly refused to renew, despite the fact that I'd been using more or less the same version of Python and certbot for a number of years and the HTTP-01 challenge requires nothing fancy at all. Why does everyone these days insist on making ops decisions for other people?
3. On a server with existing nginx virtual hosts, certbot injects configuration directives including stuff the nginx team officially recommends against, such as `if` statements. It frequently breaks existing configuration such as rewrites and redirects. After seeing this a number of times, the only conclusion I can make is that certbot has no idea how to manipulate nginx config files.
4. If I have multiple domains pointing at the same application, and remove one of them at a later time, certbot is oblivious and repeatedly fails trying to renew the certificate that now contains an invalid domain. Again, certbot doesn't know how to work with nginx.
Maybe 3 and 4 can be improved if ACME was integrated as a proper nginx module instead of certbot trying to change things from the outside. My experience as a whole, however, makes me feel that the LE/certbot teams are rather cavalier about the commitment to stability they need to make if they really want to become an essential part of the world's internet infrastructure. If you want to be paternalistic about managing TLS for people who don't know how to do it, at least try to do it properly!
If you don't like how the nginx plugin works, then fork it.
Wrapping "certbot renew && nginx -s HUP" into a systemd service doesn't seem to be a very complex thing to do.
The fact that there are alternatives, though, doesn't mean that the crappy "official" client isn't doing the LE ecosystem a disservice.
Instead of running certbot on every server, I wrote a custom ACME client that runs on a master server and is responsible for requesting/renewing all certificates that I use. It also automatically deploys each cert to the correct server.
It is a single point of failure but it makes tracking certificate expiry, renewal and revocation so much easier.
(And depending on the storage backend, it's no longer a single point of failure. And even if storage is the failure, it's just storage, if it's down your servers will keep running.)
I call it "The Prometheus monitoring I already needed to make sure my servers are up and serving the websites they're supposed to"
The bulk of the work was already done for me as there was already an ACME library for my language.
I'll probably open source it once I have a chance to clean everything up.
And that’s okay.
And this is one reason why I keep advocating for certificate automation to be built into services/apps, rather than patched on the outside with duck tape.
I look forward to the day when cert lifetimes are regularly about as short as OCSP responses. Then we can possibly do away with OCSP entirely.*
(* I am of the opinion that revocation is fundamentally broken for Web PKI and it should be phased out in favor of short cert lifetimes. You may disagree and that's fine, but I'm happy to discuss why if you're interested.)