[marknadal]

Correct.

Probably can even configure local network file servers, but better if not.

If we don't ever need to use domains in the mesh (we have a separate directory / search system).

Wait, I only have to have the certs locally (offline) on the routers?

Ahh, hmm, cause you're saying I could MITM it. But Browsers (especially on mobile) all usually freak out when they go to `https://subnetIPaddress` saying "your connection is not private" "back to safety" every single time, with freakishly small "prcooed anyways" links on mobile. Either way, mobile or not, this warning totally just trashes the experience. How do I fix that?

Or you're saying they still type in the domain? But doesn't that require existing internet to then go through? Or you're saying, router still MITM that, but happens to have matching private key, so then it is able to locally (offline) proxy the traffic into the mesh? Hmmmmmmmmmmm!!!! This might be very helpful. Sucks we still have to buy certs to run our own offline system - who has the longest certs? (Let's Encrypt is like only 3 months?)

Super thanks to everyone for helping us!

[rswail]

You won't have to buy certs from LetsEncrypt, they're provided free. So you'd have to have an external DNS that allows you to provision DNS records for mymesh.example.com and request a wildcard certificate for that domain.

The script is automated and will ensure that the certificate is always up to date.

Inside the mesh you would need:

* Have an internal DNS that resolves myserver.mymesh.example.com to an internal IP address

* Distribute the private key and certificate to the internal servers of your mesh.

* Have the browsers/clients of your mesh use the DNS names instead of raw IP addresses. So users would have to learn to go to https://myserver.mymesh.example.com instead of https://a.b.c.d

What you will need to do is have an internal DNS server that resolves "myserver.mymesh.example.com" to an internal IP address. The server would use the *.mymesh.example.com private key and cert.

[comex]

To further clarify, running an internal DNS server doesn't require a MitM, as the DNS server address for a network is generally supplied as part of DHCP. (There is one reason you might want to do a MitM, but I really don't recommend it. Namely, some people change their settings to ignore the DHCP-supplied DNS server and hardcode an address, e.g. 8.8.8.8, which they would fail to reach if the network isn't connected to the Internet. In theory you could work around the issue by redirecting such traffic to your own DNS server.)

As for longest certs, the CA/Browser Forum Baseline Requirements (which all CAs have to follow) specify a maximum validity period of 825 days, or a little over 2 years. You should be able to find CAs offering certs with that period. (Why such a specific number? I have no idea.)

[shkkmo]

It is true, instead of MITMing the HTTP request, you can MITM the DNS request. The issue then is that you need to distribute and configure the private key and certificate on all the static file servers rather than just on the router

[shkkmo]

> Or you're saying, router still MITM that, but happens to have matching private key, so then it is able to locally (offline) proxy the traffic into the mesh?

The router needs both the private key and a signed cert recent cert. Neither machine needs access to to the internet to validate the cert. The client uses it's preinstalled root certificate public keys to see if any of them signed the certificate provided by the server (any intermediate certs are also provided by the server).

The only online requirement is to have the clients recieve SOME non-local ip address in response to their initial DNS query for the domain (the specific IP address doesn't necissarily matter since the router will be intercepting the request before it is routed using that IP address)

You can get longer multi-year certs, but Let's Encrypt doesn't charge and allows you to script the automatic regeneration of new certs.