Let's Encrypt is offering 6-day and IP address certs

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.

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

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.

Meanwhile Qualsys has a “vulnerability scanner” that says a certificate that expires in under a month is a level 1 vulnerability(ID #38174): https://docs.qualys.com/en/certview/latest/get_started/certv...

>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.

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?

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:

* https://datatracker.ietf.org/doc/html/rfc8555

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.

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.

What's the end goal here? A new cert per connection? I think if, hypothetically, that were the case, where Let's Encrypt validates the domain owner on every connection, then that'd move the attack surface from trying to get private cert keys to... other attacks, in general. Is there reason to believe that "other attacks" are less likely? Have there been many cases of should-have-been-revoked certs being used improperly?

> The dns-01 challenge type will not be available because the DNS is not involved in validating IP addresses. Additionally, there is no mechanism to check CAA records for IP addresses.

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.

What are reasons to use a certificate for an IP? Why wouldn't you use a name?

Someone already mentioned that it's needed for Discovery of Designated Resolvers (DDR) for DNS-over-HTTPS. Anything else?

While we're on the subject of cert lifetimes. Is there a longer lived, public CA-issued cert for TLS client purposes?

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.

How are IP certs any good in the days of cloud? I presume they are used in instances where it’s tied to a “well known” ip?

Will this work for IPv6?

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)

If I wanted to get a cert for an IP address today, what the cheapest CA?

Six days? I can't even set the cron job to weekly. Maybe that is the point of this though from being on call I really hate thing restarting every day. Caddy, Nginx, HAProxy, and IIS all seem to handle certs without a full restart. MS SQL Server, nope.

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)

Curiosity killed the cat: is it possible to get a valid cert for IPs on private LANs, like for example 192.168.1.42 or 10.0.0.84?

> Our six-day certificates will not include OCSP or CRL URLs.

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?