Home

Hello everyone. Need some opinions here. Does it worth all the trouble to make things like jellyfin and immich run with HTTPS for services that are only accesible in the LAN? I ask it ‘cause, as far as I know, there is no way to put a valid certificate like let’s encrypt for a service that is not accessible from the net and I don’t plan to buy a certificate for myself. But I have some trouble with the rest of my family having issue with their browsers complaining about the lack of https every time a browser is updated. So, what would be the best solution?

You can use DNS01 for services not accessible from the outside. I use a caddy reverse proxy, with a wildcard cert for *.mydomain.com. caddy handles that for me automagically. Needed? Maybe not, but it’s a whole lot prettier, and I learned new things about certs and caddy :)

Let’s encrypt doesn’t have to be accessible from the web, it accesses the web itself. It’s a subtly difference i guess, but you don’t need port forwarding or anything. Of course if your jellyfin/immich net is completely blocked from going out on the internet then it still won’t work. > as far as I know, there is no way to put a valid certificate like let’s encrypt for a service that is not accessible from the net

I don’t think that’s true. But Let’s encrypt does need to verify the domain name. If it’s just a domain you made up in your LAN that is an issue yes. But I have no experience with that though.

You could use self-signed certificates, they are free. but you would need to add custom trusted CA to all the user devices manually. I’ve never done this myself so no clue how troublesome this really is.

What I do is have a reverse proxy that requests a wildcard certificate (e.g ‘*.example.com’) with Let’s encrypt. And then route all my services through the reverse proxy with subdomains. You can get free domains with duckdns.org or others.

as far as I know, there is no way to put a valid certificate like let’s encrypt for a service that is not accessible from the net

There definitely is. All of my local services run on a wildcard cert that I got from a DNS challenge with Let’s Encrypt. As long as the reverse proxy can access whatever source is issuing the certificate, and as long as the client browser can access public certificate ledgers and has DNS info about your services, things will work just fine locally.

I recommend Netbird to give access to services to your family members, for access control and for the DNS server it provides. It also gives you the bonus of accessing your services remotely.

Feel free to ask if you have any questions.

Look into DNS-01 challenge where instead of exposing ⁸⁰⁄₄₄₃, you obtain a cert by creating a TXT record for your domain. This requires your ACME client to support talking to your DNS provider’s API. For certbot they’re installable via plugins, for lego-acme many providers are included.

When I went through the trouble of doing that, I got nginx reverse proxy set up and then got a Let’s Encrypt for my internal local addressing scheme through Let’s Encrypt.

It was kind of intimidating to set up, but it worked flawlessly.

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

[Thread #176 for this comm, first seen 16th Mar 2026, 23:00] [FAQ] [Full list] [Contact] [Source code]

Just do not use wildcard, very bad security practice. Getting individual cert for each service is easy these days.

Huh? Why?

I do DNS challenges with let’s encrypt for either host fqnds (for my kubes cluster) or wildcard for the few other services.

The trick is to do a subdomain off of a domain that you own (e.g. thing.lan.mydomain.com) this way, you can scope the DNS to only *.lan.mydomain.com if you’re conscious about scoped api security.

Using let’s encrypt is nice because you can have a valid ssl chain that android, iOS, windows, and Linux all trust with their default trusts without having to do something with a custom CA (ask me how awful that process can be).

That sounds cool and kind of makes sense. I’m going to go learn more about this.

Https is pretty trivial to deploy so I would personally set it up

Because a stolen cert can do a lot more damage

It is all about least privilege

Wildcard is actually good these days because you don’t have to set up DNS entries for your hostnames.

It’s not security, just obscurity - but in the age of crawlers, it’s helpful.

Also, you can use it internally for services on LAN and because LetsEncrypt is a CA everyone trusts, you don’t need to register a local CA (like a FreeIPA instance) with all your devices- which sometimes isn’t possible.

it’s not security, just obscurity

IIRC for my setup it’s a bit of both. My DNS API key is scoped to only handle the specific subdomain updates instead of my entire DNS account.

I still use a wildcard for that subdomain for non-kubernetes systems, but the cert plugins for kubes is excellent at handling a LE cert per lan fqdn.

You don’t need to register a local CA

This was my biggest reason to move to Let’s Encrypt. I have a Hashicorp Vault instance in my homelab for secrets and I tried using it for an internal CA (like how the lab at work is set up), but trying to get on every device and add the full Vault chain to each individual system’s trust store was massive pain in the ass.

This is what i do. Have certbot running every night, and it’ll auto skip if it is too soon to renew. If renew is successful then it’ll deploy. Pretty much set and forget it.

I have my Firefox configured to force HTTPS, so it’s rather inconvenient to work with any non-HTTPS sites.

Because of that I decided to make my own CA. But since I’m running in Kubernetes and using cert-manager for certs, this was really easy. Add a resource for a self-singed issuer, issue a CA cert, then create an issuer based on that CA cert. 3 Kubernetes resources total: https://cert-manager.io/docs/configuration/ca/ and finally import the CA cert on your various devices.

However this can also be done using LetsEncrypt, with the DNS01 challenge. That way you don’t need to expose anything to the Internet, and you don’t need to import a CA on all of your devices. Any cert you issue will however appear in certificate transparency logs. So if you don’t want anyone to know that you are running a Sonarr instance, you shouldn’t issue a certificate with that in it’s name. A way around that is a wildcard cert. Which you can then apply to all your subservices without exposing the individual service in logs. The wildcard will still be visible in the logs though…

Once you accept the certificate it being not blessed isn’t much of an issue. And just turning it on should just generate a self signed certificate on anything not a piece of shit.

I had a Let’s Encrypt for an internal domain for a while. It was a wildcard subdomain of one of my external domains. *.x.y.com I created it by setting up a temp webserver and creating it from there. I ran into internal issues because I also had hairpinning for some services and not others.

Alternatively, you could do your own CA with something like EasyCA. You’d have to add the CA cert to all devices, but once you do, you have full control to create any certs you want.

I use this tutorial to setup external only and internal only URLs both with SSL

https://youtu.be/liV3c9m_OX8

for start private keys should never leave the system which uses them. Wildcards are even worse, as if one host got compromised, all others can be spoofed.

My router has Caddy to reverse proxy all http sites which uses a certificate it gets from let’s encrypt.

For inside the lan/lab, I have my pem chain looks like: cold storage root-ca -> offline vault qubes VM ca -> pfsense ca -> freeipa

I use letsencrypt for externally facing services.

My DNS provider doesn’t have an API for setting DNS, which makes doing dns CNAME validation manual.

Therefore, what I do is:

• Have a public nginx server and point public DNS records to it, then generate certs against it
• Pull those certs to my internal nginx server in my lan
• Use pi.hole to set internal DNS records (so jellyfin.mydomain.com points to 10.10.110.23 within my network)

Many people talking about using subdomains, but that’s only really a thing if you actually have a domain. Just last year the domain .internal was reserved for internal use, so that’s what I’ve set up all my domains to use. E.g. https://pihole.internal/, https://proxmox.internal/.

To make this work I use pihole’s local dns records to rewrite any *.internal domain to point to my reverse proxy Caddy’s ip.

As for the certificates, I created my own CA, which I install on all my and my family’s devices. Then, for each new url I set up, I create a new certificate and sign it with my CA certificate, then have my reverse proxy serve it.

This all sounds like a lot of work, and it is, but using OPNsense plugins for the reverse proxy and handling certificates in opnsense means it’s manageable and certificates are trivial to renew. With that said, if you have your own domain, go that route instead imo. It saves you a lot of manual labor with setting up your CA in every device you own and creating new certificates for each site.

thanks, I’ll look at it!