Six day and IP address certificate options in 2025
64 comments
·January 16, 2025rickette
ryandrake
To someone like me with hobby-level serving needs, the 90 day certificate life is pretty inconvenient, despite having automation set up. I run a tiny VPS that hosts basic household stuff like e-mail and a few tiny web sites for people, and letsencrypt/certbot automation around certificate renewal is the only thing that I seem to need to regularly babysit and log in to manually run/fix. Everything else just hums along, but I know it's been 90 days because I suddenly can't connect to my E-mail or one of the web virtual hosts went down again. And sure enough, I just need to run certbot renew manually or restart lighttpd or whatever.
jeroenhd
Let's Encrypt doesn't work great when the Let's Encrypt client software has a bug or is misconfigured (one of those is true for your situation).
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.
eikenberry
I also use Certbot (v2.1.0) for my small VPS/hobby setup (www + email) and I haven't had to mess with it since I set it up in 2021. Just adding another data point so you know it doesn't have to be painful. I'll be happy to help, just drop me a line.
Dries007
For me it's only ever an issue if I stop renewing a domain, which triggers issues somewhere next renewal and now nginx doesn't reload.
Other than that, I've never had to babysit certbot. It's just a systemd timer job.
null
rfoo
... which means automation was not setup correctly and 90 days is still too long that you just tolerated it. If it was 6 days after a few turns you would have decided "fuck it I'm going to spend time fixing it once and for all".
jonas21
Or perhaps, "I'm going to give up and switch to gmail once and for all"
likeabatterycar
These are the attitudes we get when we have a WebPKI cabal drunk on power.
duskwuff
When Let's Encrypt got started in 2014, CAs could issue certificates valid for up to five years - and many did. The CA/Browser Forum has slowly been ratcheting that down.
crtasm
>We expect to issue the first valid short-lived certificates to ourselves in February of this year. Around April we will enable short-lived certificates for a small set of early adopting subscribers. We hope to make short-lived certificates generally available by the end of 2025.
ray_v
This feels like a disaster waiting to happen -- like what happens if (when?) Let's Encrypt suffers a significant outage and sites can't refresh certificates? Do we just tolerate a significant portion of the Internet being down or broken due to expired certificates? And for what tradeoff? A very small amount of extra security? Is this because certificate revocation is a harder problem to solve / implement at Internet scale?
arianvanp
A 7 day outage seems rather unlikely no?
everfrustrated
It feels like there's something of an attack vector here with cloud providers who lease IPs for hours at a time.
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)
toast0
If you control the IP or domain via a BGP hack, you can get a certificate issued while you control it, as long as you control it from the perspective of their CA.
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.
athrowaway3z
I wouldn't write off the use of IP certs just yet.
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.
Retr0id
You can do the same BGP attacks with regular domain certs, though. If you hijack the IP that a domain resolves to, you can answer HTTP-01 challenges.
null
phasmantistes
This is exactly why the LE IP certs will be limited to 6 days: this exact attack is possible today against any IP address cert, and such certs in general are allowed to have lifetimes up to 398 days. LE isn't comfortable with that situation, so IP certs will have the shortest feasible lifetimes.
apitman
IP certs improve a niche but interesting use case for me. I run a domain registrar that implements a simple OAuth2 protocol[0] for delegating domains/subdomains. I also have an open source tunneling tool called boringproxy that implements the client side of this protocol[1].
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
captn3m0
I remember being surprised when Cloudflare launched https://1.1.1.1 with a valid cert and I immediately wanted one, but couldn’t find an easy way to get one.
I am gonna try to run a DoH resolver on this and see how it goes.
prdonahue
This was a fun conversation.
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.
yegle
For others who don't know how certificate for IP addresses relates to a DNS-over-HTTPS server: https://blog.cloudflare.com/announcing-ddr-support/
throw0101c
Note that ACME profiles are new, to the extent that the draft spec is (a) personal (and not prefixed with draft-ietf…), and (b) currently versioned -00:
* https://datatracker.ietf.org/doc/draft-aaron-acme-profiles/
The ACME spec is:
mholt
Yeah... thankfully, it's "pretty simple" for clients to implement. Just add a JSON field to your payload and that's it. (There's a little bit of error checking logic and input validation, like making sure the value is valid, but overall it's not too complex, unlike ARI, which is much more work.)
blakesterz
I don't disagree with anything they say here:
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.
mholt
That's the thing. We don't always know. Hence the need to reduce the attack lifetime.
H8crilA
Impossible to say, as most people probably don't even know that their private key is stolen. I've personally seen it only once on a real certificate revocation. Yet another reason to have shorter lifespan.
yjftsjthsd-h
If they don't know they were breached, don't the odds favor the replaced key likewise getting re-stolen immediately?
H8crilA
Yes, but the odds are less than infinite, i.e. the probability is less than 1.0. At least some of such attacks take effort.
Spivak
It's a pretty narrow threat model for Alice to get her cert stolen by Bob, be completely unaware that this has happened, and the means Bob used only works once.
toast0
I had to get certificates revoked for HeartBleed. :P
ikiris
Often enough a protocol was made to deal with it. The compromises have mostly been kept quiet though or at least didn’t get much news traction.
Eikon
This will get interesting for many CT transparency monitors which for many are already seeing scalability issues.
I am operating https://www.merklemap.com/ and the current scale is already impressive.
mmastrac
Will this work for IPv6?
ZiiS
Yes, a forward looking org like Let's Encrypt would have said IPv4 if needed. Here is an example from Cloudflare https://[2606:4700:4700::1111]
wil421
Why does the url say one.one.one.one in my browser?
Crosseye_Jack
Because your are redirected to one.one.one.one via the location header and 301 status code from the ip address.
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.
mparlane
Because it returns a 301 moved permanently with a header of location: https://one.one.one.one/
null
Retr0id
If I wanted to get a cert for an IP address today, what the cheapest CA?
dextercd
I'm very interested in trying this. acme.sh is planning to support certificate profiles, so hopefully that'll be ready when LE's short-lived certificates become available.
(Or I'll switch to a different ACME client I suppose)
mholt
Caddy/CertMagic/ACMEz already support this in the latest commits. Should be ready in time for the production rollout!
Kinda funny to call the current 90 day certs "long lived". When Let's Encrypted started out more than 10 years ago most certs from major vendors had a 1 year life span. Let's Encrypt was (one of) the first to use drastically shorter life spans, hence all the ACME automation effort.