Let's Encrypt: use Subject Alternative Name for internal domain

Question

My Synology NAS is capable of running the web interface via HTTPS. By default, you access the NAS via its name (say, mynas) so http(s)://myname:5001 or http(s)://myname.local. It defaults to an SSL certificate for synology.com.

You can create a new cert using Let's Encrypt; you forward the required ports from your router to your NAS, I created a sub domain from a domain I own and updated the DNS to point towards my home ip. (e.g. home.my-domain-i-own.com)

I was hoping I could enter myname;myname.local as subject alternative names, so I can browse my NAS internally via HTTPS without warning. However, Let's Encrypt doesn't accept domain names it can't validate, apparently.

My question: how to solve the issue I can use a Let's Encrypt cert with my domain mynas.local without any warnings?

Answer 1

The problem

You don't own the domain name mynas.local, so of course Let's Encrypt won't sign a certificate saying that you own that domain. If they signed such certificates, browsers would very soon stop trusting Let's Encrypt.

Instead what you need to do is to use your own domain name to access the NAS regardless of where you access it from. This is not only because of the certificate, it is also because it is more convenient if you have any mobile devices which need to access the NAS both from inside your LAN and from outside.

It sounds like you have a NAT on your network which is getting in the way of just pointing your domain name at the IP of your NAS. If you did not use NAT, this would just work.

The solution

The ideal solution is to use a network without NAT. You can still have a firewall blocking connections from the outside to everything but the HTTPS port on the NAS, if you want to.

It is unlikely that your ISP would give you enough IPv4 addresses for such a setup, so if you wanted to do it that way, you would have to do it with IPv6.

You can configure your LAN such that IPv4 is NATed by your gateway and IPv6 is routed without NAT. For the name you have chosen for your NAS you can then create both an A record pointing to your NAT and an AAAA record pointing to the NAS.

Clients on your LAN will then have an IPv6 path directly to the NAS and should prefer using the AAAA record. Using the IPv4 address would involve hairpin NAT, but that would only be used as fallback in case the IPv6 connection fails. Given that client and NAS would be just one hop from each other with no router between them, it should be rare that the IPv6 connectivity fails.

Clients from outside your LAN will use IPv4 or IPv6 depending on the network they are connected to. If they are on an IPv4-only network they will need to go through the port forwarding on your NAT, which you should leave configured the same way as it is now.

A workaround

If your ISP does not support IPv6 yet, then there isn't a clean solution to your problem. However there are still possible workarounds.

You can configure your own DNS server on the NAT gateway. This DNS server will need to consider itself authoritative for your domain and recurse for everything else. This DNS server will have to hand out local addresses when asked for your domain.

Clients on the LAN will be given a local IP address and connect directly to the NAS. Clients outside your LAN will not be using the DNS server on your NAT gateway, instead they will receive responses from the real authoritative server pointing to your external IP.

Answer 2

Further to kasperd's answer, this is an example of the workaround.

I used DNS to fix this issue in my home network. I use a pi-hole to provide my DNS service on a RaspberryPi. From the dashboard, choose 'Local DNS Records' and put the mynas.synology.me as the hostname with its IP address.

I use the 'Synology Active backup for business agent' to protect my local PCs so when the certificate changes, backups stop because the agent must create an exception for the new certificate. This should allow my backups to continue to work, even when the certificate changes.

Answer 3

It's impossible because you don't own mynas.local this domain in the internet (i.e. ownership).

Answer 4

Let's Encrypt (or any other public CA, actually) will not give you a certificate for a domain unless you can prove to be its rightful owner; that's the whole raison d'être of certificates: proving to clients that they are really connecting to the servers they are looking for; if anyone could get trusted certificates for any domain, they would be completely useless.

As others have said, a solution is to use a domain you actually own; you get a certificate for it, install it on the NAS and point your internal DNS to it, so that when your browser tries to connect to "nas.mydomain.com" it goes to the NAS's internal IP address (and finds a valid certificate there).

Another solution is setting up an internal CA, make sure your browser trusts it and use it to create the certificate for your NAS; this would allow you to create certificates for any domain (but of course only you would trust them). This would however require a server on which to run the CA (it's a built-in role in Windows servers, there surely are similar solutions for Linux).

However, IMHO the easiest solution would be to create a self-signed certificate, install it on your NAS and tell your browser to just trust it; the browser will thus stop complaining. How to do this depends on the browser and the OS you are using.