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.

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.

No and it shouldn’t. You can just run a proxy with a real domain and a real cert and then use dns rewrites to point that domain to a local host

For example you can use nginx manager if you want a ui and adguard for dns. Set your router to use adguard as the exclusive dns. Add a rewrite rule for your domain to point to the proxy. Register the domain and get a real cert. problem solved

All of my local services use https

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

no but you can do something closely related:

- get a domain name (foo.com) and get certificates for *.foo.com

- run a DNS resolver that maps a.b.c.d.foo.com (or a-b-c-d.foo.com) to the corresponding private IP a.b.c.d

- install the foo.com certificate on that private IP's device

then you can connect to devices in your local network via IP by using https ://192-18-1-1.foo.com

Since you need to install the certificate in step 3 above, this works better with long-lived certificates, of course, but aotomation helps there

I considered doing that for a project once.

Then I realised that when my internet was down, 192-18-1-1.foo.com wouldn't resolve. And when my internet is down is exactly when I want to access my router's admin page.

I decided simply using unencrypted HTTP is a much better choice.

> Then I realised that when my internet was down, 192-18-1-1.foo.com wouldn't resolve.

Just add a local DNS entry on your local DNS server (likely your router).

I could start running my own DNS server, and start manually curating all the important entries in it, sure.

Or I could just use HTTP, or a self-signed certificate. If an attacker intercepts traffic on twenty feet of ethernet cable in my home's walls, I've probably got bigger problems than protecting my router admin password.

You don't even need to, mDNS has been enabled by default by most devices for ages now. You'll have to look up what the name is your manufacturer chose (if you use Windows, you van usually hit the network explorer tab and it'll be right in there, don't know about other OSes). It'll even work if IPv4 is broken (if you ran out of DHCP leases or whatever) because it almost always natively runs on IPv6 too.

Cloudflare DNS (probably others as well) allows you to enter private IPs for subdomains, so you don't have to run your own DNS. There's no AXFR enabled, so no issues with privacy unless you have someone really determined to dictionary-attack your subdomains.

No, on the contrary. You can't get a valid certificate for non-global IP, but you can already get a certificate for a domain name and point it to 192.168.0.1.

You have to possess the IP.