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.

  • Decronym@lemmy.decronym.xyzB
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    edit-2
    1 year ago

    Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

    Fewer Letters More Letters
    DNS Domain Name Service/System
    HTTP Hypertext Transfer Protocol, the Web
    IP Internet Protocol
    SSH Secure Shell for remote terminal access
    SSL Secure Sockets Layer, for transparent encryption
    SSO Single Sign-On
    TLS Transport Layer Security, supersedes SSL
    VPN Virtual Private Network
    nginx Popular HTTP server

    [Thread #155 for this sub, first seen 22nd Sep 2023, 05:05] [FAQ] [Full list] [Contact] [Source code]

      • meteokr@community.adiquaints.moe
        link
        fedilink
        English
        arrow-up
        6
        ·
        1 year ago

        It is primarily a http server, its ability to act as a http reverse proxy is a product of that. Apache can do the same thing, its just less common to see it used that way.

      • computergeek125@lemmy.world
        link
        fedilink
        English
        arrow-up
        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.