Pebble already supports both profiles and IP identifiers in certificates.
3 Likes
Will any LetsEncrypt rate limits be adjusted as a result of this or will there possibly be separate higher rate limits for 6-day certificates?
Is certbot "ready" for 6-day certificates? I think it doesn't yet have the profile selection mechanism but does it have the logic for determining when certificate renewal should be attempted? At how many days left will it start attempting renewal? Also the certbot.timer service normally runs twice a day to check if any certificates are ready for renewal, does this potentially need to be increased for short-lived certificates to allow a decent number of attempts before expiration, in case there are transient renewal problems?
We will re-evaluate rate limits to make sure they are applicable.
3 Likes
Yes, I've now implemented initial profiles support and the whole thing was a few lines of code, so no issue. The profiles map directly to a Dictionary<string,string> collection in dotnet.
In my particular implementation if a CA no longer supports a profile at the time of the order (or the CA has changed due to fallback or other changes) the order will (by default) continue without the profile. Potentially controversial, but we can make it optional.
3 Likes
IPv4 address certificates will break NAT64/DNS64 and other schemes where the apparent view of DNS to the client does not match real DNS.
I did some tests a while ago in a network environment where domain names work but not IP literals. If we had certificates for IP literals, then even if the site we want to access is by domain name, and it had some resource on it (image, script, etc.) which is accessed by IP literal, then it would break in such an environment.
@phjarea217 But no certificate breaks it too, so not sure what your point is 
Also, IPv6 transition mechanisms anno 2025?
2 Likes
The user or browser would have to access the site in question by IP literal rather than domain name, which breaks NAT64/DNS64 without a CLAT since the IP literal is not translated to using the nat64 prefix.
Why would a user need to do that?
The user might not do it directly, but it might be accessed by way of a source URL of an image, script, stylesheet, XMLHttpRequest, or similar on another website which would likely be accessed by domain name. With IP address certificates, this might become more commonly seen, especially for those who have a dedicated server like a VPS and who might be too lazy to set up DNS.
Browsers currently would already mark such a connection as "unsafe", as currently no certificates would be configured at all.
I'm pretty sure website operators are not thinking like: "Now that IP certificates are possible, I'm going to use IP addresses instead of hostnames". Thus I don't see the regression part of this at all. As that's the only scenario that I could think of with current websites.
Of course for new websites this might be different. But what are the chances of a NAT64/DNS64 user visiting a new website that choose to use HTTPS IP address URIs where it also could have used a hostname?
Also, how many NAT64/DNS64 users are out there? It's 2025.. Surely those IPv6 transition mechanisms aren't that popular any longer, right?
Apparently in the Ungleich IPv6 chat (https://ipv6.chat), we have users who are using NAT64/DNS64 to reduce the burden of having to assign IPv4 addressing to devices in their local network, yet they still want to access IPv4 sites. T-Mobile at least also uses NAT64/DNS64 with a CLAT, which at least makes the IPv4 literals work correctly, but it creates some level of overhead, especially if done by a network interception rather than modifying connect calls in the socket API.
Additionally, web developers might not quite understand the difference between an IP literal URL and a domain name URL. This may occur if a content provider asks a website maintainer to embed some script into their website, and that script is referenced by a URL containing an IP literal. They appear to work correctly on dual-stack or IPv4-only networks, but they break on IPv6-only or NAT64/DNS64 networks. Sure, with Android or iOS apps this might not be a problem, as I've heard that the app still has to work on a NAT64/DNS64 network to be in the app store. But this is not necessarily guaranteed for general websites.
Probably more and more actually, as more networks are becoming IPv6-only (internally), but still need to connect to legacy IPv4-only endpoints on the Internet.
Fair enough. But still, it would only apply to websites where a new IP address URI with the HTTPS scheme would be introduced, as current IP address URIs would be without certificates anyway and thus already give an "unsafe" warning.
Thus this is a good warning for website operators to not use HTTPS IP address certificates on websites that are accessed by hostname. Not a reason not to introduce such certificates
2 Likes
Yeah, I've been thinking literal IP in certs was for "specialized" services like DoH. And, given they will be 6-day certs the admin better have good fallback CA or vigorous monitoring. Some notes about "good" and "bad" practices probably warranted when the "profiles" are introduced.
4 Likes
To be clear, I wasn't suggesting that there should not be IP certificates. But if they are used in the wrong way, then it might be an impediment to IPv6 transition mechanisms.
For example, IPv6 literal certificates could be used to create valid certificates for local networks, provided that it runs on globally unique IP addressing, without having to register a domain name. And fc00::/8 might actually be eventually allocated for the purposes of obtaining certificates for anyone who doesn't have IPv6. And as you said, DNS-over-HTTPS services (though the server IP could be bootstrapped by directly querying root nameservers and validating against the DNSSEC root trust anchor).
@Osiris what kind of transition mechanisms do you anticipate being used nowadays in 2025?
IPv4 address certificates will break NAT64/DNS64
Using DNS64 implies that the browser will be connecting via a name, in which case they won't rely on an IP certificate, and shouldn't be impacted by this.
You're right that trying to make a TLS connection to a NAT64 address won't work if a host is serving an IPv4 certificate. That also doesn't work today, as that same host won't have any IP certificate. But also seems unlikely - wouldn't most use of NAT64 come via DNS64?
The most common, to my knowledge, transitional technology deployed is 464xlat. As I understand it, outgoing IPv4 packets are NATed locally into IPv6, traverse an IPv6-only network, and then are NAT64'ed again on egress. In that case, the application making the IPv4 connection (such as a browser) sees a normal IPv4 connection, and an IP certificate will still work as expected.
So the only case that's broken is when a TLS client tries to make a direct connection to a NAT64 address. I believe that to be uncommon, and don't think there's much that can be done about that use-case. And just to reiterate, that use doesn't work today.
3 Likes
There are networks with NAT64/DNS64, but where CLAT support is not universal. NAT64/DNS64 without CLAT has the advantage that it is deployable with many different types of clients transparently, without having to change the client to install a CLAT.
In particular, in NAT64 / DNS64 networks without a CLAT, it might be useful due to IPv4 address exhaustion in the public Internet, to create a private IPv4 internet whose addressing space is completely unrelated to that of the real Internet (i.e. controlled by IANA/RIPE/AFRINIC/APNIC/ARIN/LACNIC). The idea is that you could e.g. squat on a public IP like 1.1.1.1, and if you wanted to access the real 1.1.1.1, you would have to use the NAT64 prefix.
The squatting of IPv4 space is primarily intended for devices which are IPv4-only but want to connect to IPv6-only websites.
Looking forward to being able to use IP addresses in certificates, but I have two questions about it:
The blog post states that for wildcard certs I have to use DNS-01, and for IP certs I have to use HTTP-01 or TLS-ALPN-01. Will it be possible (or is it already possible?) to combine two verification methods in one certificate request, so I can request a certificate that is both valid for *.example.com and for my IPv4 and IPv6 addresses?
Also, is there a reason why DNS-01 will not be allowed to prove ownership of IP addresses? The blog post just states "The dns-01 challenge type will not be available because the DNS is not involved in validating IP addresses." but that doesn't really explain why you don't involve DNS in validating IPs.
Quite a few providers delegate your IP network's reverse lookup to you or to a DNS server you control, so there's really no reason to not allow it as an option, right?
If I get allocated the network 2001:db8::/32 from my provider then the provider might give me access to the whole 8.b.d.0.1.0.0.2.ip6.arpa zone. So if someone requests a certificate that's valid for the IP 2001:db8::4321:1, Lets Encrypt could just check the DNS record at _acme-challenge.1.0.0.0.1.2.3.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa and see if it resolves properly.
Sure, not everyone will be able to use this method as not everyone gets their reverse IP zones delegated to them. If that's the case they can still use one of the other methods. But is there a reason not to allow it for people that do have access to their reverse zones?
The ACME protocol supports this, yes. However, not all ACME clients are capable of supporting multiple challenge types in a single certificate.
4 Likes