If self-signed certificates are too much, then perhaps this is, too - You can use Let's Encrypt SSL certs locally for the Intranet/LAN as well. Get a wildcard SSL cert for a lan-reserved subdomain of a TLD (e.g. local.mytld.com) through a DNS API (e.g. cloudflare - any other DNS API works, too). Override DNS entries in your router to redirect to local services, e.g.:
cloud.mytld.com -> 192.168.0.10
gitlab.mytld.com -> 192.168.0.11
You can have your services individually query Let's encrypt (ACME), or have your router get the wildcard cert and deploy this locally (e.g. ssh, ftp). No one external can reach your services, no one external knows how your services are called (in case of wildcard certs). You do not need to open any port for this.
Inspired by this thread I just did this, except not with the wildcard.
I have a droplet at Digital Ocean, so I used their DNS service. I configured some CNAME records for the local services, pointing to the internal names[1]. I then configured my PiHole with a local DNS CNAME record, pointing service.local.example.com to service.localdomain.
Since my PiHole is not the DHCP server, I had to add a local DNS record for service.localdomain which matched the static IP that my router gives out. It seems the conditional forwarding done by PiHole happens earlier in the resolution process.
I could then configure my services to use the DNS challenge for service.local.example.com, using the DO plugin for certbot[2] or just acme.sh[3], depending on what was available.
I didn't get it to work immediately on Android devices, until I discovered that Android only uses IPv6 DNS servers if it has an IPv6 address, and I hadn't configured that in my router. So added the static ULA address of the PiHole lease to the DHCPv6 DNS server announcement[4].
Was a bit of fiddling since I'm a networking nub, but went smoother than I had feared.
Not sure how to best distribute certificates though, if I had found a way I could let the router do all the renewals.
[1]: Not sure if this is needed but didn't bother experimenting with removing it yet.
> pointing service.local.example.com to service.localdomain
Not sure if I understand correctly, but service.local.example.com must point to your internal IP. You do not need a localdomain and the SSL certs will only work for what they were generated for (service.local.example.com). However, you can very much point your local DNS server's entry for service.local.example.com to any local IP, resolving these services internally. For that matter, you can equally simply edit the `hosts` file and add overrides.
For the ACME-certs I suggest using the fullchain-cert that you get from Let's Encrypt for service.local.example.com (e.g. in the nginx reverse proxy). Firefox/Chrome will typically not complain if you do not serve intermediate CA SSL certs, but it is better to provide the full chain of certs.
> Not sure how to best distribute certificates though, if I had found a way I could let the router do all the renewals.
My router is pfsense, I added a hook that stores SSL certs to a local NAS folder via script:
Action List: `sh /conf/acme/store_certs_nas.sh`.
From there, it is easy to pull certs through cronjobs on services.
> Not sure if I understand correctly, but service.local.example.com must point to your internal IP.
Yes, that is handled by the PiHole Local DNS configuration I mentioned later. Of course this only works internally in my network, if you ask DigitalOcean's nameservers for service.local.example.com they return NXDOMAIN (along with the CNAME). This way I don't need to keep the public DNS records in sync with my local IP addresses as defined by the static DHCP leases.
I'm not sure if I really need the CNAME entry to complete the DNS challenge, will do some more testing later.
> I added a hook that stores SSL certs to a local NAS folder
That's similar to what I had in mind. The acme.sh plugin for OpenWRT seems to be missing the ability to run post-renewal scripts though, unless I'm blind. Seems ripe for a contribution.
You can have your services individually query Let's encrypt (ACME), or have your router get the wildcard cert and deploy this locally (e.g. ssh, ftp). No one external can reach your services, no one external knows how your services are called (in case of wildcard certs). You do not need to open any port for this.