I think keeping the validity long just removes incentives for people to bother fixing their setups. We've seen the shift from "Craig needs to spend a few days on certificate renewal every year" to full automation in most environments when the 90 day validity period was introduced, and shortening it to a week will only help further automation.
You'll always have the option to skip the hassle (for a small fee, unless a Let's Encrypt competitor joins the market), but I feel the benefits outweigh the downsides.
I personally would've preferred something like DANE working, but because the best we've got is DNSSEC and most of the internet doesn't even bother implementing that, I doubt we'll ever see that replace the current CA system.
Some software now uses short lived certificates and even with decent configurations, there is an elevated level of problems specifically because of certificates. Especially in networks that use a lot of segmentation with very restricted network traffic.
I think a short lifetime can be a security benefit, but it should not become a dogma. It should be employed where it really makes sense but as a general rule inconvenient describes it quite well.
FWIW you should run most ACME clients more often than that, just in case there's a performance issue or bug at Let's Encrypt's side. The tooling won't replace your certificates unless they're almost expiring anyway. Certbot's instructions will have you set up a cron job that runs twice a day.
> Some services do not load certificates while running and must be restarted
This is exactly the kind of software that needs fixing. Luckily for the critical, nine nines uptime cases where 5 seconds of downtime for the web server restarting is unacceptable, there are services that will sell you certificates valid for a full year or even longer.
I doubt year long certificates are going away soon. We're already years off Let's Encrypt ending their 90 days offering, for sure. The convenience factor isn't going away, at some point it'll just cost a bit more.
The best certificates should expire after 20ms. /s
Other than that, I've never had to babysit certbot. It's just a systemd timer job.
I’m 1,000% sure that they know what you’re trying to espouse. Nowhere in the comment does it say “here is an exhaustive list of hosted email providers”. It’s a JOKE.
But hey, there's an upside: When they finally break this toy badly enough, everyone will finally evict the CAB from their lives and do something else.
I think that shorter cert lifetimes and the push for more automation is a valid direction to look in and work towards. But at the same time that means that there's a certain skill floor and also certain tech that you need to have in place to be able to work with all of that.
Back in the day, you'd just have someone sit down once in a year, move a few files around your server and call it a day. With the current trends, that won't really be possible, at least not for any of the certs that you can get for free.
For my public facing stuff, I just bit the bullet and went through with the automation (certbot is nice, mod_md is okay, Caddy is great), but for my personal stuff I settled on running my own CA and self-signing stuff. If I want a 10 year cert expiry for something that I don't really care that much about, I'll go ahead and do that because I'm in control. The server itself is unlikely to survive for long anyways and other development stuff is more likely to break first, so I'd rather spend my time there, rather than on automation that I don't need. Plus, mTLS is suddenly easy to do as an added security layer if I ever need to expose something to-the-outside-but-actually-just-for-myself-when-on-the-move.
Second, I think the statistic is that 81% of businesses have had an outage due to certificate expiry. So you need to understand that making certs expire more is inherently damaging. Automation breaks so even automated shorter-lifetime certificates will still accelerate and increase this damage.
And finally, nobody who's ever tried justifying the CAB's behavior has actually been able to demonstrate the CAB is solving real world problems. I want someone from the CAB to show me a real world exploit that happened that was because someone got a hold of a certificate between 7 and 90 days old and was able to use that maliciously.
If someone from the CAB can't do that, the entire CAB should be disbanded.
Regarding your "skill issue" comment, it really only demonstrates you have some growing up to do. There's a lot of real world complexity in operating business-critical and life-critical services, and it's obvious you lack experience with both.
I believe that this is out of place and perhaps a result of reading things with an uncharitable interpretation.
The skill floor part of the comment isn't me attempting to blame someone, but rather point out that needing this sort of automation complicates things and adds friction. If the only certificates that you get for free (e.g. Let's Encrypt) are short lived, then you can't just sit down once a year and move some files around, you need certbot / mod_md / Caddy and all that comes with it. Of course, you still have the longer lived commercial certs, but it's odd to see how the trend is shifting towards ACME. Not the end of the world for most, but also something that a mom & pop shop might prefer not to deal with. Or, you know, environments with specific requirements.
> So you need to understand that making certs expire more is inherently damaging.
For this, I make no claims one way or the other. To me, concerns about long lived certificates seem valid, as do those about short lived ones, both have risks associated with them. Which is the better approach? You decide for yourself. Except most people don't get to decide and just have to roll along with whatever the industry at large settles on.
In any good risk management scenario you have to weigh the cost/benefit of a change in terms of what benefits it offers and what tradeoffs it has. The CAB has repeatedly demonstrated complete inability to consider the risk profile of their behavior. They are unqualified for the job, and unfortunately, accountable to noone.
Uh, no. Most of the outage due to certificate expiry is not caused by subtly broken automation. It's caused by non-existent automation or outright broken (never gonna work) automation.
So, if you make certificates expire in 6 days, you are not going to have these outages. They will be caught during develop.
People just pretend it's okay and forget about 1 year certs. With 6 days cert it would be impossible to pretend it's okay to shift a few files manually. Or maybe some organizations will setup a human-run rotation which actually does shifting a few files every 3 days, that's totally okay. You don't need automation. You just need a way to consistently make sure your certificate won't expire in prod (and in emergency, able to quickly replace a cert).
Certificates with 1 year expiry is nothing but a dangerous footgun. It's worse than 30 years expiry, at least with 30 years expiry you don't get outages.
I's only inconvenient because it isn't properly automated. That's by design.
When this can be a acme.sh script cronjob, there isn't much of an excuse. Even my Raspberry Pi dedicated to my 3D printer is happily renewing certificates.
At least with this thing breaking every 90 days you have it fresh on your mind. One year away you may not even remember what you have to do.
Needless to say, you have a bug to fix.
Clearly it's not working correctly, so a longer certificate lifetime wouldn't address the root cause - you would just have to fix your setup less often.
I also have hobby-level serving needs. I've been using LetsEncrypt since whenever it was they started. I have two top level domains and a whole lot of subdomains.
I've never had to babysit certificate renewal, nor had to log in manually to fix anything. Not once. How comes?
Edit: seems like using Cloudflare as the DNS host is the way to go here. Thanks everyone!
Here's a utility (and library) that can talk to several dozen APIs for DNS updates (use it as a hook in your ACME client):
* https://github.com/dns-lexicon/dns-lexicon
* Previously at: https://github.com/AnalogJ/lexicon
On the top of my head, that could be because one or more domains are not accessible from the public Internet (which could be for a variety of reasons), a subset of the subject domains having expired for legitimate reasons but you might not know which in advance (certificates being what they are some application rely on them having alternative names), intermittently flaky routing (which might not be a problem for the application), and a number of other reasons. That's without including potentially hostile actors. Then there are plenty of offline uses for certificates!
That said, Let's Encrypt has really been a revolution and made life better for many people. But it's not perfect and the PKI system itself has many warts. It's absolutely a system that may need a non negligible amount of babysitting when you venture outside the absolute mainstream.
You have to automate certificates. You can't do these by hand anymore. Certificate lifetimes are going to get inexorably shorter.
For the longest time the web PKI lacked a singular view on what exactly they were supposed to be signing. Its usage reflects that.
That is deeply rooted in culture. I mean, we do speak about a culture in which X.509 was a reasonable choice. Years after the X.500 universe was cold to the touch at that.
The rest of your comment seems directed at someone else. Framing this on automation is misleading, which is what the examples in my comment were intended to show.
I guess if you zoom out, one of the things I bristle with is LetsEncrypt's opinionated way of changing people's behavior. The short certificates were a deliberate decision, done to "get users to do X." They were pretty transparent about it. In my view, computers should do what users want them to do, not what developers want users to do. We've got enough software out there with notifications and consent dialogs begging users to do this and that, and this just adds to the problem.
I get that the software is free (which was a revolution in the PKI world at the time), but the short lifespan seems to be either a behavior modification experiment OR an annoyance to get people to fork over money for the better (better for users, not necessarily for security), longer-lived products.
It is, pretty obviously, not a weird scheme to get you to pay for certificates at some other CA.
I’m not saying that our use cases are truly identical, but from what you’ve described, I don’t think that your experience is simply “how things are”.
I've been running an LE client (official one, dehydrated, others) on various system for ~8 years, and the one time I had an issue with renewing was when (AIUI) the LE folks changed CDNs and so their responses were (slightly) different and dehydrated needed to be tweaked:
* https://community.letsencrypt.org/t/jws-has-no-anti-replay-n...
* https://github.com/dehydrated-io/dehydrated/commit/e4e712c03...
Other than that, never had an issue.
Not as advanced as in Caddy (which will be a more pleasant option to use in many cases), but it's curious to see them adding something like that! Makes me wonder whether we'll also get some Nginx functionality like that out of the box sometime so certbot won't have to always be installed alongside it for sites that need to use ACME.
I've been using them for years and never had to deal with certificates anymore.