1

I have a Synology NAS at home, which has a web-based user-interface which I expose to the public Internet. Inside my LAN my NAS has the hostname nas.domain.local. and on the public Internet I have the domain name home.notarealdomainname.com. pointing to my home router (which then forwards port 7000 to my NAS' HTTPS server on port 443).

My NAS comes with a self-signed certificate which isn't really fit for purpose, I would like to install an SNI certificate that supports both the hostnames nas.domain.local. in addition to home.notarealdomainname.com. - however all of the major CAs perform some form of domain-validation (as they should!) but they can't verify my .local. domain name so they wouldn't issue that certificate.

I don't want to issue my own certificate as, for expediency in use, I would like browsers to trust the certificate.

1
  • While not an answer to your question, if you have a router that supports NAT Loopback you can just forget the local domain names and always use the public ones with a valid certificate.
    – heavyd
    Dec 18, 2014 at 18:35

3 Answers 3

5

Public CAs will only issue certificates for public domains. There was a time when they did but abandoned this behavior because this caused problems with newly introduced top-level domains. Also, CA only issue certificates for domains which are only owned and used by a single party, which is not the case for internal names.

Which means: either you accept the self-signed certificate once on all internal devices or you need to roll your own private PKI structure and import the relevant root-CA on all devices.

1

I'm assuming the general problem you're trying to solve is how to enable robust HTTPS for the device for both internal and external clients, and you don't actually care if it has two different names. If that's true, you may have another option. If you have control over the DNS server for your internal network, you could have it resolve home.notarealdomainname.com to the internal IP address for internal clients. Then you just need a certificate for the public name, and you can use that name to access it both internally and externally. Here's how I do that in BIND on Ubuntu Server 14.04:

/etc/bind/rc.conf.local:

...

zone "home.notarealdomainname.com" in {
    type master;
    file "/var/lib/bind/db.home.notarealdomainname.com"
}

...

/var/lib/bind/db.home.notarealdomainname.com:

$ORIGIN .
$TTL  86400
home.notarealdomainname.com    IN SOA dnsserver.domain.local. myemail.emaildomain.com. (
                               1       ; serial
                               86400   ; refresh (1 day)
                               3600    ; retry (1 hour)
                               172800  ; expire (2 days)
                               3600    ; minimum (1 hour)
                               )
                      NS       dnsserver.domain.local.
$ORIGIN home.notarealdomainname.com.
@                         A        192.168.1.123

Basically, it's telling your local DNS server (here assumed to be dnsserver.domain.local) that it's the authority for the home.notarealdomainname.com zone (but not notarealdomainname.com, so it won't interfere with other hosts in that domain), and returning the NAS's local IP (here assumed to be 192.168.1.123) for it.

1
  • This is pretty much what I did in the end : a few months after I posted this question, I recreated my home's Active Directory domain using a subdomain of my public domain name as the AD domain name (home.example.com) and now operate a "Split-brain" DNS set-up so nas.home.example.com resolves to my NAT's public IPv4 address (with port-forwarding to the NAS) on the Internet side, but my NAS's internal IPv4 address within my LAN. This is acceptable for now, but ideally I'd just use IPv6 from my ISP so I don't need to use port-forwarding.
    – Dai
    Jun 21, 2019 at 15:54
1

I would like to install an SNI certificate

There's no such thing as an SNI certificate. That's a TLS extension, and it means the server name is sent in the ClientHello.


certificate that supports both the hostnames nas.domain.local. in addition to home.notarealdomainname.com.

The CAs probably won't issue that certificate because of nas.domain.local.

But its not clear to me where issuing it is prohibited under the CA/Browser (CA/B) Baseline Requirements documents (CA's and Browsers do what they agree upon in the CA/B Forums; they don't follow anything from the IETF or RFCs).

Because of home.notarealdomainname.com, you will satisfy section 11.1.1, Authorization by Domain Name Registrant. Section 11.3 prohibits *.local, but that's due to the wildcard (and not the local name).

Since I can't find where the CAs are prohibited from issuing the certificate, you should ask CAs about issuing a certificate that includes a local name (in addition to the public name you control).


I don't want to issue my own certificate as, for expediency in use, I would like browsers to trust the certificate.

You should perform the following steps (even though you don't quite want to do it):

  1. create your own CA
  2. create a CSR with all the names you want the server to have
  3. issue a cert based on the CSR
  4. sign the cert with your CA
  5. install your CA on your devices and machines

The only difference between the pre-trusted list of CAs in browsers and certificate stores and your CA is you have to install your CA manually.

If you need to use OpenSSL to create a CSR with multiple Subject Alt Names (like nas.domain.local and home.notarealdomainname.com), then see this question on Stack Overflow: Certificate with Extended Key Usage only works in Firefox. In particular, see the OpenSSL configuration file.


Finally, this is a known problem with the Internet of Things; and it currently lacks a solution. It was recently brought up on the Web App Security mailing list. See Proposal: Marking HTTP As Non-Secure:

I'd like to propose consideration of a fourth category: Personal
Devices (home routers, printers, IoT, raspberry pis in classrooms,
refrigerators):
- cannot, by nature, participate in DNS and CA systems
- likely on private network block
- user is the owner of the service, hence can trust self rather than CA

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .