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.
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
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?
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.
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.
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.
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.
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 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.
Other than that, I've never had to babysit certbot. It's just a systemd timer job.
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
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.
I've been using them for years and never had to deal with certificates anymore.
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 think the drop-dead date for this product was like April 2015 or so. The ideal customer for a product like this (lazy and also incompetent but with plenty of money) is also likely to leave it too late. I won't guarantee we'd have caught that, but unlike forbidden steps taken to avert a bigger mess of ones own making (as happened for SHA-1 deprecation, some notable financial outfits secured certs which should not have existed, to cover for the fact they hadn't properly managed their own technical risks) this seems like a product category thing, nobody was openly selling certs that would just break in Chrome, that's a bad product.
[Why would such certificates break in Chrome? Google hate these long lived certs so Chrome treats certificates which have validity exceeding what the BRs authorise as immediately invalid, if you want to moan to Google about why your prohibited certs don't work you're basically admitting you violated your agreement with them so it's like showing up to claim your stolen rucksack full of cocaine from the cops...]
Surely there are tradeoffs in having to rotate the certs that often, right? Notably, considerable load on their infrastructure. I get that urging people to automate their renewals makes sense (though I've also heard people unironically saying: "I want it to be a manual process, so I know how it works instead of relying on some black box"), but it seems that shorter and shorter cert lifetimes might put more strain on a service that nigh everyone seems to just be using for free.
Edit: at least there are a lot of prominent companies here https://letsencrypt.org/sponsors/
boringproxy needs to provide a callback redirect_uri to the oauth server in order to retrieve it's token, which it can then use for setting DNS records. However, it can't provide an HTTPS endpoint until it can set up those DNS records and get a cert. Chicken/egg. Currently the spec requires the server to implement a `GET /temp-domain` endpoint which creates a DNS record like 157-245-231-242.example.com which points at the client's IP. This lets boringproxy bootstrap a secure OAuth2 callback endpoint.
IP certs would remove an entire step from this process.
[0]: https://github.com/takingnames/namedrop-protocol-spec
[1]: This is actually broken in boringproxy at the moment, but there's a demo video here: https://www.youtube.com/watch?v=9hf72-fYTts
I am gonna try to run a DoH resolver on this and see how it goes.
I remember calling Clint and Jeremy at DigiCert and asking: "hey we have this cool IP address—what are the odds you guys can issue a certificate for it?"
I'm not sure if they had to dust off some code or process to do it, but they got it done really quickly once the demonstration of control was handled.
Because if zero pages load, but that one does, the issue is DNS.
Ping is easy too of course, but I can ask people to type four ones with periods between into their search bar over the phone. No command line required.
https://community.letsencrypt.org/t/post-to-new-order-url-fa...
If they do start providing 6-day certs I hope their turnaround on issue reports is faster than that (and ideally have something better for reporting issues than a community forum where you have to suffer clueless morons spamming your thread).
That, and extended week-long outages are extremely unlikely.
You only need the outage to last for the window of [begin renewal attempts, expiration], not the entire 6d lifetime.
For example, with the 90d certs, I think cert-manager defaults to renewal at 30d out. Let's assume the same grace, of ~33% of the total life, for the 6d certs: that means renew at 2d out. So if an outage persisted for 2d, those certs would be at risk of expiring.
https://letsencrypt.org/docs/rate-limits/
For the “exact same set of hostnames” (aka. renewals) the rate limit is 5 certificates every 7 days.
So you could do it every other day, if you can make sure there's only one client doing it.
And they're very clear this is a global limit: creating multiple accounts doesn't subvert it.
So you'll need to manage this centrally, if you have multiple hosts sharing a hostname.
* https://datatracker.ietf.org/doc/draft-aaron-acme-profiles/
The ACME spec is:
I am operating https://www.merklemap.com/ and the current scale is already impressive.
PS. Neat site!
That's what happens - logs are "expired" after a few years. But if you want to have an exhaustive monitor, you probably don't want to discard the records of expired certificates.
> PS. Neat site!
Thank you!
https://letsencrypt.org/2025/01/16/6-day-and-ip-certs/#short...
But... How often do these types of compromises happen? I can't say I've ever seen or heard of it happening.
Is in-addr.arpa. not usable for these purposes? Given how you can do PTR records to map IP address to domain name, I had just assumed it would be at least theoretically usable for more, even if few or no hosts exposed it so at present.
Doesn’t prove you own the thing the IP routes to.
Someone already mentioned that it's needed for Discovery of Designated Resolvers (DDR) for DNS-over-HTTPS. Anything else?
I sometimes deal with a relying party that insists on public CA issued certs for TLS client use, and then makes rotation very painful behind a portal with 2FA etc. This would be fine if public CAs issued certs for 5 years but they seem to be limited to 1 year now because of browser policy.
http://1.1.1.1 redirects to https://1.1.1.1 which then redirects to https://one.one.one.one
but the TLS cert on https://1.1.1.1 (or https://[2606:4700:4700::1111] on ipv6) is still valid for the ipaddress otherwise your browser would put up a warning during the tls handshake.
Also (and just speculating here), it could be they wanted to get away from promoting https://1.1.1.1 because of legacy spam filtering. But that’s just me thinking out loud as to why they would prefer the domain over the ip
(Or I'll switch to a different ACME client I suppose)
1. Lease IP
2. Obtain cert (verify can receive traffic to IP on port 80)
3. Give IP back
4. Cloud provider gives IP to another customer
5. Bgp attack IP with 6 days.
While I support the idea of IP certs I do wonder how thought through this is and what the future consequences for security are.
I agree with another commenter here who said this should be limited to IPs behind RPKI.
Possibly also needs a mechanism for IP owners to clamp the cert time to be below their IP re-lease policy. As an example a provider like AWS could require max certs of (say) 6 hours and ensure any returned IPs stay unleased for 6 hours before reissuing them)
You've got to be pretty lucky, or do a lot of IP cycling for your vector to be terribly useful. A paranoid user of IP certs would let their new public facing assignments settle for a week before using them; but I suspect few people will start using IP address certs, because of usability.
AFAIK IP address certs would provide a way to create a secure browsing context in your browser, which is required for service worker ('offline' background threads) and some File API, which could open up a new class of programs that host for friends and family.
It does 'leak' your internal host addresses but that shouldn't be an issue.
Same way you can't get a cert for some.name.in-an-internal-domain-we-use-internally
Sure you can, you just have to issue it yourself.
If someone else did this, Mozilla would be threatening to remove them from their trusted roots.
IP address certs sound like a security nightmare that could be subverted by BGP hijacking. Which is why most CAs don't issue them. Does accessing the ACME challenge from multiple endpoints adequately prevent this type of attack?
> Short-lived Subscriber Certificate: For Certificates issued on or after 15 March 2024 and prior to 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 10 days (864,000 seconds). For Certificates issued on or after 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 7 days (604,800 seconds).
[…]
> §7.1.2.11.2 CRL Distribution Points
> The CRL Distribution Points extension MUST be present in: Subordinate CA Certificates; and Subscriber Certificates that 1) do not qualify as “Short-lived Subscriber Certificates” and 2) do not include an Authority Information Access extension with an id-ad-ocspaccessMethod.
* https://cabforum.org/working-groups/server/baseline-requirem...
OCSP does not seem to be mandated in the latest Base Requirements.
The attack scenario is exactly the same as hostname certificates, which are often validated by HTTP or TLS ACME challenges.
> Does accessing the ACME challenge from multiple endpoints adequately prevent this type of attack?
Yes. You'd essentially have to MitM all traffic towards the IP for it to work, and with more and more networks rolling out BGP origin validation a global BGP hijack becomes harder and harder to pull off.
You'd still be in trouble if you expect your own ISP to be hostile, of course. Don't single-home with an ISP you don't trust, or stick with domain name certs and force DNS challenges.