Comment by iamrobertismo
2 days ago
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.
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.
That doesn't work, as neither SNI nor the server_name field of the ECHConfig are allowed to contain IP addresses: https://www.ietf.org/archive/id/draft-ietf-tls-esni-25.html#...
Even if it did work, the privacy value of hiding the SNI is pretty minimal for an IP address that hosts only a couple domains, as there are plenty of databases that let you look up an IP address to determine what domain names point there - e.g. https://bgp.tools/prefix/18.220.0.0/14#dns
I don't really see the value in ECH for self-hosted sites regardless. It works for Cloudflare and similar because they have millions of unrelated domains behind their IP addresses, so connecting to their IPs reveals essentially nothing, but if your IP is only used for a handful of related things then it's pretty obvious what's going on even if the SNI is obscured.
As far as I understand you cannot use IP address as the outer certificate as per https://www.ietf.org/archive/id/draft-ietf-tls-esni-25.txt
> In verifying the client-facing server certificate, the client MUST interpret the public name as a DNS-based reference identity [RFC6125]. Clients that incorporate DNS names and IP addresses into the same syntax (e.g. Section 7.4 of [RFC3986] and [WHATWG-IPV4]) MUST reject names that would be interpreted as IPv4 addresses.
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...
Thanks! This is helpful to read.
No dependency on a registrar sounds nice. More anonymous.
> No dependency on a registrar sounds nice.
Actually the main benefit is no dependency on DNS (booth direct and root).
IP is a simple primitive, i.e. "is it routable or not ?".
The popular HTTP validation method has the same drawback whether using DNS or IP certificates? Namely, if you can compromise routes to hijack traffic, you can also hijack the validation requests. Right?
2 replies →
IP addresses also are assigned by registrars (ARIN in the US and Canada, for instance).
> IP addresses also are assigned by registrars (ARIN in the US and Canada, for instance).
To be pedantic for a moment, ARIN etc. are registries.
The registrar is your ISP, cloud provider etc.
You can get a PI (Provider Independent) allocation for yourself, usually with the assistance of a sponsoring registrar. Which is a nice compromise way of cutting out the middleman without becoming a registrar yourself.
2 replies →
Arguably neither is particularly secure, but you must have an IP so only needing to trust one of them seems better.
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 ? ;)
I don't quite understand how this relates?
Currently when you configure DNS over TLS/HTTPS you have to set the IP address AND the hostname of the SSL certificate used to secure the service. Getting IP Address certs makes the configuration simpler
> I don't quite understand how this relates?
Erm ? Do I have to spell out that I was pointing out that there was more than the "ephemeral services" that were being guessed at that could take advantage of IP certs ?
Maybe you want TLS but getting a proper subdomain for your project requires talking to a bunch of people who move slowly?
Very very true, never thought about orgs like that. However, I don't think someone should use this like a bandaid like that. If the idea is that you want to have a domain associated with a service, then organizationally you probably need to have systems in place to make that easier.
Ideally, sure. But in some places you're what you're proposing is like trying to boil the oceans to make a cup of tea
VBA et al succeeded because they enabled workers to move forward on things they would otherwise be blocked on organizationally
Also - not seeing this kind of thing could be considered a gap in your vision. When outsiders accuse SV of living in a high-tech ivory tower, blind to the realities of more common folk, this is the kind of thing they refer to.
1 reply →