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
https://github.com/certbot/certbot/pull/10370 showed that a proof of concept is viable with relatively few changes, though it was vibe coded and abandoned (but at least the submitter did so in good faith and collaboratively) :/ Change management and backwards compatibility seem to be the main considerations at the moment.
It allowed me to quickly obtain a couple of IP certificates to test with. I updated my simple TLS certificate checker (https://certcheck.sh) to support checking IP certificates (IPv4 only for now).
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.
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.
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.
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.
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).
Maybe but probably not. Various always-on , SDN, or wide scale site-to-site VPN schemes are deployed widely enough for long enough now that it's expected infrastructure at this point.
Even getting people to use certificates on IPSEC tunnels is a pain. Which reminds me, I think the smallest models of either Palo Alto or Checkpoint still have bizarre authentication failures if the certificate chain is too long, which was always weird to me because the control planes had way more memory than necessary for well over a decade.
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!
> 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.
They can be as transient as you want. For example, on AWS, you can release an elastic IP any time you want.
So imagine I reserve an elastic IP, then get a 45 day cert for it, then release it immediately. I could repeat this a bunch of times, only renting the IP for a few minutes before releasing it.
I would then have a bunch of 45 day certificates for IP addresses I don't own anymore. Those IP addresses will be assigned to other users, and you could have a cert for someone else's IP.
Of course, there isn't a trivial way to exploit this, but it could still be an issue and defeats the purpose of an IP cert.
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.
> 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 think a pattern like that is reasonable for a 6-day cert:
- renew every 2 days, and have a "4 day debugging window"
- renew every 1 day, and have a "5 day debugging window"
You should probably be running your renewal pipeline more frequently than that: if you had let your ACME client set itself up on a single server, it would probably run every 12h for a 90-day certificate. The ACME client won't actually give you a new certificate until the old one is old enough to be worth renewing, and you have many more opportunities to notice that the pipeline isn't doing what you expect than if you only run when you expect to receive a new certificate.
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...
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
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.
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/ )
IPv6? You wouldn’t even need to expose the actual endpoints out on the open internet. DNAT on the edge and point inbound traffic on a VM responsible for cert renewals, then distribute to the LAN devices actually using those addresses.
>so still no way to support TLS for LAN devices without manual setup or angering security researchers.
Arguably setting up letsencrypt is "manual setup". What you can do is run a split-horizon DNS setup inside your LAN on an internet-routable tld, and then run a CA for internal devices. That gives all your internal hosts their own hostname.sub.domain.tld name with HTTPS.
Frankly: it's not that much more work, and it's easier than remembering IP addresses anyway.
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.
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].
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.
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?
I'm confused what you'd want an IP certificate for when DNS A records update so easily and cheap? Is this a case of you'd want both not either, like setting up spf/dkms/dmarc?
Now you will have an American entity be controlling all your assets that you want online on a very regular basis. No way than calling home regularly.
Impossible to manage your own local certificate authority as sub CA without a nightmarish constant process of renewal and distribution.
For security this means that everything will be expected to have almost constant external traffic, RW servers to overwrite the certificates, keys spreaded for that...
And maybe I miss something but would IP address certificate be a nightmare in term of security?
Like when using mobile network or common networks like university networks, it might be very easy to snap certificates for ip shared by multiple unrelated entities. No?
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>/ ?
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)
>Successful specifications will provide some benefit to all the relevant parties because standards do not represent a zero-sum game. However, there are sometimes situations where there is a conflict between the needs of two (or more) parties.
>In these situations, when one of those parties is an "end user" of the Internet -- for example, a person using a web browser, mail client, or another agent that connects to the Internet -- the Internet Architecture Board argues that the IETF should favor their interests over those of other parties.
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.
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.
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.
I see how this would be useful once we take binary signing for granted. It would probably even be quite unobjectionable if it were simply a domain binding.
However, the very act of trying to make this system less impractical is a concession in the war on general purpose computing. To subsidize its cost would be to voluntarily loose that non-moral line of argument.
ivanr|1 month ago
Svoka|1 month ago
(seems to be WIP https://github.com/caddyserver/caddy/issues/7399)
btown|1 month ago
https://github.com/certbot/certbot/pull/10370 showed that a proof of concept is viable with relatively few changes, though it was vibe coded and abandoned (but at least the submitter did so in good faith and collaboratively) :/ Change management and backwards compatibility seem to be the main considerations at the moment.
certchecksh|1 month ago
It allowed me to quickly obtain a couple of IP certificates to test with. I updated my simple TLS certificate checker (https://certcheck.sh) to support checking IP certificates (IPv4 only for now).
unknown|1 month ago
[deleted]
AI-love|1 month ago
[deleted]
rsync|1 month ago
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.
hypeatei|1 month ago
fuomag9|1 month ago
midtake|1 month ago
- 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!
halifaxbeard|1 month ago
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.
6thbit|1 month ago
And 160 is the sum of the first 11 primes, as well as the sum of the cubes of the first three primes!
bayindirh|1 month ago
hamdingers|1 month ago
200 would be a nice round number that gets you to 8 1/3 days, so it comes with the benefits of weekly rotation.
raegis|1 month ago
rswail|1 month ago
zja|1 month ago
charcircuit|1 month ago
throw0101d|1 month ago
* https://datatracker.ietf.org/doc/html/rfc9799
* https://acmeforonions.org
* https://onionservices.torproject.org/research/appendixes/acm...
londons_explore|1 month ago
gruez|1 month ago
I think acme.sh supports it though.
mcpherrinm|1 month ago
cryptonector|1 month ago
reincarnate0x14|1 month ago
Even getting people to use certificates on IPSEC tunnels is a pain. Which reminds me, I think the smallest models of either Palo Alto or Checkpoint still have bizarre authentication failures if the certificate chain is too long, which was always weird to me because the control planes had way more memory than necessary for well over a decade.
JackSlateur|1 month ago
PunchyHamster|1 month ago
qwertox|1 month ago
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.
kevincox|1 month ago
6 days actually seems like a long time for this situation!
cortesoft|1 month ago
They can be as transient as you want. For example, on AWS, you can release an elastic IP any time you want.
So imagine I reserve an elastic IP, then get a 45 day cert for it, then release it immediately. I could repeat this a bunch of times, only renting the IP for a few minutes before releasing it.
I would then have a bunch of 45 day certificates for IP addresses I don't own anymore. Those IP addresses will be assigned to other users, and you could have a cert for someone else's IP.
Of course, there isn't a trivial way to exploit this, but it could still be an issue and defeats the purpose of an IP cert.
bigstrat2003|1 month ago
mholt|1 month ago
Sohcahtoa82|1 month ago
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.
compumike|1 month ago
I think a pattern like that is reasonable for a 6-day cert:
- renew every 2 days, and have a "4 day debugging window" - renew every 1 day, and have a "5 day debugging window"
Monitoring options: https://letsencrypt.org/docs/monitoring-options/
This makes me wonder if the scripts I published at https://heyoncall.com/blog/barebone-scripts-to-check-ssl-cer... should have the expiry thresholds defined in units of hours, instead of integer days?
andrewaylett|1 month ago
alibarber|1 month ago
PunchyHamster|1 month ago
charcircuit|1 month ago
Which should push you to automate the process.
xg15|1 month ago
johannes1234321|1 month ago
oddly|1 month ago
patmorgan23|1 month ago
cpach|1 month ago
sgjohnson|1 month ago
unknown|1 month ago
[deleted]
stackghost|1 month ago
Arguably setting up letsencrypt is "manual setup". What you can do is run a split-horizon DNS setup inside your LAN on an internet-routable tld, and then run a CA for internal devices. That gives all your internal hosts their own hostname.sub.domain.tld name with HTTPS.
Frankly: it's not that much more work, and it's easier than remembering IP addresses anyway.
progbits|1 month ago
arisudesu|1 month ago
iamrobertismo|1 month ago
jeroenhd|1 month ago
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.
medmunds|1 month ago
axus|1 month ago
iamrobertismo|1 month ago
traceroute66|1 month ago
There's also this little thing called DNS over TLS and DNS over HTTPS that you might have heard of ? ;)
pdntspa|1 month ago
apitman|1 month ago
As a concrete example, I'll probably be able to turn off bootstrap domains for TakingNames[0].
[0]: https://takingnames.io/blog/instant-subdomains
razakel|1 month ago
dextercd|1 month ago
cryptonector|1 month ago
singpolyma3|1 month ago
JackSlateur|1 month ago
mTLS is probably the only sane situation where private key infrastructure shall be used
greyface-|1 month ago
cryptonector|1 month ago
SahAssar|1 month ago
* An outer SNI name when doing ECH perhaps
* Being able to host secure http/mail/etc without being beholden to a domain registrar
meling|1 month ago
michaelt|1 month ago
wolttam|1 month ago
For local /network/ development, maybe, but you’d probably be doing awkward hairpin natting at your router.
Sohcahtoa82|1 month ago
Other than basically being a pain in the ass.
Already__Taken|1 month ago
greatgib|1 month ago
Now you will have an American entity be controlling all your assets that you want online on a very regular basis. No way than calling home regularly. Impossible to manage your own local certificate authority as sub CA without a nightmarish constant process of renewal and distribution.
For security this means that everything will be expected to have almost constant external traffic, RW servers to overwrite the certificates, keys spreaded for that...
And maybe I miss something but would IP address certificate be a nightmare in term of security?
Like when using mobile network or common networks like university networks, it might be very easy to snap certificates for ip shared by multiple unrelated entities. No?
josephernest|1 month ago
elpasi|1 month ago
cedws|1 month ago
toast0|1 month ago
6thbit|1 month ago
iancarroll|1 month ago
nkmnz|1 month ago
superkuh|1 month ago
>Successful specifications will provide some benefit to all the relevant parties because standards do not represent a zero-sum game. However, there are sometimes situations where there is a conflict between the needs of two (or more) parties.
>In these situations, when one of those parties is an "end user" of the Internet -- for example, a person using a web browser, mail client, or another agent that connects to the Internet -- the Internet Architecture Board argues that the IETF should favor their interests over those of other parties.
Incorporated entities are just secondary users.
bflesch|1 month ago
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.
iso1631|1 month ago
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.
zamadatix|1 month ago
mholt|1 month ago
1a527dd5|1 month ago
unknown|1 month ago
[deleted]
rubatuga|1 month ago
Khalequzzaman|1 month ago
hojofpodge|1 month ago
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.
ycombinatrix|1 month ago
MORPHOICES|1 month ago
[deleted]
AI-love|1 month ago
[deleted]
notepad0x90|1 month ago
duskwuff|1 month ago
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.
pona-a|1 month ago
However, the very act of trying to make this system less impractical is a concession in the war on general purpose computing. To subsidize its cost would be to voluntarily loose that non-moral line of argument.
cpach|1 month ago