Using Letsencrypt Cert on LAN?

I have installed acme and have it working. I have a dynamic IP that rarely changes, but use a dynamic DNS service. I have opened port 443 to test that it works from the outside, but I don't need or want external access, so I disabled it. I really just want HTTPS access on my LAN, but how do I get the Letsencrypt certificate to work locally. It always failed when I tried adding my local IP or domain name.

I know I can use a locally signed certificate, but I was just wanting to see if I could use a signed cert so I wouldn't get that annoying browser message when connecting.

Simply put: You can't, at least not with Let's Encrypt. They do not issue certificates for private IP addresses as their verification is based on the domain name.

You could, however, issue a wildcard certificate, set up a local DNS that redirects to your private IP addresses and only ever access the router with your domain name. If you do a quick web search, you are going to find a few tutorials on how to set this up (not OpenWrt specific, so you would swap out the DNS stuff)

EDIT: Sorry, the problem is not the IP, but the domain name. The certificates are bound to a domain name and this domain needs to be reachable by Let's Encrypt in order to do the verification. The second paragraph still applies!

Or ditch https and use http only.
It all comes done to trust.
Do you trust your lan?

You can do dns-validation instead of http for unreachable addresses. Let's Encrypt will happily issue certificates for any name you control. It doesn't need to be accessible on the Internet.

But using a wildcard is probably easier if that's an option.

1 Like

Jup, my bad, the edit didn't make it much clearer what I meant.

Regarding the wildcard: I read an article before where the wildcard certificate was distributed to several devices on the LAN, eliminating the need for individual certificates for the devices.

@NJC2 I do exactly this. Let's Encrypt issues me a wildcard certificate (*.domain.org) and creates the certificate on my routing OpenWRT device which I have named (openwrt1.domain.org). I copy this certificate to my other openwrt, file server, Home Assistant, etc. devices (openwrt2.domain.org, nas.domain.org, ha.domain.org, ...). As long as I use the domain names and not the (internal) IP addresses to access these, I get the trusty lock symbol. I also don't yet enable access form outside.

Cloudflare DDNS keeps the domain and IP address in sync.

My next step is automate the certificate distribution.

There's an acme package for OpenWrt which can obtain a certificate for you based on dns challenge. That would solve the problem of "distributing" certificate to your OpenWrt device(s).

1 Like

You can do it. No public IP needed.

Use a dynamic DNS service such as dynv6.com, which supports creating TXT records programmatically. Get a zone. Set up openwrt.your-zone.dynv6.net to point to 192.168.1.1. Create a nsupdate key there. Set up ACME to use DNS-based challenge for openwrt.your-zone.dynv6.net, provide it with the nsupdate key that you created earlier. Wait while it creates and deletes _acme-challenge.openwrt.your-zone.dynv6.net TXT record as directed by Let's Encrypt, getting a certificate in the process. Done.

Also recommended: in DHCP and DNS, explicitly map openwrt.your-zone.dynv6.net to 192.168.1.1, so that it is accessible via domain name even when yout internet connection is down.

the LE certificate would have been issued against your DDNS domain name. You will need to configure your internal DNS (i.e. DNSMasq on your router) to resolve this to your routers internal interface. After you have configured DNSMasq then check that pinging your DDNS domain name returns the IP address of the internal interface on the router. Next, use your browser to connect to your router on the internal interface *** using your DDNS domain name ****

Note that by doing the above you will have lost DNSMasq resolution to your DDNS name in the public namespace. You will need to sort out how to get around this. There are several ways but none are elegant and will cause serious issues with any applications that need to resolve to the public namespace. TBH i don't see much benefit in what you are trying to do.

actually you can just add in the DDNS domain name -> local router IP address in your local hosts file on your PC. This should be enough to connect to your router using your DDNS name and LE certificates without affecting applications on the router. But any applications on your PC will still not resolve correctly to the public namespace. You will be running a split DNS namespace on your PC.

Yes. I use the acme package for the 1st router. Seems inefficient to run on the 2 others when it would be the same certificate. And that wouldn't solve the HA, NAS & other needs.

What I'm looking for is an automated certificate distribution solution that is sufficiently mindful of the security needed around private key certificate info.

And yet again, the acme package is that solution.

And "yet again", one that seems wastefully duplicative, and that wouldn't solve for my non-OpenWRT needs.

Why get Let's Encrypt to issue exactly the same certificate to an instance of acme on each server when one can just copy the one already issued? Something like a cron job of scp.

wouldn't rsync fit the job of syncing certs across routers ?

1 Like