If you think of it this way, maybe you can better understand why things are the way they are.
CAs try to help one prove they are who they say they are.
They can only do that if you are unique.
Where everyone everywhere knows where, and how, to find that unique you.
If you take away that uniqueness, then anyone can be everyone/everywhere.
You think that your IP/common name may not coincide with anyone else.
Although that may be true, here you need to think more like a "bad guy".
If such persons were to find out anyone else's IP/common name, they could then go to any CA and get a duplicate cert for that IP/common name.
And they could use that valid, and trusted, cert that to help them achieve their "bad intentions".
I don't think we agree on that. It is something you desire is all we can agree on
A public CA will (probably) be trusted by your clients already. But, then you must prove control of the domain used in the cert on the public internet.
You could consider getting a public domain name and setup DNS at some DNS provider, like Cloudflare, and get a cert from Let's Encrypt using a DNS Challenge. You will need outbound access to the internet from a client of yours to request and renew this cert but otherwise can be disconnected from it. You would not need to define any public IP in the DNS. Once you have the cert on this client you could even sneaker-net it over to the server in your private net if you want a 100% airgap. That seems extreme for what you describe as an HA system but whatever floats your boat
Otherwise, you can setup a private cert as described by others and your clients will need to be taught to trust it.
Self-signed certificates (assuming not a large number of servers and clients).
Let's Encrypt does not fit into this scenario; as Let's Encrypt is on the Public Internet and not LOCAL and certainly not Completely LOCAL! As @danb35 has already stated here: Completely LOCAL! - #4 by danb35
No, it wouldn't. Any cert from any public CA is public knowledge.
Exactly right. So you can create your own CA, and you can tell your devices to trust it--as several others, including me, have pointed out. And that really is the only solution to your requirement that's anywhere close to "good."
And in regards to "this should be easier", well sure. It'd be nice if popular home/prosumer main Internet gateway routers built in a CA and could automatically issue certificates (maybe even over the ACME protocol), much like they tend to have recursive DNS resolvers, NTP servers, DHCP servers, and so forth. Plus it'd be nice if there were an easy intended-to-use-in-the-home policy configuration that browsers could use to add that CA to their trust store in a similar way to how large enterprises can configure them. But there's a lot of work to be done to have that kind of automatic solution, and I haven't seen a lot of movement in that direction yet myself, but yeah, eventually it might be a thing.
Really I suspect the problem may be more that browsers have moved to an HTTPS-centric mindset (generally for good reasons), trying HTTPS first and only having the latest features over it and so forth, whereas there is limited support for browsers treating things on the "local network" as secure in the same way (beyond some special cases for "localhost"). Part of it is it can be hard to define "local network" (as just what administrative boundary is "local" doesn't always coincide with concepts like "on my subnet"). And with most things moving, for better or worse, to the "cloud", it may be not something that most companies are working on improving and standardizing.
You've been shown, repeatedly, why Let's Encrypt can't solve this problem. You've also been shown, repeatedly, how you can solve this problem. Have you read those posts? Do you understand them? If not, what part is unclear? Surely one of us can clarify it. If so, why are you concerned who the solution comes from, as long as it's solved?
The solutions presented are unusable for me. But that appears to be the best the current CA architecture offers. Some heavy lifting is required to make local https a similar user experience to that of the public one. It is a special case that there is little incentive to solve. You may not understand that, but there is no sense in beating this dead horse. I think this thread has gone long enough.
