I considered that, but I think at the moment there's no concept of IP address for web certificates, it's all based on domain names as far as I know.

It doesn't mean it's not doable of course, but I could understand if it make people uneasy since it means that the same domain and the same certificate would behave differently depending on what it resolves to.

It may be an interesting solution to consider though. That would definitely make my life easier.

> there's no concept of IP address for web certificates, it's all based on domain names as far as I know

Regardless of whether you can or can't issue a certificate with a CN of an IP address, the browser doesn't receive the certificate in isolation, it receives it from an IP address, and can handle certificate validation differently depending on what it's connected to.

This may be a terrible idea for reasons I haven't considered (it probably is), but I can't think of any off head myself right now.

EDIT: this is probably terrible because someone can just stick a MITM proxy on your lan, and poison your DNS to resolve google.com to a RFC1918 address and boom.

You absolutely can get a certificate for an IP address. Clients should verify them based on the common name, and a subject alternative name has various field types including IP address.

A quick Google search shows various certificate authorities who will issue certificates for IP addresses.

Public addresses only though:

https://stackoverflow.com/questions/2043617/is-it-possible-t...

Whitelisting specific addresses makes me uncomfortable.

But I can't actually articulate why it would be bad in this instance, so maybe it's fine...

well, rfc1918 addresses just specify which ranges should not be advertised into the default free zone. (aka, the internet routing table). It says nothing about if a network is LAN or not.

One could totally build a network with globally routed addresses, and not announce those addresses to the rest of the world.

> "One could totally build a network with globally routed addresses, and not announce those addresses to the rest of the world."

Could, and people do; I've worked on networks where the original people must have misunderstood networking and did the equivalent of using 10.0.0.0/8, 11.0.0.0/8, 12.0.0.0/8 for internal networks, including public /8s they didn't own, so they lost access to one or two chunks of the internet - and it never seemed to cause all that many problems for them working this way (so no motivation to do a big involved risky rework-everything project). We added new private network subnets for new build things, but never swapped everything over. It'll phase out eventually I guess.

There are companies who’ve been using public IPs on their intranet for decades, however.