This webpage provides instructions for using the acme-dns DNS challenge method with various ACME clients to obtain HTTPS certificates for private networks. Caddy, Traefik, cert-manager, acme.sh, LEGO and Certify The Web are listed as ACME clients that support acme-dns. For each client, configuration examples are provided that show how to set API credentials and other settings to use the acme-dns service at https://api.getlocalcert.net/api/v1/acme-dns-compat to obtain certificates. Interesting that so many ACME clients support the acme-dns service, providing an easy way to obtain HTTPS certificates for private networks.
HN https://news.ycombinator.com/item?id=36674224
seiferteric: Proposes an idea for automatically creating trusted certificates for new devices on a private network.
hartmel: Mentions SCEP which allows automatic certificate enrollment for network devices.
mananaysiempre: Thinks using EJBCA for this, as hartmel suggested, adds unnecessary complexity.
8organicbits: Describes a solution using getlocalcert which issues certificates for anonymous domain names.
austin-cheney: Has a solution using TypeScript that checks for existing certificates and creates them if needed, installing them in the OS and browser.
bruce511: Says automating the process is possible.
lolinder: Mentions Caddy will automatically create and manage certificates for local domains.
frfl: Uses Lego to get a Let’s Encrypt certificate for a local network website using the DNS challenge.
donselaar: Recommends DANE which works well for private networks without a public CA, but lacks browser support.
Plenty of non-browser related reasons to want HTTPS in your own network.
If you need it/should use it depends on your system architecture and level of paranoia.
For instance we’re running all our stuff in a virtualized Linux environment on-premise on our own hardware. There’s a firewall zone from the outside and in, several zones for different applications.
We terminate SSL at the edge and use port 80 for anything internal that’s HTTP.
While that opens us up to internal eavesdropping my argument is that anyone that deep in our system will have compromised everything anyways.
On the other hand it allows our firewall to do application filtering, including killing bad (as in faith) incoming requests.
The only caveat to that is that some of our external pen-testers think they’ve found a DOS scenario in our application when all that happens is that the firewall drops the connection.
If I was routing traffic over a shared network or multiple sites I’d definitely employ HTTPS.
All this said, I’m sure someone smarter than me have written better opinions on the topic.