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
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.
It would give you a certificate chain which may authenticate the onion service as being operated as who it purports to. Of course, depending on context, a certificate that is useful for that purpose might itself be too much if an information leak
DV certificates (that lets encrypt) provides offer no verification of the owner. EV certificates for .onion could be actually useful though, but one generally has to pay for EV cert.
For example HTTP/2 and HTTP/3 require HTTPS. While technically HTTPS is redundant, .onion sites should avoid requiring browsers to add special casing for them due to their low popularity compared to regular web sites.
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).
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.
cert-manager maintainter chiming in to say that yes, cert-manager should support IP address certs - if anyone finds any bugs, we'd love to hear from you!
We also support ACME profiles (required for short lived certs) as of v1.18 which is our oldest currently supported[1] version.
We've got some basic docs[2] available. Profiles are set on a per-issuer basis, so it's easy to have two separate ACME issuers, one issuing longer lived certs and one issuing shorter, allowing for a gradual migration to shorter certs.
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.
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.
For ipv6 proof of ownership can easily be done with an outbound connection instead. And would work great for provisioning certs for internal only services.
Also I don't see the point of what TLS is supposed to solve here? If you and I (and everyone else) can legitimately get a certificate for 10.0.0.1, then what are you proving exactly over using a self-signed cert?
There would be no way of determining that I can connecting to my-organisation's 10.0.0.1 and not bad-org's 10.0.0.1.
This is assuming NAT, with IPv6 you should be able to have globally unique IPs. (Not unique to IPv6 in theory, of course, but in practice almost no one these days is giving LAN devices public IPv4s).
The identifier would be generated by the certificate authority upon your first request for a certificate, and every time you renew you get to keep the same one.
I see what you're getting at - but to me this sounds almost exactly like just using DNS, even if the (A/AAAA) record you want to use resolves to an un-routable address: https://letsencrypt.org/docs/challenge-types/#dns-01-challen... - you just create a DNS TXT record instead of them trying to access a server at the address for verification.
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.
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.
For better or worse the push down to 47-day certificates is an industry-wide thing, in a few years no provider will issue certificates for longer than that.
Nobody is being forced to use 6-day certs for domains though, when the time comes Let's Encrypt will default to 47 days just like everyone else.
What does attestation mean in this context? The point of the Web PKI is to provide consistent cryptographic identity for online resources, not necessarily trustworthy ones.
(The classic problem with self-signed certs being that TOFU doesn’t scale to millions of users, particularly ones who don’t know what a certificate fingerprint is or what it means when it changes.)
Though if I may put on my tinfoil hat for a moment, I wonder if current algorithms for certificate signing have been broken by some government agency or hacker group and now they're able to generate valid certificates.
But I guess if that were true, then shorter cert lives wouldn't save you.
One of the ideas behind short-lived certificates is to put certificate lifetimes within the envelope of CRL efficacy, since CRLs themselves don’t scale well and are a significant source of operational challenges for CAs.
This makes sense from a security perspective, insofar as you agree with the baseline position that revocations should always be honored in a timely manner.
I'm not sure it is about security. For security, CRLs and OCSP were a thing from the beginning. Short-lived certificates allow to cancel CRLs or at least reduce their size, so CA can save some expenses (I guess it's quite a bit of traffic for every client to download CRLs for entire letsencrypt).
> broken by some government agency or hacker group
Probably not. For browsers to accept this certificate it has to be logged in a certificate transparency log for anyone to see, and no such certificates have been seen to be logged.
My browser on my work laptop has 219 root certificates trusted. Some of those may be installed from my employer, but I suspect most of them come from MS as it's Edge on Windows 11. I see in that list things like "Swedish Government Root Authority" "Thailand National Root Certification Authority" "Staat der Nederlanden Root CA" and things like "MULTICERT Root Certification Authority" "ACCVRAUZ1". I don't think there is any reason to believe any certificate. If a government wants a cert for a given DNS they will get it, either because they directly control a trusted root CA, or because they will present a warrant to a company that wants to do business in their jurisdiction and said company will issue the cert.
TLS certs should be treated much more akin to SSH host keys in the known hosts file. Browsers should record the cert the first time they see it and then warn me if it changes before it's expiration date, or some time near the expiration date.
Certificate transparency effectively means that any government actually uses a false certificate on the wider web and their root cert will get revoked.
Obviously you might still be victim #1 of such a scheme... But in general the CA's now aren't really trusted anymore - the real root of trust is the CT logs.
>> TLS certs should be treated much more akin to SSH host keys in the known hosts file. Browsers should record the cert the first time they see it and then warn me if it changes before it's expiration date, or some time near the expiration date.
This is great, and actually constructive!
I use, a hack i put together
http://www.jofla.net/php__/CertChecker/
to keep a list (in json) of a bunch of machines (both https and SSH) and the last fingerprints/date it sees.
Every time it runs i can see if any server has changed, just is a heads-up for any funny business.
Sure its got shortcommings, it doesnt mimmic headers and such but its a start.
It would be great if browsers could all, you know, have some type of distributed protocol, ie DHT where by at least some concensus about whether this cert has been seen by me or enough peers lately.
Having a ton of CAs and the ability to have any link in that chain sing for ANY site is crazy, and until you've seen examples of abuse you assume the foundations are sound.
Thing is, NOTHING, is stopping anyone from already getting short lived certs and being 'proactive' and rotating through. What it is saying is, well, we own the process so we'll make Chrome not play ball with your site anymore unless you do as we say...
The CA system has cracks, that short lived certs don't fix, so meanwhile we'll make everyone as uncomfortable as possible while we rearrange deck chairs.
> 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.
It's probably not a good solution if you're dealing with clients you control.
Otoh, if you're dealing with browsers, they really like WebPKI certs, and if you're directing load to specific servers in real time, why add DNS and/or a load balancer thing in the middle?
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.
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...
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.
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.
> 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 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?
> 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.
You can also become a registrar yourself - at least, RIPE allows it. However, fees are significantly higher and it's not clear why you'd want to, unless you were actually providing ISP services to customers (in which case it's mandatory - you're not allowed to use a PI allocation for that)
The biggest modern-era reason is direct access to update your RPKI entries.
But this only matters if you are doing stuff that makes direct access worthwhile.
If your setup is mostly "set and forget" then you should just accept the lag associated with needing to open a ticket with your sponsor to update the RPKI.
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.
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.
IP addresses arent valid for the SNI used with ECH, even with TLS.
On paper I do agree though it would be a decent option should things one day change there.
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?
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)
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.
Thank you, I missed the part with several "top of the chain" providers. So all of them would need to go down at the same time for things to really stop working.
How many "top of chain" providers is letsencrypt using? Are they a single point of failure in that regard?
I'd imagine that other "top of chain" providers want money for their certificates and that they might have a manual process which is slower than letsencrypt?
But in general, one of the points of ACME is to eliminate dependence on a single provider, and prevent vendor lock-in. ACME clients should ideally support multiple ACME CAs.
For example, Caddy defaults to both LE and ZeroSSL. Users can additionally configure other CAs like Google Trust Services.
“Are they a single point of failure in that regard?”
It depends. If the ACME client is configured to only use Let’s Encrypt, then the answer is yes. But the client could fall-back to Google’s CA, ZeroSSL, etc. And then there is no single point of failure.
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.
Then it would be a grave error to issue an IP cert without active insight into BGP. (Or it doesn't matter which chain you have.. But calling a website from a sampling of locations can't be a more correct answer.)
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.
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.
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:
[1] https://go-acme.github.io/lego/I wonder if the support made it to Caddy yet
(seems to be WIP https://github.com/caddyserver/caddy/issues/7399)
It works, but as another comment mentioned there may be quirks with IP certs, specifically IPv6, that I hope will be fixed by v2.11.
IPv4 certs are already working fine for me in Caddy, but I think there's some kinks to work out with IPv6.
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!
Because it allows to you to work for six days, and rest on the seventh. Like God did.
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.
'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?
It would give you a certificate chain which may authenticate the onion service as being operated as who it purports to. Of course, depending on context, a certificate that is useful for that purpose might itself be too much if an information leak
DV certificates (that lets encrypt) provides offer no verification of the owner. EV certificates for .onion could be actually useful though, but one generally has to pay for EV cert.
For example HTTP/2 and HTTP/3 require HTTPS. While technically HTTPS is redundant, .onion sites should avoid requiring browsers to add special casing for them due to their low popularity compared to regular web sites.
Yes, but browsers moan if you connect to a website without https, no matter if it's on localhost or an onion service.
Tor Browser handles this, it treats `.onion` as a secure context.
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).
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.
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.
cert-manager maintainter chiming in to say that yes, cert-manager should support IP address certs - if anyone finds any bugs, we'd love to hear from you!
We also support ACME profiles (required for short lived certs) as of v1.18 which is our oldest currently supported[1] version.
We've got some basic docs[2] available. Profiles are set on a per-issuer basis, so it's easy to have two separate ACME issuers, one issuing longer lived certs and one issuing shorter, allowing for a gradual migration to shorter certs.
[1]: https://cert-manager.io/docs/releases/ [2]: https://cert-manager.io/docs/configuration/acme/#acme-certif...
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.
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.
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.
For ipv6 proof of ownership can easily be done with an outbound connection instead. And would work great for provisioning certs for internal only services.
Also I don't see the point of what TLS is supposed to solve here? If you and I (and everyone else) can legitimately get a certificate for 10.0.0.1, then what are you proving exactly over using a self-signed cert?
There would be no way of determining that I can connecting to my-organisation's 10.0.0.1 and not bad-org's 10.0.0.1.
This is assuming NAT, with IPv6 you should be able to have globally unique IPs. (Not unique to IPv6 in theory, of course, but in practice almost no one these days is giving LAN devices public IPv4s).
Perhaps by providing some identifier in the URL?
ie. https://10.0.0.1(af81afa8394fd7aa)/index.htm
The identifier would be generated by the certificate authority upon your first request for a certificate, and every time you renew you get to keep the same one.
I see what you're getting at - but to me this sounds almost exactly like just using DNS, even if the (A/AAAA) record you want to use resolves to an un-routable address: https://letsencrypt.org/docs/challenge-types/#dns-01-challen... - you just create a DNS TXT record instead of them trying to access a server at the address for verification.
A public CA won’t give you a cert for 10.0.0.1
Exactly - no one can prove they own it (on purpose because it's reserved for private network use, so no one can own it)
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.
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.
Well they offer a money-back guarantee. And other providers of SSL certificates exist.
For better or worse the push down to 47-day certificates is an industry-wide thing, in a few years no provider will issue certificates for longer than that.
Nobody is being forced to use 6-day certs for domains though, when the time comes Let's Encrypt will default to 47 days just like everyone else.
> Nobody is being forced to use 6-day certs for domains though
Yet
At some point it makes sense to just let us use self signed certs. Nobody believes SSL is providing attestation anyways.
What does attestation mean in this context? The point of the Web PKI is to provide consistent cryptographic identity for online resources, not necessarily trustworthy ones.
(The classic problem with self-signed certs being that TOFU doesn’t scale to millions of users, particularly ones who don’t know what a certificate fingerprint is or what it means when it changes.)
A lot corporate environments load their root cert and MITM you anyway
It's really security theater, too.
Though if I may put on my tinfoil hat for a moment, I wonder if current algorithms for certificate signing have been broken by some government agency or hacker group and now they're able to generate valid certificates.
But I guess if that were true, then shorter cert lives wouldn't save you.
One of the ideas behind short-lived certificates is to put certificate lifetimes within the envelope of CRL efficacy, since CRLs themselves don’t scale well and are a significant source of operational challenges for CAs.
This makes sense from a security perspective, insofar as you agree with the baseline position that revocations should always be honored in a timely manner.
I'm not sure it is about security. For security, CRLs and OCSP were a thing from the beginning. Short-lived certificates allow to cancel CRLs or at least reduce their size, so CA can save some expenses (I guess it's quite a bit of traffic for every client to download CRLs for entire letsencrypt).
> broken by some government agency or hacker group
Probably not. For browsers to accept this certificate it has to be logged in a certificate transparency log for anyone to see, and no such certificates have been seen to be logged.
My browser on my work laptop has 219 root certificates trusted. Some of those may be installed from my employer, but I suspect most of them come from MS as it's Edge on Windows 11. I see in that list things like "Swedish Government Root Authority" "Thailand National Root Certification Authority" "Staat der Nederlanden Root CA" and things like "MULTICERT Root Certification Authority" "ACCVRAUZ1". I don't think there is any reason to believe any certificate. If a government wants a cert for a given DNS they will get it, either because they directly control a trusted root CA, or because they will present a warrant to a company that wants to do business in their jurisdiction and said company will issue the cert.
TLS certs should be treated much more akin to SSH host keys in the known hosts file. Browsers should record the cert the first time they see it and then warn me if it changes before it's expiration date, or some time near the expiration date.
Certificate transparency effectively means that any government actually uses a false certificate on the wider web and their root cert will get revoked.
Obviously you might still be victim #1 of such a scheme... But in general the CA's now aren't really trusted anymore - the real root of trust is the CT logs.
>> TLS certs should be treated much more akin to SSH host keys in the known hosts file. Browsers should record the cert the first time they see it and then warn me if it changes before it's expiration date, or some time near the expiration date.
This is great, and actually constructive!
I use, a hack i put together http://www.jofla.net/php__/CertChecker/ to keep a list (in json) of a bunch of machines (both https and SSH) and the last fingerprints/date it sees. Every time it runs i can see if any server has changed, just is a heads-up for any funny business. Sure its got shortcommings, it doesnt mimmic headers and such but its a start.
It would be great if browsers could all, you know, have some type of distributed protocol, ie DHT where by at least some concensus about whether this cert has been seen by me or enough peers lately.
Having a ton of CAs and the ability to have any link in that chain sing for ANY site is crazy, and until you've seen examples of abuse you assume the foundations are sound.
Rule by the few, us little people don't matter.
Thing is, NOTHING, is stopping anyone from already getting short lived certs and being 'proactive' and rotating through. What it is saying is, well, we own the process so we'll make Chrome not play ball with your site anymore unless you do as we say...
The CA system has cracks, that short lived certs don't fix, so meanwhile we'll make everyone as uncomfortable as possible while we rearrange deck chairs.
awaiting downvotes in earnest.
> 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.
Ok, though if you're in that situation, is an IP cert the correct solution?
It's probably not a good solution if you're dealing with clients you control.
Otoh, if you're dealing with browsers, they really like WebPKI certs, and if you're directing load to specific servers in real time, why add DNS and/or a load balancer thing in the middle?
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.
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...
There will be no certificates longer than 45 days by any CA in browsers in a few years.
>I won't have time to fix this
Which should push you to automate the process.
He's expressly talking about broken automation.
You can have automation to fix the broken automation.
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.
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...
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.
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?
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.
You can also become a registrar yourself - at least, RIPE allows it. However, fees are significantly higher and it's not clear why you'd want to, unless you were actually providing ISP services to customers (in which case it's mandatory - you're not allowed to use a PI allocation for that)
> and it's not clear why you'd want to
The biggest modern-era reason is direct access to update your RPKI entries.
But this only matters if you are doing stuff that makes direct access worthwhile.
If your setup is mostly "set and forget" then you should just accept the lag associated with needing to open a ticket with your sponsor to update the RPKI.
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 ? ;)
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.
Has anyone actually given a good explanation as to why TLS Client Auth is being removed?
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...
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.
Because Google doesn't want anyone using PKI for anything but simple websites
How are IP address certificates useful?
* 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
IP addresses arent valid for the SNI used with ECH, even with TLS. On paper I do agree though it would be a decent option should things one day change there.
Oh nice! I hadn't considered DoT/DoH. The ECH angle is interesting. Thanks.
If I can use my DHCP assigned IP, will this allow me to drop having to use self-signed certificates for localhost development?
No, they will only give out certificates if you can prove ownership of the IP, which means it being publicly routable.
It's just control isn't it, not ownership? I can't prove ownership of the IPs assigned to me, but I can prove control.
Finally a reason to adopt IPv6 for your local development
A lot of publicly routable IP addresses are assigned by DHCP...
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.
it's nice to be able to use https locally if you're doing things with HTTP/2 specifically.
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.
One can also use the DNS-01 challenge in that scenario.
I guess IP certs won't really be used for anything important, but isn't there a bigger risk due to BGP hijacking?
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)
Does anyone know when Caddy plans on supporting this?
We've supported it for about a year!
Very nice, thank you guys!
https://caddy.community/t/doubt-about-the-new-lets-encrypt-c...
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.
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.
Thank you, I missed the part with several "top of the chain" providers. So all of them would need to go down at the same time for things to really stop working.
How many "top of chain" providers is letsencrypt using? Are they a single point of failure in that regard?
I'd imagine that other "top of chain" providers want money for their certificates and that they might have a manual process which is slower than letsencrypt?
LE has 2 primary production data centers: https://letsencrypt.status.io/
But in general, one of the points of ACME is to eliminate dependence on a single provider, and prevent vendor lock-in. ACME clients should ideally support multiple ACME CAs.
For example, Caddy defaults to both LE and ZeroSSL. Users can additionally configure other CAs like Google Trust Services.
This document discusses several failure modes to consider: https://github.com/https-dev/docs/blob/master/acme-ops.md#if...
“Are they a single point of failure in that regard?”
It depends. If the ACME client is configured to only use Let’s Encrypt, then the answer is yes. But the client could fall-back to Google’s CA, ZeroSSL, etc. And then there is no single point of failure.
Makes sense. I assume each of them is in control and at the whims of US president?
It seems that currently most free CAs have a big presence in the US, and employ quite a few US employees.
ZeroSSL/HID Global seems to be quite multi-national though, and it’s owned by a Swedish company (Assa Abloy).
I don’t know what what kind of mitigations these orgs have in place if the shit really hits the fan in the US. It’s an interesting question for sure.
They are not in control of the US president.
I'm pretty sure that the .org TLD can be shut off by the US at any point in time.
That’s not relevant though. These CAs will gladly give you a .se/.dk/.in/whatever cert as long as validation passes.
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.
Domains map one-to-one with registrars, but multiple AS can be using the same IP address.
Then it would be a grave error to issue an IP cert without active insight into BGP. (Or it doesn't matter which chain you have.. But calling a website from a sampling of locations can't be a more correct answer.)
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.
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.