Selfhosted

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 for both reverse proxy and certificates makes it well integrated and certificates are trivial to renew. With that said, if you have your own domain, go the let's encrypt subdomain route instead imo. It saves you a lot of manual labor with setting up your CA on every device you own and creating new certificates for each site.

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)

For inside the lan/lab, I have my pem chain looks like:

cold storage root-ca -> offline vault qubes VM ca -> pfsense ca -> freeipa ca

I use letsencrypt for externally facing services.

Its a little bit more effort than getting things just workin' but its worth the whole lotta security you get in return. Plus it feels nice looking at a shiny green lock.

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

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...

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).

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.

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 :)

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

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.

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

https://youtu.be/liV3c9m_OX8

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

4 acronyms in this thread; the most compressed thread commented on today has 16 acronyms.

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

Look into DNS-01 challenge where instead of exposing 80/443, 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.

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 service 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.

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.

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.

@gblues If you use something like yggdrasil, you don't need to bother w/ ssl certs. Just make sure your services are listening on the yggdrasil-specific IPv6 port only, and whenever you connect to one over plain http:// you're guaranteed to have an encrypted, verified connection.