As already noted on this thread, you can't use certbot today to get an IP address certificate. You can use lego [1], but figuring out the exact command line took me some effort yesterday. Here's what worked for me:

    lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived

[1] https://go-acme.github.io/lego/

IP address certificates are particularly interesting for iOS users who want to run their own DoH servers.

A properly configured DoH server (perhaps running unbound) with a properly constructed configuration profile which included a DoH FQDN with a proper certificate would not work in iOS.

The reason, it turns out, is that iOS insisted that both the FQDN and the IP have proper certificates.

This is why the configuration profiles from big organizations like dns4eu and nextdns would work properly when, for instance, installed on an iphone ... but your own personal DoH server (and profile) would not.

Why 6 day and not 8?

- 8 is a lucky number and a power of 2

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

- 6 is the value of every digit in the number of the beast

- I just don't like 6!

Next, I hope they focus on issuing certificates for .onion addresses. On the modern web many features and protocols are locked behind HTTPS. The owner of a .onion has a key pair for it, so proving ownership is more trustworthy than even DNS.

For people who want IP certificates, keep in mind that certbot doesn't support it yet, with a PR still open to implement it: https://github.com/certbot/certbot/pull/10495

I think acme.sh supports it though.

I wonder if transport mode IPsec can be relevant again if we're going to have IP address certificates. Ditto RFC 5660 (which -full disclosure- I authored).

I have now implemented a 2 week renewal interval to test the change to the 45 days, and now they come with a 6-day certificate?

This is no criticism, I like what they do, but how am I supposed to do renewals? If something goes wrong, like the pipeline triggering certbot goes wrong, I won't have time to fix this. So I'd be at a two day renewal with a 4 day "debugging" window.

I'm certain there are some who need this, but it's not me. Also the rationale is a bit odd:

> IP address certificates must be short-lived certificates, a decision we made because IP addresses are more transient than domain names, so validating more frequently is important.

Are IP addresses more transient than a domain within a 45 day window? The static IPs you get when you rent a vps, they're not transient.

IP addresses must be accessible from the internet, so still no way to support TLS for LAN devices without manual setup or angering security researchers.

This is interesting, I am guessing the use case for ip address certs is so your ephemeral services can do TLS communication, but now you don't need to depend on provisioning a record on the name server as well for something that you might be start hundreds or thousands of, that will only last for like an hour or day.

Very excited about this. IP certs solve an annoying bootstrapping problem for selfhosted/indiehosted software, where the software provides a dashboard for you to configure your domain, but you can't securely access the dashboard until you have a cert.

As a concrete example, I'll probably be able to turn off bootstrap domains for TakingNames[0].

[0]: https://takingnames.io/blog/instant-subdomains

Has anyone actually given a good explanation as to why TLS Client Auth is being removed?

Do I understand correctly: would someone have a concrete example of URL which is both an IP address and HTTPS, widely accessible from global internet? e.g. https://<ipv4-address>/ ?

How are IP address certificates useful?

What is a good use case for an IP address certificate for the average company? Say, e-commerce or SaaS-startup?

If I can use my DHCP assigned IP, will this allow me to drop having to use self-signed certificates for localhost development?

This comment used to say that was in staging only. (Nevermind, i was confused following the links from original article)

I guess IP certs won't really be used for anything important, but isn't there a bigger risk due to BGP hijacking?

undefined

Does anyone know when Caddy plans on supporting this?

Honestly not a big fan of IP address certs in the context of dynamic IP address generation

Something about a 6 day long IP address based token brings me back to the question of why we are wasting so much time on utterly wrong TOFU authorization?

If you are supposed to have an establishable identity I think there is DNSSEC back to the registrar for a name and (I'm not quite sure what?) back to the AS.for the IP.

This sounds like a very good thing, like a lot of stuff coming from letsencrypt.

But what risks are attached with such a short refresh?

Is there someone at the top of the certificate chain who can refuse to give out further certificates within the blink of an eye?

If yes, would this mean that within 6 days all affected certificates would expire, like a very big Denial of Service attack?

And after 6 days everybody goes back to using HTTP?

Maybe someone with more knowledge about certificate chains can explain it to me.

[dead]

It's a huge ask, but i'm hoping they'll implement code-signing certs some day, even if they charge for it. It would be nice if appstores then accepted those certs instead of directly requiring developer verification.