I wonder if the support made it to Caddy yet

(seems to be WIP https://github.com/caddyserver/caddy/issues/7399)

OpenSSL is quite particular about the IP address being included in the SAN field of the cert when making a TLS connection, fwiw. iOS engineers may not have explicitly added this requirement and it might just be a side effect of using a crypto library.

I use DoH behind a reverse proxy with my own domain daily without any kind of issue

> 8 lets me refresh weekly and have a fixed day of the week to check whether there was some API 429 timeout

There’s your answer.

6 days means on a long enough enough timeframe the load will end up evenly distributed across a week.

8 days would result in things getting hammered on specific days of the week.

Worry not, cause it's not 6 days (144 hours), it is 6-ish days: 160 hours

And 160 is the sum of the first 11 primes, as well as the sum of the cubes of the first three primes!

Because it allows to you to work for six days, and rest on the seventh. Like God did.

It's actually 6 and 2/3rds! I'm trying to figure out a rationale for 160 hours and similarly coming up empty, if anyone knows I'd be interested.

200 would be a nice round number that gets you to 8 1/3 days, so it comes with the benefits of weekly rotation.

The are some great points

'Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names'

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

* https://acmeforonions.org

* https://onionservices.torproject.org/research/appendixes/acm...

But isn't it unnecessary to use https, since tor itself encrypts and verifies the identity of the endpoint?

Some ACME clients that I think currently support IP addresses are acme.sh, lego, traefik, acmez, caddy, and cert-manager. Certbot support should hopefully land pretty soon.

IPSec is terrible, huge, and messy standard that company that made it took 20 years to stop getting CVE every year

The short-lived requirement seems pretty reasonable for IP certs as IP addresses are often rented and may bounce between users quickly. For example if you buy a VM on a cloud provider, as soon as you release that VM or IP it may be given to another customer. Now you have a valid certificate for that IP.

6 days actually seems like a long time for this situation!

The push for shorter and shorter cert lifetimes is a really poor idea, and indicates that the people working on these initiatives have no idea how things are done in the wider world.

It's less about IP address transience, and more about IP address control. Rarely does the operator of a website or service control the IP address. It's to limit the CA's risk.

> Are IP addresses more transient than a domain within a 45 day window?

If I don't assign an EIP to my EC2 instance and shut it down, I'm nearly guaranteed to get a different IP when I start it again, even if I start it within seconds of shutdown completing.

It'd be quite a challenge to use this behavior maliciously, though. You'd have to get assigned an IP that someone else was using recently, and the person using that IP would need to have also been using TLS with either an IP address certificate or with certificate verification disabled.

What worries me more about the push for shorter and shorter cert terms instead of making revoking that works is that if provider fails now you have very little time to switch to new one

If you are doing this in a commercial context and the 4 day debugging window, or any downtime, would cause you more costs than say, buying a 1 year certificate from a commercial supplier, then that might be your answer there...

>I won't have time to fix this

Which should push you to automate the process.

I recently migrated to a wildcard (*.home.example.com) certificate for all my home network. Works okay for many parts. However requires a public DNS server where TXT records can be set via API (lego supports a few DNS providers out of the box, see https://go-acme.github.io/lego/dns/ )

One can also use a private CA for that scenario.

I mean if it's not routable how do you want to prove ownership in a way nobody else can? Just make a domain name.

One thing this can be useful for is encrypted client hello (ECH), the way TLS/HTTPS can be used without disclosing the server name to any listening devices (standard SNI names are transmitted in plaintext).

To use it, you need a valid certificate for the connection to the server which has a hostname that does get broadcast in readable form. For companies like Cloudflare, Azure, and Google, this isn't really an issue, because they can just use the name of their proxies.

For smaller sites, often not hosting more than one or two domains, there is hardly a non-distinct hostname available.

With IP certificates, the outer TLS connection can just use the IP address in its readable SNI field and encrypt the actual hostname for the real connection. You no longer need to be a third party proxying other people's content for ECH to have a useful effect.

The July announcement for IP address certs listed a handful of potential use cases: https://letsencrypt.org/2025/07/01/issuing-our-first-ip-addr...

No dependency on a registrar sounds nice. More anonymous.

Yeah actually seems pretty useful to not rely on the name server for something that isn't human facing.

> I am guessing the use case for ip address certs is so your ephemeral services can do TLS communication

There's also this little thing called DNS over TLS and DNS over HTTPS that you might have heard of ? ;)

Maybe you want TLS but getting a proper subdomain for your project requires talking to a bunch of people who move slowly?

That is a very old article that seems to be outdated now.

It's a requirement from the Chrome root program. This page is probably the best resource on why they want this: https://googlechrome.github.io/chromerootprogram/moving-forw...

Because Google doesn't want anyone using PKI for anything but simple websites

One reason is that the client certificate with id-kp-clientAuth EKU and a dNSName SAN doesn't actually authenticate the client's FQDN. To do that you'd have to do something of a return routability check at the app layer where the server connects to the client by resolving its FQDN to check that it's the same client as on the other connection. I'm not sure how seriously to take that complaint, but it's something.

* DoT/DoH

* An outer SNI name when doing ECH perhaps

* Being able to host secure http/mail/etc without being beholden to a domain registrar

No, they will only give out certificates if you can prove ownership of the IP, which means it being publicly routable.

Browsers consider ‘localhost’ a secure context without needing https

For local /network/ development, maybe, but you’d probably be doing awkward hairpin natting at your router.

What's stopping you from creating a "localhost.mydomain.com" DNS record that initially resolves to a public IP so you can get a certificate, then copying the certificate locally, then changing the DNS to 127.0.0.1?

Other than basically being a pain in the ass.

No additional risk IMHO. If you can hijack my service IPs, you can establish control over the IPs or the domain names that point to them. (If you can hijack my DNS IPs, you can often do much more... even with DNSSEC, you can keep serving the records that lead to IPs you hijacked)

We've supported it for about a year!

https://caddy.community/t/doubt-about-the-new-lets-encrypt-c...

With a 6 day lifetime you'd typically renew after 3 days. If Lets Encrypt is down or refuses to issue then you'd have to choose a different provider. Your browser trusts many different "top of the chain" providers.

With a 30 day cert with renewal 10-15 days in advance that gives you breathing room

Personally I think 3 days is far too short unless you have your automation pulling from two different suppliers.

Domains map one-to-one with registrars, but multiple AS can be using the same IP address.

Would be cool. But since they’re a non-profit, they would need some way to make it scalable.

1) For better or worse, code signing certificates are expected to come with some degree of organizational verification. No one would trust a domain-validated code signing cert, especially not one which was issued with no human involvement.

2) App stores review apps because they want to verify functionality and compliance with rules, not just as a box-checking exercise. A code signing cert provides no assurances in that regard.