[szszrk]

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]

So go to keys-are-names.

There's no reason AT ALL to bring IP addresses into the mix.

[nine_k]

Consider Wireguard: it works at IP level, but gives you identity by crypto key. You can live without proper DNS in a small internal network.

(This obviously lives well without the IP certs under discussion.)

[szszrk]

> 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.

[arianvanp]

https://yggdrasil-network.github.io/

Its a mesh routing network where your identity is your public key and your ipv6 address is derived from the hash of your public key.

Works perfectly

[Hizonner]

>> 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:// 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).

[freeone3000]

The BSD networking stack treats an IP addr as a valid hostname for hostname resolution. As such, every phone, tablet, and computer able to do TLS by hostname can do it by IP. Try it out! Self-sign an IP certificate and try it on your local net. If you put it in the trust store, it’ll validate just fine. The only barrier to adoption was CAs refusing to issue IP certificates at large.

[mananaysiempre]

Noot quite. DNS hostnames and IP addresses are encoded differently in X.509 certs: one is the dNSName option of the GeneralName choice type in the subjectAltName extension[1], the other is the iPAddress option. (And before you ask, tagging a stringified IP address quad as a dNSName is misissuance per the CA/Browser Forum Baseline Requirements[2] and liable to get your CA kicked from certificate stores. Ambiguous encodings are dangerous.) So some explicit support from the TLS library is indeed required. But I’m indeed not aware of many apps having problems with IP address certs.

[1] https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....

[2] https://cabforum.org/working-groups/server/baseline-requirem...

[Hizonner]

Um, the BSD networking stack I'm familiar with doesn't include TLS or X.509 validation at all. The question isn't what you get from gethostbyname. It's what you get when you hand that to your X.509 validator.

[szszrk]

> go do a survey of all the code out there, and see how much of it supports IP address certificates.

I've been doing that for years on onprem (~60% old "enterprise/legacy" ~40% modern stuff) and never seen anything that doesn't support it. YMMV, but if all I work with supports it, I won't complain in vain.

> those parts are going to choke if you just blindly go and stick IP addresses in https:// URLs.

I did many times, seems that legacy heavens were always kind to me in this regard.

> something you're going to want to change all the time, like an IP address

That's a personal assumption as well. If your architectures change IPs all the time, OK. Ones I worked with didn't. Always had plenty of components with IPs that didn't changed in a decade or two. Even my two previous local ISPs I had gave me "dynamic public IP" and kept them for many years. For some companies changing an ip of their main firewalls/load balancers or VPN servers is unthinkable.

Even on my last project on Public Cloud, the first thing I did was to make sure public IPs won't be dynamic (will survive recreation of services) so I don't have to deal with consequences of my corporate client endpoints and proxies flushing DNS caches randomly. (don't ask me why, but even huge companies still use proxies on a large scale. Good luck with figuring out when such proxy invalidates your DNS record).

> in the IPv4 space

IPv6 is here. Your printer and light bulb will want a cert as well.