How are y’all managing internal network certificates?

At any point in time, I have between 2-10 services, often running on a network behind an nginx reverse proxy, with some variation in certificates, none ideal. Here’s what I’ve done in the past:

  • setup a CLI CA using openssl
    • somewhat works, but importing CAs into phones was a hassle.
  • self sign single cert per service
    • works, very kludgy, very easy
  • expose http port only on lo interface for sensitive services (e.g. pihole admin), ssh local tunnel when needed

I see easy-RSA seems to be more user friendly these days, but haven’t tried it yet.

I’m tempted to try this setup for my local LAN facing (as exposed to tunnel only, such as pihole) services:

  • Get letsencrypt cert for single public DNS domain (e.g. lan.mydomain.org)… not sure about wildcard cert.
  • use letsencrypt on nginx reverse proxy, expose various services as suburls (e.g. lan.mydomain.org/nextcloud)

Curious what y’all do and if I’m missing anything basic.

I have no intention of exposing these outside my local network, and prefer as less client side changes as possible.

  • @computergeek125English
    2•1 year ago

    And to make your terminology life a bit harder, the distinction between forward and reverse proxy matters: reverse proxies sit in front of web servers, while forward proxies sit in front of systems or networks.

    Reverse proxies pretend to be the web server they’re terminating traffic for - programs like nginx, Apache (https), lighttpd, and HAProxy you may see doing this.

    Forward proxies need to be told where to go by a web browser, and will then (if the ACL allows) connect (and often but not always filter) the browser to the final server. In some networks, the forward proxy can be seen as something like a firewall but specifically for web traffic. The only forward proxy I know of off hand is Squid, but I imagine many more exist that I do not remember.