I want my self hosted things to use https. For example, I have Jellyfin installed via docker, and I want it to use https instead of http.

I don’t care about necessarily doing this the “right” way, as I won’t be making Jellyfin or any other service public, and will only be using it on my local network.

What is the easiest way to do this? Assume everything I host is in docker. Also a link to a tutorial would be great.

Thanks!

  • hperrin@lemmy.world
    link
    fedilink
    English
    arrow-up
    58
    arrow-down
    3
    ·
    11 days ago

    The easiest way to do it is to do it the right way with LetsEncrypt. The hardest way to do it is the wrong way, where you create your own CA, import it as a root CA into all of the machines you’ll be accessing your servers from, then create and sign your own certs using your CA to use in your servers.

    • TCB13@lemmy.world
      link
      fedilink
      English
      arrow-up
      14
      ·
      11 days ago

      Yes, LetsEncrypt with DNS-01 challenge is the easiest way to go. Be it a single wildcard for all hosts or not.

      Running a CA is cool however, just be aware of the risks involved with running your own CA.

      You’re adding a root certificate to your systems that will effectively accept any certificate issued with your CA’s key. If your PK gets stolen somehow and you don’t notice it, someone might be issuing certificates that are valid for those machines. Also real CA’s also have ways to revoke certificates that are checked by browsers (OCSP and CRLs), they may employ other techniques such as cross signing and chains of trust. All those make it so a compromised certificate is revoked and not trusted by anyone after the fact.

      • Findmysec@infosec.pub
        link
        fedilink
        English
        arrow-up
        4
        ·
        edit-2
        10 days ago

        Running a CA is cool however, just be aware of the risks involved with running your own CA.

        All they say that if the private key is stolen then you’re screwed. Think about it, if an attacker can:

        1. Get into your network.
        2. Presumably bypass key-based ssh/container runtime protections
        3. Access pod/VM which is running the CA
        4. Bypass default MAC settings (Apparmor on debian, SELinux on RHEL)
        5. Steal private key without you knowing from your logs

        You have a much bigger problem my friend

        • TCB13@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          10 days ago

          While I agree with you, an attacker may not need to go to such lengths in order to get the PK. The admin might misplace it or have a backup somewhere in plain text. People aren’t also prone to look to logs and it might be too late when they actually noticed that the CA was compromised.

          Managing an entire CA safely and deploying certificates > complex; Getting let’s encrypt certificates using DNS challenges > easy;

    • Scrubbles@poptalk.scrubbles.tech
      link
      fedilink
      English
      arrow-up
      9
      ·
      11 days ago

      Tried that once. It was not a fun route to go down. If let’s encrypt ever dies it anything fine, I’ll look into it again. Until then, let’s encrypt all the way

    • Findmysec@infosec.pub
      link
      fedilink
      English
      arrow-up
      7
      ·
      10 days ago

      why is creating one’s own CA the wrong way? I don’t want to have to pay cloudflare or porkbun to run HTTPS at home

      • hperrin@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        3
        ·
        edit-2
        10 days ago

        Because you have to manage it on your server and all your own machines, and it doesn’t provide any value if your server is hacked. It actually makes you less safe if your server is hacked, because then you can consider every machine that has that CA as compromised. There’s no reason to use HTTPS if you’re running your own CA. If you don’t trust your router, you shouldn’t trust anything you do on your network. Just use HTTP or use a port forward to localhost through ssh if you don’t trust your own network.

        You don’t have to pay anyone to use HTTPS at home. Just use a free subdomain and HTTP validation for certbot.

        • irotsoma@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          10 days ago

          I agree that it’s the wrong way, but not because of any of this other than the first half of the first sentence.

          It’s the hard/wrong way because it means you are having to be responsible for securing the root cert private keys and because most people will do it wrong and set up a root cert with the ability to sign not just tls certs, and that’s where the problems can occur if the keys are compromised and you’ve set up all of your machines to trust it.

          But it’s also not true that you shouldn’t use HTTPS or that you should trust your own network, not because of the router, but because of the devices. People don’t control their devices anymore. Many home automation devices, nanny cams, security devices, water leak detectors, etc., contain firmware that is poorly configured and can easily expose your network traffic if it’s not encrypted. Not to mention a lot of apps these days on smartphones are Trojans for spyware, Temu, WeChat, etc.

          And as for cost, you can get a domain name for a few dollars per year or as mentioned, a subdomain from something like a DDNS service, so it definitely can be totally free to do it the right way.

    • Matt The Horwood@lemmy.horwood.cloud
      link
      fedilink
      English
      arrow-up
      4
      ·
      11 days ago

      I use the OVH plugin to get a wildcard cert for my homelab, that way I can spin up anything and its covered by the cert.

      Also, Proxmox and PFSense use the OVH let’s encrypt plugin to be secured as well

    • philpo@feddit.de
      link
      fedilink
      English
      arrow-up
      3
      ·
      11 days ago

      Yeah. Exactly how I do it. .casa domain to distinguish it from my other domains, DNS challenge and I am good.

      Proxmox and OPN Sense work with it themselves, for everything else I use NPM on Proxmox. Couldn’t be more happy with that solution.

  • seang96@spgrn.com
    link
    fedilink
    English
    arrow-up
    32
    ·
    11 days ago

    Reverse proxy and letsencrypt. Doing custom certificates is more difficult and you would need to install and trust the certificate on all devices.

    • AbidanYre@lemmy.world
      link
      fedilink
      English
      arrow-up
      8
      ·
      11 days ago

      This assumes ownership of a domain if I’m not mistaken.

      Otherwise, yes this is the easiest way.

      • jonne@infosec.pub
        link
        fedilink
        English
        arrow-up
        9
        ·
        11 days ago

        If needed you could use a subdomain from a free dyndns provider. And if you’re going to be self hosting stuff having your own domain is probably good anyway.

      • Creat@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        9
        ·
        11 days ago

        There are dyndns providers that support the DNS challenge that have free tiers. Those are sufficient, and you can even get wildcard certs for your subdomain that way. Perfectly sufficient for a homelab.

          • Creat@discuss.tchncs.de
            link
            fedilink
            English
            arrow-up
            2
            ·
            11 days ago

            Yes exactly. I didn’t wanna name-drop them cause they are closed for new dynDNS signups. You can create an account to manage your own domain, but you currently can’t signup for their dynDNS service, unfortunately.

            That being said, I would still highly recommend them for managing your own domain, if you’re looking for a place to host literally just the DNS part.

    • Findmysec@infosec.pub
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 days ago

      Yeah I guess installing a root CA cert (or an Intermediate, depending on how complex your setup is) and automatically rotating certs upon expiry isn’t the most trivial thing. With that said, dekstop linux/windows isn’t a problem. You could theoretically do it on iOS too. Android recently has completely broken this method, however, and there’s a fair few hoops one must jump over to insert a root CA into the Android trust store on Android 13 and later. I’d like find a way to do it just for browsers on Android using adb if possible

    • thirdBreakfast@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 days ago

      I agree. Get a domain name, point it to the internal address of your NGINX Proxy manager (or other reverse proxy that manages certificates that you are used to). A bit of work initially, then trivial to add services afterwards.

      I didn’t really need encryption for my internal services (although I guess that’s good), but I kept getting papercuts with browser warnings, not being able to save passwords, and some services (eg container repository on Forgejo) just flat out refusing to trust a http connection.

  • Realitaetsverlust@lemmy.zip
    link
    fedilink
    English
    arrow-up
    16
    arrow-down
    2
    ·
    11 days ago

    I usw nginxproymanager for that. It has an integrated function to create and update letsencrypt certificates. Creating a New host takes like 1 minute.

  • doodledup@lemmy.world
    link
    fedilink
    English
    arrow-up
    14
    arrow-down
    1
    ·
    11 days ago

    Nginx Proxy Manager is awesome for managing certificates. I have all of my services running behind it.

    • Tinkerer@lemmy.ca
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 days ago

      I do this too, have acls setup for my main LAN ips and all my internal hosts setup in opnsense in hosts override so they get redirected to NPM. Not sure if this is the correct way but it gives me all valid certificates. You could also do domain override and redirect just that domain to your NPM.

    • jonno@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      7
      ·
      11 days ago

      Or use caddy with a dns challenge. No need to open any ports and just use it completely locally without any annoying warning.

  • Findmysec@infosec.pub
    link
    fedilink
    English
    arrow-up
    12
    arrow-down
    2
    ·
    edit-2
    10 days ago

    The easiest way is to pay for a public domain, use a subdomain of that which does not have an A record on the wide internet, and then use certbot to get Let’s Encrypt certificates for them and auto-renew. Stuff these in your individual reverse-proxy instances (or propagate them, no idea how) and you’re done

  • cmnybo@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    7
    ·
    11 days ago

    I just add my CA to my devices and use self signed certificates for stuff on my LAN. I don’t want to go through all the trouble of using lets encrypt for something that’s not accessible from the internet.

    • catloaf@lemm.ee
      link
      fedilink
      English
      arrow-up
      6
      arrow-down
      1
      ·
      11 days ago

      This is the most permanent solution. You can generate valid and trusted certs for as long as you want. Let’s Encrypt is great, but you also have to configure the automation to keep renewing the certs every 30 days.

    • TCB13@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      ·
      11 days ago

      Just be aware of the risks involved with running your own CA.

      You’re adding a root certificate to your systems that will effectively accept any certificate issued with your CA’s key. If your PK gets stolen somehow and you don’t notice it, someone might be issuing certificates that are valid for those machines. Also real CA’s also have ways to revoke certificates that are checked by browsers (OCSP and CRLs), they may employ other techniques such as cross signing and chains of trust. All those make it so a compromised certificate is revoked and not trusted by anyone after the fact.

      For what’s worth, LetsEncrypt with DNS-01 challenge is way easier to deploy and maintain in your internal hosts than adding a CA and dealing with all the devices that might not like custom CAs. Also more secure.

    • postnataldrip@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      11 days ago

      If you mean signed by your CA then this is me too, albeit with an intermediate CA in the middle (honestly pointless in my case, but old habits etc).

      I don’t host anything externally and trusting the CA certs internally is easy as Ionly need to do it on a handful of devices. This + reverse proxy keeps things tidy and uncomplicated.

    • azl@lemmy.sdf.org
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 days ago

      I’ve been doing it this way for many years, before LetsEncrypt was around. Maybe some day I will switch so I can become dependent on another third party (though I do use LetsEncrypt for public-facing services).

      Yes, telling your computer to trust a certificate chain that you are responsible for securing may significantly increase your attack surface. It’s easy to forget about that root cert (I actually push mine via GPO).

  • towerful@programming.dev
    link
    fedilink
    English
    arrow-up
    6
    ·
    11 days ago

    Nginx Proxy Manager is probably perfect for you.
    Pick a domain (like mylab.home or something), set up your home network to resolve that domains IP as your docker hosts IP.
    NPM will do self-signed certs. So, you will get a “warning, Https is insecure” kinda page when you visit it. You could import NPMs root cert into your OS/browser so it trusts it (or set up an “don’t warn for this domain” or something).

    If you don’t want per-client config to trust it, then you need to buy a domain, use a DNS that supports letsencrypt DNS-challenge, and grab certs that way (means you don’t need a publicly accessible well-known route exposed)

  • jet@hackertalks.com
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    11 days ago

    IPv6 addresses and letsencrypt

    If your addresses are globally unique, you don’t have to care about internal or external

  • AmbiguousProps@lemmy.today
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    edit-2
    11 days ago

    There’s a few ways, but for example you can use a service like cloudflared which comes with its own certs (and then set up WAF rules to only allow your IP), or you could set something up using let’s encrypt via reverse proxy (for example, using Opnsense and the let’s encrypt plugin which actually validates domains that aren’t otherwise exposed to the internet, there by giving you full blown validated SSL).

    If you don’t care about validation errors then you can use nginx reverse proxies (locally, not exposing any ports externally) and apply self-signed certs through the proxy regardless of whether or not the software allows SSL config.

  • Decronym@lemmy.decronym.xyzB
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    edit-2
    9 days ago

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

    Fewer Letters More Letters
    CA (SSL) Certificate Authority
    DNS Domain Name Service/System
    HTTP Hypertext Transfer Protocol, the Web
    HTTPS HTTP over SSL
    IP Internet Protocol
    SSL Secure Sockets Layer, for transparent encryption
    TLS Transport Layer Security, supersedes SSL
    nginx Popular HTTP server

    [Thread #856 for this sub, first seen 7th Jul 2024, 03:25] [FAQ] [Full list] [Contact] [Source code]

  • gencha@lemm.ee
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    11 days ago

    I roll out Step CA to my workstation with an Ansible role. All other clients on the lab trust this CA and are allowed to request certificates for themselves through ACME, like LetsEncrypt.

    All my services on all clients on the network are exposed through traefik, which also handles the ACME process.

    When it comes to Jellyfin, this is entirely counter-productive. Your media server needs to be accessible to be useful. Jellyfin should be run with host networking to enable DLNA, which will never pass through TLS. Additionally, not all clients support custom CAs. Chromecast or the OS on a TV are prime candidates to break once you move your Jellyfin entirely behind a proxy with custom CA certificates. You can waste a lot of time on this and achieve very little. If you only use the web UI for Jellyfin, then you might not care, but I prefer to keep this service out of the fancy HTTPS setup.