Hey everyone, went ahead and registered a domain w/ cloudflare, did the letsencrypt acme cert generation and all is validated. The problem is that I did not include the LAN address of the NAS on the cert chain.
I know normally you dont do that, but do want to SSL protect the NAS and apps running in it, like emby. Read the thread below:
but was not what I was looking for. This is the error in question:
Question is how do I add the LAN address so that firefox is happy? The *domain.org is just a generic name I am using, thats not my actual registered domain.
FWIW, I used the scripts developed by @Dan to bring SSL to my network components. They use SSH to not only transfer the files in question but also commands to get them installed, etc. Works great for Mikrotik and my Raspberry Pis.
As for your second question, are you running a DHCP / DNS server that associates various internal FQDNs with the IP’s in question? If so, I suggest you try entering the FQDN into the address bar instead of the IP address. If you error does not persist then that was the issue.
IP addresses in reserved address ranges like 192.168.x.x, 172.16.x.x, 10.10.x.x cannot be requested for SSL. Lots of people may have a device that legitimately corresponds to 192.168.1.1, for example. That’s not the same as “router.YourFQDN.com”.
IIUC, you issued the cert but accessed your truenas via IP. To mitigate this security popup, you have to access your truenas via FQDN (the cert was issued for).
Assuming you issued a wildcard cert for *.domain.org, you just need to create an A record for truenas.domain.org that points to lan ip (of your truenas) in your dns server (cloudflare). Then you would be able to access truenas via this exact url.
Also, AFAIK RFC1918 discourages using private IPs in public DNS. Nevertheless, it would work.
If you want to comply with best practices, then create this record on your local DNS server instead. Perhaps it is your router. I’m not sure whether every model supports it from the GUI, though.
Another possible approach is to create a CNAME record (at cloudflare) that points to truenas.lan (assuming your router’s local domain is lan and NAS hostname is truenas). Perhaps this would only work if your truenas obtain its ip via DHCP.
Not trying to muddy the waters but I used internal dns with a real domain and Cloudflare mostly internally, worked fine. Local dns used to match names to IP addresses locally, and Cloudflare api token fed to my let’s encrypt daemon at least once to generate the wildcard cert.
I have a ton of 192.168.x.x services using that cert and all the browsers accept it. But I can’t call those services with the ip in the url, they have to be named like proxmox 1.shepherd.com as long as it resolves in local dns.
I know it breaks a standard but I’m not about to assign my public ip plus a port just to satisfy a white paper. Nobody else uses these certs or these host names outside my Lan.
I don’t need external access to my network, so I use internal DNS servers.
Real domain registered on Cloudflare. It’s only used for domain validation by ACME via token. There are no IP assignment on Cloudflare. DNS settings is empty.
The internal DNS servers are assigned to devices via DHCP or statically for servers. All FQDN for devices are managed on the internal DNS servers.
Pihole does a great job resolving these internal FQDN DNS queries in addition to ad blocking. Works super well for me and my remaining to do for pihole is spinning up a third on the NAS as an App for redundancy.
Hilariously, the pihole App doesn’t allow an easy integration of SSL certificate into the App WebGUI if you want to run the App on its own internal IP address. Thank you, @dan for figuring out where to store it.
That is correct, I issued it for the top level domain. I never thought about creating a local dns record, duh.
you are correct, trying to stay compliant with rfc 1918. My router is running pfsense and since i went down this rabbit hole, may as well put an ssl for it as well, even though it’ll never ever be accessible on the wan.
It shouldn’t be hard. At least it wasn’t when I was issuing a cert for opnsense. The main issue for me was a config format. But as you are using a very popular dns hosting, I think you would easily find a guide.
I use a Split DNS setup. I have a domain name registered with Cloudflare and add public records there for services I use with Cloudflare tunnels. On my private LAN network, I add records to my internal DNS server for the same domain name. In some cases, a hostname record is duplicated on my internal DNS server and at Cloudflare but with different IP addresses. For those services that I use while out and about and then while I’m on my internal network, access is seemless.
See Split-horizon DNS - Wikipedia for more information.
Now, for that domain, I use a wildcard lets encrypt certificate for all my services including TrueNAS. I run the ACME automation outside of TrueNAS on a VM because I need to load the updated certificate using scripts I’ve written to automate the process. These scripts are run by the ACME post update hooks. This way, I access all my services, internal and externally using FQDN’s. Since my ACME updates are outside of TrueNAS, I use a go program in my deployment scripts to update my two NAS machines. I’ve made this go program available at GitHub. The current release is 1.3 and I have pre-compiled binaries available for Linux, FreeBSD, Windows, and MacOS available in the Release 1.3 section of GitHub. See GitHub - jrushford/tnascert-deploy: TrueNAS certificate deployment tool
