[marknadal]

This sucks, my community[1] has a local offline-first video/audio call app that we run on a physical mesh network.

This will make it impossible for people to talk to each other, without first needing to be connected online to some certificate authority, or without some extraordinarily difficult pre-installation process, which is often not even possible on a phone.

HTTPS was important, but now its being used to shoe horn dependency on centralized online-only authority. Perfectly ripe to censor anyone.

1. https://gitter.im/amark/gun

[comex]

A browser doesn't need to connect to the certificate authority to validate a cert; only the server hosting the app 'needs' to be online (at least long enough to obtain a signed certificate every so often).

The bigger problem is that there has to be a single server hosting the app in the first place, which IMO is a severe flaw in the Web's architecture. But this change doesn't really make the situation worse.

[marknadal]

Subnet IPs are always different tho. Can I really get a cert for all subnet addresses? That'd be awesome! Please please educate me.

I want to be clear though, I need it so that the user doesn't have to install the cert themselves, or have to be online to approve.

Previously, a user would connect to the local wireless network, then the router would open them up to a directory listing of the local apps available on the network (like the video/audio call), they click the link (just points to the dynamic subnet IP of a static file server) to load the offline HTML page which then connects to call anyone in the network, including users on neighbor and neighbor-of-neighbors routers.

Basically our own decentralized telecom!

[comex]

SSL certificates are typically issued for domains and aren't tied to a specific IP address. So you need a domain name, and clients need to be able to resolve that domain to your IP, which means the network needs a DNS server – but the DNS server itself doesn't have to be online at all times, it just has to know what IP to return for your domain. I am not sure how that works with your mesh setup.

Note that some domain validation methods involve the certificate authority resolving the domain to an IP address and trying to connect to it on the public Internet – but not all. Let's Encrypt, for example, supports the dns-01 method, which just requires a custom TXT record to be set on the domain. (But of course the TXT record itself needs to be on the public Internet.) That said, since your goal is to work offline, you may want to use a different CA that issues longer-lived SSL certificates, since Let's Encrypt only gives you 3 months at a time.

[tialaramex]

Since we're talking about a Web Browser I'm going to assume we're talking about the Web PKI - certificates that are trusted in common software like web browsers that use TLS.

Leaf certificates in the Web PKI specify one or more SANs (Subject Alternative Names, the "alternative" is because this is the Internet's alternative to the way the X.500 directory system was designed, you don't use the X.500 directory system so you don't care about this) which can each be either an IP address (either IPv4 or IPv6) or it can be any Fully Qualified Domain Name (like bobs-laptop.example.com) from the Internet DNS or it can be a "Wildcard" like *.servers.example.com, which is considered a "match" for any Fully Qualified Domain Name that has exactly one label (a name with no dots in it) instead of the asterisk, so it would batch bigfiles.servers.example.com, and www.servers.example.com but not www.example.com or bigfiles.servers.microsoft.com)

You can get software (such as "Certbot" or "acme.sh") to help obtain trusted certificates periodically from the Internet automatically (at no cost) for a machine which has a Fully Qualified Domain Name on the Internet and is connected to the Internet at least sometimes. You may need to write software yourself to manage actually installing such certificates if your server software is custom - if you use common server software like Apache the tools can do it for you. The no cost option is provided by a charity, ISRG. If you're not a charity and appreciate the service you might consider sending a few bucks their way so they can keep doing this.

If your servers are not ordinarily connected to the Internet, but you do own an Internet domain name (e.g. example.com) you can just make up names for them in that domain and you will be able to obtain certificates for those made-up names, since you control the domain they're your names to do with as you please. But doing this is a bunch more work than the scenario where they're on the Internet.

[shkkmo]

I'm not familiar with this exact setup, but I am assuming you have full control over the router software, but want to limit any installation or configuration of either the browser's computer or the local network fileservers.

> Subnet IPs are always different tho. Can I really get a cert for all subnet addresses?

SSL certs don't usually have anything to do with the IP address, that is usually handled by the hosts file / DNS entries.

There is no reason the non-profit can't get a domain and a free SSL cert and distribute that cert and it's private key with the router software as a default while allowing admins to install/configure their own domain and SSL cert.

The router can then MITM all requests to that domain using a SSL termination proxy for the file server.

[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]

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

[fulafel]

If you are running a network disconnected from the internet, it follows logically that you'll have to reconfigured the normally internet-anchored security mechanisms on end-devices. You always have the option of using another app for this too.

Are you sure you don't want confidentiality on the audio/video calls on your network? After all it's passing through all the mesh nodes and vulnerable to eavesdropping.

[marknadal]

We do end-to-end encryption with WebCrypto in the browser, but WebCrypto is only available on HTTPS :P which (tho sister comment might be onto something!) making it hard to access our subnet IPs offline in the first place!

[tenebrisalietum]

It's been over a year, but I played around with PKI and installing your own self-signed root certs on iPhone and Android (for HTTPS) was not hard.

[Avamander]

But having to start exchanging root certs is not trivial in mesh environments, it's also insecure if you have to accept someone else's root.