8 ms·

Getting ready to issue IP address certificates

335 points by Bogdanp 1y ago

zaik 1y ago
Interesting. I wonder if XMPP federation would work with such a certificate.
- giancarlostoro 1y ago
  Are there public XMPP servers using just the IP for the host? Never heard of this, I could see this being the case internally.
mocko 1y ago
I can see how this would work on a technical level but what's the intended use case?
- throitallaway 1y ago
  I'm guessing mostly hobbyists and one-off use cases where people don't care to associate a hostname to a project.
- BiteCode_dev 1y ago
  Static ip for self hosting at home
  - politelemon 1y ago
    The validity is just 6 days, so I'd assume it's not for long lived use cases? Or am I misunderstanding something
    - meepmorp 1y ago
      they're only for publicly accessible IP addresses, so they'd work the same as regular letsencrypt certs - get a new one when the old one expires.
    - deleted 1y ago
      [deleted]
    - XorNot 1y ago
      Certificate validity has no bearing on availability. It just keeps revocation lists short.
  - remram 1y ago
    You can point a name at your home IP just as easily as any other IP.
    - bravesoul2 1y ago
      But you have to pay and involve a 3rd party.
      - kingstnap 1y ago
        Are there ISPs that give you free static ips? Maybe for ipv6?
        bravesoul2 1y ago
        Probably not these days for v4
- ff317 1y ago
  It might be interesting for "opportunistic" DoTLS towards authdns servers, which might listen on the DoTLS port with a cert containing a SAN that matches the public IP of the authdns server. (You can do this now with authdns server hostnames, but there could be many varied names for one public authdns IP, and this kinda ties things together more-clearly and directly).
  - jeroenhd 1y ago
    It might also he useful to hide the SNI in HTTPS requests. With the current status of ESNI/ECH you need some kind of proxy domain, but for small servers that only host a few sites, every domain may be identifiable (as opposed to, say, a generic Cloudflare certificate or a generic Azure certificate).
- bongodongobob 1y ago
  Pretty common to have appliances without DNS entries in infra is my guess, I could def make use of this at work.
  - Hizonner 1y ago
    You're not going to be able to get a cert for any address that's not both (a) global, and (b) actually reachable from the Internet.
- teaearlgraycold 1y ago
  Not common, but there is the use case of vanity IPs. The cert for https://1.1.1.1 https://1.1.1.1 is signed for the IP as well as the domain name one.one.one.one
- szszrk 1y ago
  Sometimes you want to have valid certs while your dns is undergoing major redesign. For instance to keep your dashboards available, or to be triple sure no old automation will fail due to dns issues. In other cases dns is just not needed at all. You might prefer simplicity, independence from dns propagation, so you will have your, say, Cockpit exposed instantly on a test env. Only our imagination limits us here.
  - Hizonner 1y ago
    So go to keys-are-names. There's no reason AT ALL to bring IP addresses into the mix.
    - szszrk 1y ago
      > So go to keys-are-names. Elaborate, please. > There's no reason AT ALL to bring IP addresses into the mix. Not sure what scenario you are talking about, but IPs are kind of hard to avoid. DNS is trivial to avoid - you can simply not set it up. "bringing IPs into the mix" is literally the only possible option.
      - Hizonner 1y ago
        >> So go to keys-are-names. > Elaborate, please. Identify a service directly by its crypto key. When you configure something else to connect to it, treat the IP address as a hint, not the primary identifier for what it's talking to. Standard idiom. ... and before you tell me that that's infeasible because you'd have to modify software, go do a survey of all the code out there, and see how much of it supports IP address certificates. If you're moving around the parts of some big complex system, it's pretty much guaranteed that many of those parts are going to choke if you just blindly go and stick IP addresses in https:// https:// URLs. And if you're fixing the software anyway, then it's not sane to "fix" it to attach identity to something you're going to want to change all the time, like an IP address. Especially if they're global addresses (which are the only ones any Let's Encrypt or any other public CA is ever going to certify) in the IPv4 space (which is the only one any "enterprise" ever seems willing to use).
- move-on-by 1y ago
  Plenty of other responses with good use cases, but I didn’t see NTS mentioned. If you want to use NTS, but can’t get an IP cert, then you are left requiring DNS before you can get a trusted time. If DNS is down- then you can’t get the time. A common issue with DNSSEC is having the wrong time- causing validation failures. If you have DNSSEC enforced and have the wrong time- but NTS depends on DNS, then you are out of luck with no way to recover. Having IP as part of your cert allows trusted time without the DNS requirement, which can then fix your broken DNSSEC enforcement.
  - Hizonner 1y ago
    How are you going to validate an X.509 certificate if you don't know the time?
    - move-on-by 1y ago
      Oh this is a good point! Looking at my DNSSEC domain (hosted by CloudFlare) on https://dnssec-debugger.verisignlabs.com https://dnssec-debugger.verisignlabs.com - the Inception Time and Expiration Time seems to be valid for... 3.5 days? This isn't something I look at much, but I assume that is up to the implementation. The new shortlived cert is valid for 6 days. So, from a very rough look, I expect X.509 certificate is going to be less time sensitive then DNSSEC - but only by a few days. Also, very likely to depend on implementation details. This is a great point.
      - dcow 1y ago
        Practically, though, you rely on hardware time until you get network time.
    - dgl 1y ago
      ChromeOS has a quite interesting design to do this: https://www.chromium.org/chromium-os/chromiumos-design-docs/timekeeping/#tlsdate https://www.chromium.org/chromium-os/chromiumos-design-docs/... Essentially: keep some minimum values for time. Then do a single HTTPS request, ignore the validation of the certificate's date to start with, but use the Date header to later validate it against minimum / maximum. This has the advantage it's still a HTTPS request, so can't be MiTM'd and depending on implementation it can validate the time quite well (even if the device has run out of power it can have saved a recent timestamp on disk, so with regular use of the device an old certificate won't be valid, keeping the main useful property of certificates having validity periods). I don't believe it does this, but you could do this without DNS as 8.8.8.8, etc already have IP address certificates: curl -sI https://1.1.1.1 | grep -i '^date:' curl -sI https://8.8.8.8 | grep -i '^date:' curl -sI https://9.9.9.9 | grep -i '^date:' It would need a custom tool though, as curl only has --insecure, not a way to avoid just the notBefore / notAfter validation of the cert. (This is not the only thing to use this technique, OpenBSD's ntpd has a way to contrain time based on HTTP headers: https://man.openbsd.org/ntpd.conf#CONSTRAINTS https://man.openbsd.org/ntpd.conf#CONSTRAINTS -- the default ntpd.conf ships with Quad9 configured via IP address.)
- infogulch 1y ago
  Just ESNI/ECH is a big deal. I recall one of the main arguments against Encrypted server name indication (ESNI) is that it would only be effective for the giant https proxy services like Cloudflare, that the idea of IP certs was floated as a solution but dismissed as a pipe dream. With IP address certificates, now every server can participate in ESNI, not just the giants. If it becomes common enough for clients to assume that all web servers have an IP cert and attempt to use ESNI on every connection, it could be a boon for privacy across the internet.
  - duskwuff 1y ago
    > If it becomes common enough for clients to assume that all web servers have an IP cert That's never going to be a safe assumption; private and/or dynamically assigned IP addresses are always going to be a thing.
  - Hizonner 1y ago
    So is this the flow? 1. Want to connect to https://www.secret.com https://www.secret.com. 2. Resolve using DNS, get 1.2.3.4 3. Connect to 1.2.3.4, validate cert 4. Send ESNI, get separate cert for www.secret.com, validate that ... and the threat you're mitigating is presumably that you don't want to disclose the name "www.secret.com" unless you're convinced you're talking to the legitimate 1.2.3.4, so that some adversary can't spoof the IP traffic to and from 1.2.3.4, and thereby learn who's making connections to www.secret.com. Is that correct? But the DNS resolution step is still unprotected. So, two broad cases: 1. Your adversary can subvert DNS. In this case IP certificates add no value, because they can just point you to 5.6.7.8, and you'll happily disclose "www.secret.com" to them. And you have no other path to communicate any information about what keys to trust. 2. Your adversary cannot subvert DNS. But if you can rely on DNS, then you can use it as a channel for key information; you include a key to encrypt the ESNI for "www.secret.com" in a DNS record. Even if the adversary can spoof the actual IP traffic to and from 1.2.3.4, it won't do any good because it won't have the private key corresponding to that ESNI key in the DNS. And those keys are already standardized. So what adversary is stopped by IP certificates who isn't already stopped by the ESNI key records in the DNS?
    - 1y ago
- spelunker 1y ago
  Might be nice for local/development environment work. Test HTTPS without needing to set up `my-dev-env.staging.service.com` or whatever.
  - martinald 1y ago
    Yes definitely.
  - cpach 1y ago
    But these are public certificates. Most personal computers are behind NAT, i.e. they lack a public IP address.
    - spelunker 1y ago
      But my EC2 instance is public! Ok not "local" per se, but definitely could be part of development work.
- hypeatei 1y ago
  One use-case is connecting to a DoT (DNS-over-TLS) server directly rather than using a hostname. If you make a TLS connection to an IP address via OpenSSL, it will verify the IP SAN and fail if it's not there.
- charcircuit 1y ago
  It helps break free of ICANN's domain name system. This enables for competitors to support https without needing self signed certs.
- Am4TIfIsER0ppos 1y ago
  The intended use case is to forbid plain http so that you can't communicate with the computer in the next room without 3rd party permission.
- deleted 1y ago
  [deleted]
smallnix 1y ago
Is this for ipv4 and ipv6?
- jaas 1y ago
  It will work for both.
richm44 1y ago
Time for me to dust off CVE-2010-3170 again? :-)
- NicolaiS 1y ago
  I guess a bunch of "roll your own X.509 validation"-logic will have that bug, but to exploit it you need a misbehaving CA to issue you such a cert (i.e. low likelihood)
OptionOfT 1y ago
Interesting, there is no subject in the example cert shown. Is this because the certificate was requested for the IP, and other DNS entries were part of the SAN?
- jaas 1y ago
  We (Let's Encrypt) are getting rid of subject common names and moving to just using subject alternative names. This change has been made in short-lived (6 day) certificate profiles. It has not been made for the "classic" profile (90 day).
  - tialaramex 1y ago
    Have you found much trouble with clients that can't cope without CN? Is this one of those situations where anything that can't cope is also hopeless for other reasons (e.g. can't speak TLS 1.2, doesn't understand IPv6, that sort of thing) and so you can tell people you're not their biggest problem ?
    - jcgl 1y ago
      It’d surely be something like that. CN has been deprecated and SAN support has been required for 25 years at this point[0]. [0] https://datatracker.ietf.org/doc/html/rfc2818#section-3.1 https://datatracker.ietf.org/doc/html/rfc2818#section-3.1
      - tialaramex 1y ago
        I'm aware that PKIX deprecated use of CN for this purpose at the turn of the century, but when browsers began ignoring CN about a decade ago (which is the first half of the adoption curve) I know Google had to ship an enterprise override for people whose corporate systems could not cope. If it's true that all or almost all systems now work properly that's great news.
zdw 1y ago
This seems to be for public IP addresses, not private RFC1918 ipv4 range addresses. The only challenges possible are HTTP and TLS-ALPN, not DNS, so the "proof" that you own the IP is that LetsEncrypt can contact it?
- ameliaquining 1y ago
  Yes, which is the same way control of a domain name is typically checked; DNS is only used in a minority of cases as it can't be as turnkey.
- Hizonner 1y ago
  Having DNS available wouldn't be any more "proof". The person applying gets to choose which form of proof will be provided, so adding more options can only ever make it easier to "prove" things.
  - tialaramex 1y ago
    I don't happen to know if it's actively in use, or whether any of the technical implementation details were formally standardized, but one obvious thing goes like this: 1. Write a DNS record for CAA the Certificate Authority Authorization for your names 2. In the CAA record, say that you forbid anybody except your chosen CA to issue. Competent CAs will obey this instruction (obeying it is mandated by the root trust stores, there are bugs of course but on the whole compliance is very good and is separate from their implementation of specific validation methods) 3. Further, indicate, either in this record or by agreement with your chosen CA, that they must use DNS proof of control. This might be something very nerdy like indicating a specific OID for the method in the CAA record or it might be a Memorandum of Understanding somebody signed and then they went out for a nice lunch.
    - ameliaquining 1y ago
      Yes, this is a thing: https://www.rfc-editor.org/rfc/rfc8657.html#name-extensions-to-the-caa-record https://www.rfc-editor.org/rfc/rfc8657.html#name-extensions-...
lq9AJ8yrfs 1y ago
So all the addressing bodies (e.g., ISPs and cloud providers) are on board then right? They sometimes cycle through IP's with great velocity. Faster than 6 days at least. Lots of sport here, unless perhaps they cool off IPs before reallocating, or perhaps query and revoke any certs before reusing the IP? If the addressing bodies are not on board then it's a user responsibility to validate the host header and reject unwanted IP address based connections until any legacy certs are gone / or revoke any legacy certs. Or just wait to use your shiny new IP? I wonder how many IP certs you could get for how much money with the different cloud providers.
- hk1337 1y ago
  > I wonder how many IP certs you could get for how much money with the different cloud providers. I wonder if they'll offer wildcard certs at some point.
  - qyrreqjh 1y ago
    if you're talking about lets encrypt, they started offering wildcards in 2018
    - DaSHacka 1y ago
      GP may have been talking about "wildcard IP certificates" Or, even if they weren't, now I'm curious about that possibility too.
      - bc569a80a344f9c 1y ago
        Doesn't seem like that's possible. RFC5280 (https://datatracker.ietf.org/doc/html/rfc5280 https://datatracker.ietf.org/doc/html/rfc5280) defines these fields. Section 4.2.1.6 defines SANs, and specifies: > When the subjectAltName extension contains an iPAddress, the address MUST be stored in the octet string in "network byte order", as specified in [RFC791]. The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For IP version 4, as specified in [RFC791], the octet string MUST contain exactly four octets. For IP version 6, as specified in [RFC2460], the octet string MUST contain exactly sixteen octets. That's 32 bits for IPv4 and 128 bits for IPv6. You can't store anything other than a single unicast IP address of either format with that much space.
timewizard 1y ago
I've personally never felt comfortable using regexes to solve production problems. The certificate code referenced here shows why: https://github.com/mozilla-firefox/firefox/blob/d5979c2a5c2e48c0c9ecb22ebad79fa135438454/toolkit/components/certviewer/content/certDecoder.mjs#L161 https://github.com/mozilla-firefox/firefox/blob/d5979c2a5c2e... Yikes.
- ameliaquining 1y ago
  I think that's not doing anything security-critical, it's just formatting an IPv6 address for display in the certificate-viewer UI.
- cpburns2009 1y ago
  All that regex does is split an IPv6 address into groups of 4 digits, joins them with ":", and collapses any sequence of ":0000:" to "::". I don't see anything problematic with it.
  - timewizard 1y ago
    > and collapses any sequence of ":0000:" to "::" Which is an error. Any ip like 2001:0000:0000::1 is going to be incorrect. It willingly produces errors. Whoever wrote this didn't even spend a few seconds thinking about the structure of IPv6 addresses. > I don't see anything problematic with it. Other than it being completely wrong and requiring a regex to be compiled for an amount of work that's certainly less than the compilation itself.
    - cpburns2009 1y ago
      It only operates on a 32 digit IPv6 address so it won't already be abbreviated. My phrasing was inexact. It replaces only the first sequence of any number of ":0000:" to "::".
    - remram 1y ago
      > Any ip like 2001:0000:0000::1 is going to be incorrect. This is neither a possible input nor a possible output of that code.
0xbadcafebee 1y ago
Nice, another exploit for TLS. The previous ones were all about generating valid certs for a domain you don't own. This one will be for generating a cert for an IP you don't own. The blackhats will be hooting and hollering on telegram :)
- jeroenhd 1y ago
  IP certificates have been a thing for many years now. The only change is that Let's Encrypt now also provides them.
Hizonner 1y ago
So does anybody have a pointer to the official justification for this insanity?
- fredfish 1y ago
  https://github.com/cabforum/servercert/pull/579/commits https://github.com/cabforum/servercert/pull/579/commits </s?
  - Hizonner 1y ago
    I'm sorry, but how is "Require validation of DNSSEC (when present) for CAA and DCV Lookups" related to issuing X.509 certs that include IP address SANs? I don't see any connection, and I didn't spot anything about it on a quick skim of the comments.
    - fredfish 1y ago
      Anything from people who are afraid of increasingly onerous DNS requirements to breakage because they can't fix their parent domains DNSSEC misconfiguration. It seems like an interesting timing coincide to me so I wonder if there's some (ir)rational explanation. (Implementing a new SAN that must inherently have the gap you are finally addressing is not a bit funny to you?)
- ameliaquining 1y ago
  The announcement is https://letsencrypt.org/2025/01/16/6-day-and-ip-certs/ https://letsencrypt.org/2025/01/16/6-day-and-ip-certs/. I don't think it's more complicated than: there exist services that for one reason or another don't have a domain name and are instead accessible by a public static IP address, and they need TLS certificates for security, and other CAs offer this, so Let's Encrypt should too. Is there any specific reason why they shouldn't?
  - Hizonner 1y ago
    Hmm. Absolutely no explanation of why there's a need. Given only that announcement, I'd have to assume that the reason is "because we can". So the first reason not to do it is that you never want to change software without a good reason. And none of the use cases anybody's named here so far hold water. They're all either skill issues already well addressed by existing systems, or fundamental misunderstandings that don't actually work. Changing basic assumptions about naming is an extra bad idea with oak leaf clusters, because it pretty much always opens up security holes. I can't point to the specific software where somebody's made a load-bearing security assumption about IP address certificates not being available (more likely a pair of assumptions "Users will know about this" and "This can't happen/I forgot about this")... but I'll find out about it when it breaks. Furthermore, if IP certificates get into wide use (and Let's Encrypt is definitely big enough to drive that), then basically every single validator has to have a code path for IP SANs. Saying "you don't have to use it" is just as much nonsense as saying "you don't have to use IP". Every X.509 library ends up with a code path for IP SANs, and it effectively can't even be profiled out. Every library is that much bigger and that much more complicated and needs that much more maintenance and testing. It's a big externalized cost. It would better to change the RFCs to deprecate IP SANs; they never should have been standardized to begin with. It also encourages a whole bunch of bad practices that make networks brittle and unmaintainable. You should almost never see an IP address outside of a DNS zone file (or some other name resolution protocol). You can argue that people shouldn't do stupid things like hardwiring IP addresses even if they're given the tools... but that's no consolation to the third parties downstream of those stupid decisions. ... and it doesn't even work for all IP addresses, because IP addresses aren't global names. So don't forget to special-case the locally administered space in every single piece of code that touches an X.509 certificate.
zipping1549 1y ago
Boy that doesn't sound good.
vkdelta 1y ago
Does it help getting encrypted https (without self signed cert error) on my local router ? 192.168.0.1 being an example login page.
- ameliaquining 1y ago
  No, they won't issue a certificate for a private IP address because you don't have exclusive control over it (i.e., the same IP address would point to a different machine on someone else's network).
- qmarchi 1y ago
  No but maybe yes: It would be impossible, and undesirable to issue certificates for local addresses. There's no way to verify local addresses because, inherently, they're local and not globally routable. However, if a router manufacturer was so inclined, they _could_ have the device request a certificate for their public IPv4 address, given that it's not behind CG-NAT. v6 should be relatively easy since (unless you're at a cursed ISP) all v6 is generally globally routable.
  - jeroenhd 1y ago
    Even behind CGNAT, you could probably get away with DNS here. If you provide your customers with customeraccount.manufacturerrouters.com, you can then use DNS validation to get a valid certificate for *.customeraccount.manufacturerrouters.com. Put a record in there that points to the local router IP (I.E. settings.customeraccount.manufacturerrouters.com) and you can get HTTPS logins on your local network, even with local IP addresses if the CAB still allows that. It's not exactly user friendly, but it'll work. Personally, I have a private CA that I use. My home router has a domain name pointing towards it and has been loaded up with my private certificate. I get the certificate error once a year when the thing expires but in the mean time I can access my router securely.
- johnklos 1y ago
  You have to possess the IP.
- jekwoooooe 1y ago
msgodel 1y ago
This is incredibly dumb. The three way handshake and initial key exchange is your certificate.
- cpburns2009 1y ago
  That would be fine if browsers didn't throw up giant warning signs when using self-signed certificates.
  - msgodel 1y ago
    That sounds like a defect in the browser design. Or maybe it's because you actually want an identity to verify (which an IP address is not.)
  - nijave 1y ago
    Usually you can just import the leaf self signed cert as a CA in your OS trust store and the problem goes away (assuming it has an IP SAN). Slightly tedious but you can issue the certs with long validity
    - cpburns2009 1y ago
      Chrome provides no simple way to trust a self-signed cert. When you go to certificate details, the only option under the "Details" tab is "Export...". The only work around is to click "Advanced" and "Proceed to example.com (unsafe)". Chrome will then helpfully suffer amnesia in 1-3 days and completely forget you want to allow an exception for the certificate.
      - nijave 1y ago
        iirc Chrome uses OS trust store so the trust needs to be using the operating system's facility
- Dylan16807 1y ago
  And this protects you from a hostile network how?
foresto 1y ago
I expect SAN in this case means Subject Alternative Name, not Storage Area Network. Sigh... I wish people would use their words before trotting out possibly-ambiguous (or obscure) acronyms. It would help avoid confusion among readers who don't live and breathe the topic on the writer's mind.
- parliament32 1y ago
  If you don't know how to interpret "SAN" in a blog post from a TLS certificate issuer, I don't think you're the target audience for this post.
  - NewJazz 1y ago
    OK, but how hard is a link to Wikipedia?
    - arccy 1y ago
      please expand the abbreviation "OK"
      - NewJazz 1y ago
        Okay
  - foresto 1y ago
    Lots of people on HN are not the target audience for any given post, yet are still interested. (And my point applies to all writing and speaking, not just this post.)
    - mcpherrinm 1y ago
      If it was a blog post or announcement, we’d have surely included more context, and not a forum post really intended for limited distribution. You just used HN without expanding that acronym! :)
  - 1y ago
bufferoverflow 1y ago
[dead]
Tepix 1y ago
I think certificates for IP addresses can be useful. However, if Let‘s encrypt were to support S/MIME certificates, it would have a far greater impact. Since a few years, we have an almost comical situation with email encryption: Finally, most important mail user agents (aka mail clients) support S/MIME encryption out of the box. But you need a certificate from a CA to have a smooth user experience, just like with the web. However, all CAs that offer free trustworthy¹ S/MIME certificates with a duration of a year or more² have disappeared. The result: No private entities are using email encryption. (PGP remains unused outside of geek circles because it is too awkward to use.) Let‘s encrypt our emails! ¹ A certificate isn‘t trustworthy if the CA generates the secret key for you. ² With S/MIME you need to keep your old certificates around to decrypt old mails, so having a new one frequently is not practical
- figassis 1y ago
  I know little about s/mime encryption. But why do we need to decrypt old emails with the same protocol? In my head, I imagine certs would be for transport, and your server or host should handle encryption at rest no? So short lived transport certs, and whatever storage encryption you want. What am I missing here?
  - frozenice 1y ago
    S/MIME is about the mail (content) itself, not the transport. For the transport part there are things like (START)TLS and MTA-STS. With S/MIME you include your certificate in the mail and can either sign the mail with a signature (with your private key, others can verify it using your public key from the certificate) or encrypt the mail (with the receiver's public key, so only he can decrypt it using his private key). Certificate trust is determined normally via the CA chain and trusted CAs.
- wiktor-k 1y ago
  > ² With S/MIME you need to keep your old certificates around to decrypt old mails, so having a new one frequently is not practical You don't need to change your decryption key - the new certificate can use the same decryption keys as the old one (certbot even has a flag: --reuse-key). Whether this is a good idea or not is a separate question. I think the biggest benefit would be ACME-like automatic certificate issuance. Currently getting a new certificate is just too much friction.
sschueller 1y ago
What about internal IPv4 addresses? Can we have browsers ignore 192.168.x.x, 172.16.x.x and 10.x.x.x if we can't get certs for those or can we get a public wildcard for internal networks?
- cpach 1y ago
  I don’t believe that makes sense in the context of certificates generated by a public CA. Unlike domain names, there’s not one owner of 10.10.10.10, there are millions of “owners”… But what problem is it that you want to solve? For local development, one can use a tool such as mkcert. For shared internal resources (e.g. within a company), it’s probably easier to use a TLS cert tied to a domain instead of using naked IP addresses.
  - sschueller 1y ago
    My cameras are internally accessibly via https. Every time I open a browser I need to click two buttons to get past the certificate error. Sure I could configure a real domain, do split DNS and get a certificate but these cameras require manual uploading a certificate. I would need to do this every three months for every camera and eventually even more frequently.
    - arccy 1y ago
      and IP certs would help how? you'd have to upload every 6 days. just run your own CA with ~infinite lifespan.
    - throw0101c 1y ago
      There are numerous tutorials on running your own private certificate authority (CA): * https://smallstep.com/blog/private-acme-server/ https://smallstep.com/blog/private-acme-server/ ; https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi-yubikey/ https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi... * https://openvpn.net/community-resources/setting-up-your-own-certificate-authority-ca/ https://openvpn.net/community-resources/setting-up-your-own-... * https://www.digitalocean.com/community/tutorials/how-to-set-up-and-configure-a-certificate-authority-ca-on-debian-10 https://www.digitalocean.com/community/tutorials/how-to-set-... Import the CA's root cert on your browsing devices and anything it issues will be trusted.
sgjohnson 1y ago
Shame that IP address certificates can’t be done via the DNS challenge, but I completely understand why.
1vuio0pswjnm7 1y ago
Why can't the internet regional registries issue certificates Why can't local internet registries issue certificates Why are third parties needed to verify RIR and LIR registrants Apparently the job is too much for domainname registrars Are the reasons the same

335 points by Bogdanp 1y ago

zaik 1y ago

Interesting. I wonder if XMPP federation would work with such a certificate.

giancarlostoro 1y ago
Are there public XMPP servers using just the IP for the host? Never heard of this, I could see this being the case internally.

mocko 1y ago

I can see how this would work on a technical level but what's the intended use case?

throitallaway 1y ago
I'm guessing mostly hobbyists and one-off use cases where people don't care to associate a hostname to a project.
BiteCode_dev 1y ago
Static ip for self hosting at home
- politelemon 1y ago
  The validity is just 6 days, so I'd assume it's not for long lived use cases? Or am I misunderstanding something
  - meepmorp 1y ago
    they're only for publicly accessible IP addresses, so they'd work the same as regular letsencrypt certs - get a new one when the old one expires.
  - deleted 1y ago
    [deleted]
  - XorNot 1y ago
    Certificate validity has no bearing on availability. It just keeps revocation lists short.
- remram 1y ago
  You can point a name at your home IP just as easily as any other IP.
  - bravesoul2 1y ago
    But you have to pay and involve a 3rd party.
    - kingstnap 1y ago
      Are there ISPs that give you free static ips? Maybe for ipv6?
      - bravesoul2 1y ago
        Probably not these days for v4
ff317 1y ago
It might be interesting for "opportunistic" DoTLS towards authdns servers, which might listen on the DoTLS port with a cert containing a SAN that matches the public IP of the authdns server. (You can do this now with authdns server hostnames, but there could be many varied names for one public authdns IP, and this kinda ties things together more-clearly and directly).
- jeroenhd 1y ago
  It might also he useful to hide the SNI in HTTPS requests. With the current status of ESNI/ECH you need some kind of proxy domain, but for small servers that only host a few sites, every domain may be identifiable (as opposed to, say, a generic Cloudflare certificate or a generic Azure certificate).
bongodongobob 1y ago
Pretty common to have appliances without DNS entries in infra is my guess, I could def make use of this at work.
- Hizonner 1y ago
  You're not going to be able to get a cert for any address that's not both (a) global, and (b) actually reachable from the Internet.
teaearlgraycold 1y ago
Not common, but there is the use case of vanity IPs. The cert for https://1.1.1.1 https://1.1.1.1 is signed for the IP as well as the domain name one.one.one.one
szszrk 1y ago
Sometimes you want to have valid certs while your dns is undergoing major redesign. For instance to keep your dashboards available, or to be triple sure no old automation will fail due to dns issues. In other cases dns is just not needed at all. You might prefer simplicity, independence from dns propagation, so you will have your, say, Cockpit exposed instantly on a test env. Only our imagination limits us here.
- Hizonner 1y ago
  So go to keys-are-names. There's no reason AT ALL to bring IP addresses into the mix.
  - szszrk 1y ago
    > So go to keys-are-names. Elaborate, please. > There's no reason AT ALL to bring IP addresses into the mix. Not sure what scenario you are talking about, but IPs are kind of hard to avoid. DNS is trivial to avoid - you can simply not set it up. "bringing IPs into the mix" is literally the only possible option.
    - Hizonner 1y ago
      >> So go to keys-are-names. > Elaborate, please. Identify a service directly by its crypto key. When you configure something else to connect to it, treat the IP address as a hint, not the primary identifier for what it's talking to. Standard idiom. ... and before you tell me that that's infeasible because you'd have to modify software, go do a survey of all the code out there, and see how much of it supports IP address certificates. If you're moving around the parts of some big complex system, it's pretty much guaranteed that many of those parts are going to choke if you just blindly go and stick IP addresses in https:// https:// URLs. And if you're fixing the software anyway, then it's not sane to "fix" it to attach identity to something you're going to want to change all the time, like an IP address. Especially if they're global addresses (which are the only ones any Let's Encrypt or any other public CA is ever going to certify) in the IPv4 space (which is the only one any "enterprise" ever seems willing to use).
move-on-by 1y ago
Plenty of other responses with good use cases, but I didn’t see NTS mentioned. If you want to use NTS, but can’t get an IP cert, then you are left requiring DNS before you can get a trusted time. If DNS is down- then you can’t get the time. A common issue with DNSSEC is having the wrong time- causing validation failures. If you have DNSSEC enforced and have the wrong time- but NTS depends on DNS, then you are out of luck with no way to recover. Having IP as part of your cert allows trusted time without the DNS requirement, which can then fix your broken DNSSEC enforcement.
- Hizonner 1y ago
  How are you going to validate an X.509 certificate if you don't know the time?
  - move-on-by 1y ago
    Oh this is a good point! Looking at my DNSSEC domain (hosted by CloudFlare) on https://dnssec-debugger.verisignlabs.com https://dnssec-debugger.verisignlabs.com - the Inception Time and Expiration Time seems to be valid for... 3.5 days? This isn't something I look at much, but I assume that is up to the implementation. The new shortlived cert is valid for 6 days. So, from a very rough look, I expect X.509 certificate is going to be less time sensitive then DNSSEC - but only by a few days. Also, very likely to depend on implementation details. This is a great point.
    - dcow 1y ago
      Practically, though, you rely on hardware time until you get network time.
  - dgl 1y ago
    ChromeOS has a quite interesting design to do this: https://www.chromium.org/chromium-os/chromiumos-design-docs/timekeeping/#tlsdate https://www.chromium.org/chromium-os/chromiumos-design-docs/... Essentially: keep some minimum values for time. Then do a single HTTPS request, ignore the validation of the certificate's date to start with, but use the Date header to later validate it against minimum / maximum. This has the advantage it's still a HTTPS request, so can't be MiTM'd and depending on implementation it can validate the time quite well (even if the device has run out of power it can have saved a recent timestamp on disk, so with regular use of the device an old certificate won't be valid, keeping the main useful property of certificates having validity periods). I don't believe it does this, but you could do this without DNS as 8.8.8.8, etc already have IP address certificates: curl -sI https://1.1.1.1 | grep -i '^date:' curl -sI https://8.8.8.8 | grep -i '^date:' curl -sI https://9.9.9.9 | grep -i '^date:' It would need a custom tool though, as curl only has --insecure, not a way to avoid just the notBefore / notAfter validation of the cert. (This is not the only thing to use this technique, OpenBSD's ntpd has a way to contrain time based on HTTP headers: https://man.openbsd.org/ntpd.conf#CONSTRAINTS https://man.openbsd.org/ntpd.conf#CONSTRAINTS -- the default ntpd.conf ships with Quad9 configured via IP address.)
infogulch 1y ago
Just ESNI/ECH is a big deal. I recall one of the main arguments against Encrypted server name indication (ESNI) is that it would only be effective for the giant https proxy services like Cloudflare, that the idea of IP certs was floated as a solution but dismissed as a pipe dream. With IP address certificates, now every server can participate in ESNI, not just the giants. If it becomes common enough for clients to assume that all web servers have an IP cert and attempt to use ESNI on every connection, it could be a boon for privacy across the internet.
- duskwuff 1y ago
  > If it becomes common enough for clients to assume that all web servers have an IP cert That's never going to be a safe assumption; private and/or dynamically assigned IP addresses are always going to be a thing.
- Hizonner 1y ago
  So is this the flow? 1. Want to connect to https://www.secret.com https://www.secret.com. 2. Resolve using DNS, get 1.2.3.4 3. Connect to 1.2.3.4, validate cert 4. Send ESNI, get separate cert for www.secret.com, validate that ... and the threat you're mitigating is presumably that you don't want to disclose the name "www.secret.com" unless you're convinced you're talking to the legitimate 1.2.3.4, so that some adversary can't spoof the IP traffic to and from 1.2.3.4, and thereby learn who's making connections to www.secret.com. Is that correct? But the DNS resolution step is still unprotected. So, two broad cases: 1. Your adversary can subvert DNS. In this case IP certificates add no value, because they can just point you to 5.6.7.8, and you'll happily disclose "www.secret.com" to them. And you have no other path to communicate any information about what keys to trust. 2. Your adversary cannot subvert DNS. But if you can rely on DNS, then you can use it as a channel for key information; you include a key to encrypt the ESNI for "www.secret.com" in a DNS record. Even if the adversary can spoof the actual IP traffic to and from 1.2.3.4, it won't do any good because it won't have the private key corresponding to that ESNI key in the DNS. And those keys are already standardized. So what adversary is stopped by IP certificates who isn't already stopped by the ESNI key records in the DNS?
  - 1y ago
spelunker 1y ago
Might be nice for local/development environment work. Test HTTPS without needing to set up `my-dev-env.staging.service.com` or whatever.
- martinald 1y ago
  Yes definitely.
- cpach 1y ago
  But these are public certificates. Most personal computers are behind NAT, i.e. they lack a public IP address.
  - spelunker 1y ago
    But my EC2 instance is public! Ok not "local" per se, but definitely could be part of development work.
hypeatei 1y ago
One use-case is connecting to a DoT (DNS-over-TLS) server directly rather than using a hostname. If you make a TLS connection to an IP address via OpenSSL, it will verify the IP SAN and fail if it's not there.
charcircuit 1y ago
It helps break free of ICANN's domain name system. This enables for competitors to support https without needing self signed certs.
Am4TIfIsER0ppos 1y ago
The intended use case is to forbid plain http so that you can't communicate with the computer in the next room without 3rd party permission.
deleted 1y ago
[deleted]

smallnix 1y ago

Is this for ipv4 and ipv6?

jaas 1y ago
It will work for both.

richm44 1y ago

Time for me to dust off CVE-2010-3170 again? :-)

NicolaiS 1y ago
I guess a bunch of "roll your own X.509 validation"-logic will have that bug, but to exploit it you need a misbehaving CA to issue you such a cert (i.e. low likelihood)

OptionOfT 1y ago

Interesting, there is no subject in the example cert shown. Is this because the certificate was requested for the IP, and other DNS entries were part of the SAN?

jaas 1y ago
We (Let's Encrypt) are getting rid of subject common names and moving to just using subject alternative names. This change has been made in short-lived (6 day) certificate profiles. It has not been made for the "classic" profile (90 day).
- tialaramex 1y ago
  Have you found much trouble with clients that can't cope without CN? Is this one of those situations where anything that can't cope is also hopeless for other reasons (e.g. can't speak TLS 1.2, doesn't understand IPv6, that sort of thing) and so you can tell people you're not their biggest problem ?
  - jcgl 1y ago
    It’d surely be something like that. CN has been deprecated and SAN support has been required for 25 years at this point[0]. [0] https://datatracker.ietf.org/doc/html/rfc2818#section-3.1 https://datatracker.ietf.org/doc/html/rfc2818#section-3.1
    - tialaramex 1y ago
      I'm aware that PKIX deprecated use of CN for this purpose at the turn of the century, but when browsers began ignoring CN about a decade ago (which is the first half of the adoption curve) I know Google had to ship an enterprise override for people whose corporate systems could not cope. If it's true that all or almost all systems now work properly that's great news.

zdw 1y ago

This seems to be for public IP addresses, not private RFC1918 ipv4 range addresses. The only challenges possible are HTTP and TLS-ALPN, not DNS, so the "proof" that you own the IP is that LetsEncrypt can contact it?

ameliaquining 1y ago
Yes, which is the same way control of a domain name is typically checked; DNS is only used in a minority of cases as it can't be as turnkey.
Hizonner 1y ago
Having DNS available wouldn't be any more "proof". The person applying gets to choose which form of proof will be provided, so adding more options can only ever make it easier to "prove" things.
- tialaramex 1y ago
  I don't happen to know if it's actively in use, or whether any of the technical implementation details were formally standardized, but one obvious thing goes like this: 1. Write a DNS record for CAA the Certificate Authority Authorization for your names 2. In the CAA record, say that you forbid anybody except your chosen CA to issue. Competent CAs will obey this instruction (obeying it is mandated by the root trust stores, there are bugs of course but on the whole compliance is very good and is separate from their implementation of specific validation methods) 3. Further, indicate, either in this record or by agreement with your chosen CA, that they must use DNS proof of control. This might be something very nerdy like indicating a specific OID for the method in the CAA record or it might be a Memorandum of Understanding somebody signed and then they went out for a nice lunch.
  - ameliaquining 1y ago
    Yes, this is a thing: https://www.rfc-editor.org/rfc/rfc8657.html#name-extensions-to-the-caa-record https://www.rfc-editor.org/rfc/rfc8657.html#name-extensions-...

lq9AJ8yrfs 1y ago

So all the addressing bodies (e.g., ISPs and cloud providers) are on board then right? They sometimes cycle through IP's with great velocity. Faster than 6 days at least. Lots of sport here, unless perhaps they cool off IPs before reallocating, or perhaps query and revoke any certs before reusing the IP? If the addressing bodies are not on board then it's a user responsibility to validate the host header and reject unwanted IP address based connections until any legacy certs are gone / or revoke any legacy certs. Or just wait to use your shiny new IP? I wonder how many IP certs you could get for how much money with the different cloud providers.

hk1337 1y ago
> I wonder how many IP certs you could get for how much money with the different cloud providers. I wonder if they'll offer wildcard certs at some point.
- qyrreqjh 1y ago
  if you're talking about lets encrypt, they started offering wildcards in 2018
  - DaSHacka 1y ago
    GP may have been talking about "wildcard IP certificates" Or, even if they weren't, now I'm curious about that possibility too.
    - bc569a80a344f9c 1y ago
      Doesn't seem like that's possible. RFC5280 (https://datatracker.ietf.org/doc/html/rfc5280 https://datatracker.ietf.org/doc/html/rfc5280) defines these fields. Section 4.2.1.6 defines SANs, and specifies: > When the subjectAltName extension contains an iPAddress, the address MUST be stored in the octet string in "network byte order", as specified in [RFC791]. The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For IP version 4, as specified in [RFC791], the octet string MUST contain exactly four octets. For IP version 6, as specified in [RFC2460], the octet string MUST contain exactly sixteen octets. That's 32 bits for IPv4 and 128 bits for IPv6. You can't store anything other than a single unicast IP address of either format with that much space.

timewizard 1y ago

I've personally never felt comfortable using regexes to solve production problems. The certificate code referenced here shows why: https://github.com/mozilla-firefox/firefox/blob/d5979c2a5c2e48c0c9ecb22ebad79fa135438454/toolkit/components/certviewer/content/certDecoder.mjs#L161 https://github.com/mozilla-firefox/firefox/blob/d5979c2a5c2e... Yikes.

ameliaquining 1y ago
I think that's not doing anything security-critical, it's just formatting an IPv6 address for display in the certificate-viewer UI.
cpburns2009 1y ago
All that regex does is split an IPv6 address into groups of 4 digits, joins them with ":", and collapses any sequence of ":0000:" to "::". I don't see anything problematic with it.
- timewizard 1y ago
  > and collapses any sequence of ":0000:" to "::" Which is an error. Any ip like 2001:0000:0000::1 is going to be incorrect. It willingly produces errors. Whoever wrote this didn't even spend a few seconds thinking about the structure of IPv6 addresses. > I don't see anything problematic with it. Other than it being completely wrong and requiring a regex to be compiled for an amount of work that's certainly less than the compilation itself.
  - cpburns2009 1y ago
    It only operates on a 32 digit IPv6 address so it won't already be abbreviated. My phrasing was inexact. It replaces only the first sequence of any number of ":0000:" to "::".
  - remram 1y ago
    > Any ip like 2001:0000:0000::1 is going to be incorrect. This is neither a possible input nor a possible output of that code.

0xbadcafebee 1y ago

Nice, another exploit for TLS. The previous ones were all about generating valid certs for a domain you don't own. This one will be for generating a cert for an IP you don't own. The blackhats will be hooting and hollering on telegram :)

jeroenhd 1y ago
IP certificates have been a thing for many years now. The only change is that Let's Encrypt now also provides them.

Hizonner 1y ago

So does anybody have a pointer to the official justification for this insanity?

fredfish 1y ago
https://github.com/cabforum/servercert/pull/579/commits https://github.com/cabforum/servercert/pull/579/commits </s?
- Hizonner 1y ago
  I'm sorry, but how is "Require validation of DNSSEC (when present) for CAA and DCV Lookups" related to issuing X.509 certs that include IP address SANs? I don't see any connection, and I didn't spot anything about it on a quick skim of the comments.
  - fredfish 1y ago
    Anything from people who are afraid of increasingly onerous DNS requirements to breakage because they can't fix their parent domains DNSSEC misconfiguration. It seems like an interesting timing coincide to me so I wonder if there's some (ir)rational explanation. (Implementing a new SAN that must inherently have the gap you are finally addressing is not a bit funny to you?)
ameliaquining 1y ago
The announcement is https://letsencrypt.org/2025/01/16/6-day-and-ip-certs/ https://letsencrypt.org/2025/01/16/6-day-and-ip-certs/. I don't think it's more complicated than: there exist services that for one reason or another don't have a domain name and are instead accessible by a public static IP address, and they need TLS certificates for security, and other CAs offer this, so Let's Encrypt should too. Is there any specific reason why they shouldn't?
- Hizonner 1y ago
  Hmm. Absolutely no explanation of why there's a need. Given only that announcement, I'd have to assume that the reason is "because we can". So the first reason not to do it is that you never want to change software without a good reason. And none of the use cases anybody's named here so far hold water. They're all either skill issues already well addressed by existing systems, or fundamental misunderstandings that don't actually work. Changing basic assumptions about naming is an extra bad idea with oak leaf clusters, because it pretty much always opens up security holes. I can't point to the specific software where somebody's made a load-bearing security assumption about IP address certificates not being available (more likely a pair of assumptions "Users will know about this" and "This can't happen/I forgot about this")... but I'll find out about it when it breaks. Furthermore, if IP certificates get into wide use (and Let's Encrypt is definitely big enough to drive that), then basically every single validator has to have a code path for IP SANs. Saying "you don't have to use it" is just as much nonsense as saying "you don't have to use IP". Every X.509 library ends up with a code path for IP SANs, and it effectively can't even be profiled out. Every library is that much bigger and that much more complicated and needs that much more maintenance and testing. It's a big externalized cost. It would better to change the RFCs to deprecate IP SANs; they never should have been standardized to begin with. It also encourages a whole bunch of bad practices that make networks brittle and unmaintainable. You should almost never see an IP address outside of a DNS zone file (or some other name resolution protocol). You can argue that people shouldn't do stupid things like hardwiring IP addresses even if they're given the tools... but that's no consolation to the third parties downstream of those stupid decisions. ... and it doesn't even work for all IP addresses, because IP addresses aren't global names. So don't forget to special-case the locally administered space in every single piece of code that touches an X.509 certificate.

zipping1549 1y ago

Boy that doesn't sound good.

vkdelta 1y ago

Does it help getting encrypted https (without self signed cert error) on my local router ? 192.168.0.1 being an example login page.

ameliaquining 1y ago
No, they won't issue a certificate for a private IP address because you don't have exclusive control over it (i.e., the same IP address would point to a different machine on someone else's network).
qmarchi 1y ago
No but maybe yes: It would be impossible, and undesirable to issue certificates for local addresses. There's no way to verify local addresses because, inherently, they're local and not globally routable. However, if a router manufacturer was so inclined, they _could_ have the device request a certificate for their public IPv4 address, given that it's not behind CG-NAT. v6 should be relatively easy since (unless you're at a cursed ISP) all v6 is generally globally routable.
- jeroenhd 1y ago
  Even behind CGNAT, you could probably get away with DNS here. If you provide your customers with customeraccount.manufacturerrouters.com, you can then use DNS validation to get a valid certificate for *.customeraccount.manufacturerrouters.com. Put a record in there that points to the local router IP (I.E. settings.customeraccount.manufacturerrouters.com) and you can get HTTPS logins on your local network, even with local IP addresses if the CAB still allows that. It's not exactly user friendly, but it'll work. Personally, I have a private CA that I use. My home router has a domain name pointing towards it and has been loaded up with my private certificate. I get the certificate error once a year when the thing expires but in the mean time I can access my router securely.
johnklos 1y ago
You have to possess the IP.
jekwoooooe 1y ago

msgodel 1y ago

This is incredibly dumb. The three way handshake and initial key exchange is your certificate.

cpburns2009 1y ago
That would be fine if browsers didn't throw up giant warning signs when using self-signed certificates.
- msgodel 1y ago
  That sounds like a defect in the browser design. Or maybe it's because you actually want an identity to verify (which an IP address is not.)
- nijave 1y ago
  Usually you can just import the leaf self signed cert as a CA in your OS trust store and the problem goes away (assuming it has an IP SAN). Slightly tedious but you can issue the certs with long validity
  - cpburns2009 1y ago
    Chrome provides no simple way to trust a self-signed cert. When you go to certificate details, the only option under the "Details" tab is "Export...". The only work around is to click "Advanced" and "Proceed to example.com (unsafe)". Chrome will then helpfully suffer amnesia in 1-3 days and completely forget you want to allow an exception for the certificate.
    - nijave 1y ago
      iirc Chrome uses OS trust store so the trust needs to be using the operating system's facility
Dylan16807 1y ago
And this protects you from a hostile network how?

foresto 1y ago

I expect SAN in this case means Subject Alternative Name, not Storage Area Network. Sigh... I wish people would use their words before trotting out possibly-ambiguous (or obscure) acronyms. It would help avoid confusion among readers who don't live and breathe the topic on the writer's mind.

parliament32 1y ago
If you don't know how to interpret "SAN" in a blog post from a TLS certificate issuer, I don't think you're the target audience for this post.
- NewJazz 1y ago
  OK, but how hard is a link to Wikipedia?
  - arccy 1y ago
    please expand the abbreviation "OK"
    - NewJazz 1y ago
      Okay
- foresto 1y ago
  Lots of people on HN are not the target audience for any given post, yet are still interested. (And my point applies to all writing and speaking, not just this post.)
  - mcpherrinm 1y ago
    If it was a blog post or announcement, we’d have surely included more context, and not a forum post really intended for limited distribution. You just used HN without expanding that acronym! :)
- 1y ago

bufferoverflow 1y ago

[dead]

Tepix 1y ago

I think certificates for IP addresses can be useful. However, if Let‘s encrypt were to support S/MIME certificates, it would have a far greater impact. Since a few years, we have an almost comical situation with email encryption: Finally, most important mail user agents (aka mail clients) support S/MIME encryption out of the box. But you need a certificate from a CA to have a smooth user experience, just like with the web. However, all CAs that offer free trustworthy¹ S/MIME certificates with a duration of a year or more² have disappeared. The result: No private entities are using email encryption. (PGP remains unused outside of geek circles because it is too awkward to use.) Let‘s encrypt our emails! ¹ A certificate isn‘t trustworthy if the CA generates the secret key for you. ² With S/MIME you need to keep your old certificates around to decrypt old mails, so having a new one frequently is not practical

figassis 1y ago
I know little about s/mime encryption. But why do we need to decrypt old emails with the same protocol? In my head, I imagine certs would be for transport, and your server or host should handle encryption at rest no? So short lived transport certs, and whatever storage encryption you want. What am I missing here?
- frozenice 1y ago
  S/MIME is about the mail (content) itself, not the transport. For the transport part there are things like (START)TLS and MTA-STS. With S/MIME you include your certificate in the mail and can either sign the mail with a signature (with your private key, others can verify it using your public key from the certificate) or encrypt the mail (with the receiver's public key, so only he can decrypt it using his private key). Certificate trust is determined normally via the CA chain and trusted CAs.
wiktor-k 1y ago
> ² With S/MIME you need to keep your old certificates around to decrypt old mails, so having a new one frequently is not practical You don't need to change your decryption key - the new certificate can use the same decryption keys as the old one (certbot even has a flag: --reuse-key). Whether this is a good idea or not is a separate question. I think the biggest benefit would be ACME-like automatic certificate issuance. Currently getting a new certificate is just too much friction.

sschueller 1y ago

What about internal IPv4 addresses? Can we have browsers ignore 192.168.x.x, 172.16.x.x and 10.x.x.x if we can't get certs for those or can we get a public wildcard for internal networks?

cpach 1y ago
I don’t believe that makes sense in the context of certificates generated by a public CA. Unlike domain names, there’s not one owner of 10.10.10.10, there are millions of “owners”… But what problem is it that you want to solve? For local development, one can use a tool such as mkcert. For shared internal resources (e.g. within a company), it’s probably easier to use a TLS cert tied to a domain instead of using naked IP addresses.
- sschueller 1y ago
  My cameras are internally accessibly via https. Every time I open a browser I need to click two buttons to get past the certificate error. Sure I could configure a real domain, do split DNS and get a certificate but these cameras require manual uploading a certificate. I would need to do this every three months for every camera and eventually even more frequently.
  - arccy 1y ago
    and IP certs would help how? you'd have to upload every 6 days. just run your own CA with ~infinite lifespan.
  - throw0101c 1y ago
    There are numerous tutorials on running your own private certificate authority (CA): * https://smallstep.com/blog/private-acme-server/ https://smallstep.com/blog/private-acme-server/ ; https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi-yubikey/ https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi... * https://openvpn.net/community-resources/setting-up-your-own-certificate-authority-ca/ https://openvpn.net/community-resources/setting-up-your-own-... * https://www.digitalocean.com/community/tutorials/how-to-set-up-and-configure-a-certificate-authority-ca-on-debian-10 https://www.digitalocean.com/community/tutorials/how-to-set-... Import the CA's root cert on your browsing devices and anything it issues will be trusted.

sgjohnson 1y ago

Shame that IP address certificates can’t be done via the DNS challenge, but I completely understand why.

1vuio0pswjnm7 1y ago

Why can't the internet regional registries issue certificates Why can't local internet registries issue certificates Why are third parties needed to verify RIR and LIR registrants Apparently the job is too much for domainname registrars Are the reasons the same