Can internal certificates handle wildcard domains and/or entire subnets?

[Stilez]

Two questions about internal certificate generation within FreeNAS:

• The certificate system can handle wildcard domains (*.example.com) but can I generate such a cert within FreeNAS?
• Similarly, certificates can include IP addresses as well as FQDNs but can they cover ranges/subnets of IP addresses? If so, what is the syntax, and can this be done within the GUI?

If either or both of these are possible within the FreeNAS GUI, what would the correct syntax be?

 

[dlavigne]

Why would you want to do that? That pretty much goes against the whole point of trust provided by certificates.

 

[jgreco]

Two questions about internal certificate generation within FreeNAS:

• The certificate system can handle wildcard domains (*.example.com) but can I generate such a cert within FreeNAS?
• Similarly, certificates can include IP addresses as well as FQDNs but can they cover ranges/subnets of IP addresses? If so, what is the syntax, and can this be done within the GUI?

If either or both of these are possible within the FreeNAS GUI, what would the correct syntax be?

You can certainly come up with the necessary SSL incantations to generate a wildcard certificate, though this probably cannot be done via the GUI.

Certificates have been slowly deprecating the use of the Common Name as the primary identifier, and replacing it with the DNS: and IP: entries in the SAN field. This is sucky and messy and a total botch in many ways, but it deals pretty narrowly with several major issues with SSL.

You can cover ranges or subnets of IP addresses, but only by including each IP address. There may be an extension somewhere that allows more complicated specifications, but browsers have had a hard enough time getting even the simple stuff right. If you try to include a list of dozens or hundreds of IP addresses in the SAN, I'm guessing at least one browser will break.

https://en.wikipedia.org/wiki/Subject_Alternative_Name

 

[Stilez]

Why would you want to do that? That pretty much goes against the whole point of trust provided by certificates.

Dru - I don't understand this comment. I use a range of servers/devices (test build, backup, etc) locally on my LAN. Several of them are controlled via webUIs. If I'm using the FreeNAS local CA (freenas.mylocalnet @ 10.0.0.2) as a trusted CA for my FreeNAS GUI under HTTPS, I might as well use it as the CA for my backup FreeNAS server GUI (freenas-backup.mylocalnet @ 10.0.0.3), my mail server (mail.mylocalnet @ 10.0.0.4), and various other local servers/services, otherwise they're all in effect untrusted in my browser.

I don't understand why stipulating that my FreeNAS internal CA is a trusted CA for certificates of the machine at freenas.mylocalnet @ 10.0.0.2 (its own GUI) is fine, but stipulating that it's also a trusted CA for my backup server's GUI (freenas-backup.mylocalnet @ 10.0.0.3) is "going against the whole point of trust". Surely I can have multiple devices all vouched for by the same trusted CA - that's exactly what CAs do.

Also surely it's more secure to have just one local device acting as a trusted CA, given that any self-certificating device of that kind needs its root cert added to any machine that has to trust it. (i.e., surely safer to have only one local/self root cert, that's added to any LAN device needing to trust these, rather than having to add a separate root cert in relation to every device whose GUI or services can operate over HTTPS usiong its own internal CA). That way there's only one extra root CA that I have to add, and trust, for all SSL/TLS on the entire LAN, not several. I don't see how it can break the trust model.

 

[Stilez]

You can cover ranges or subnets of IP addresses, but only by including each IP address. There may be an extension somewhere that allows more complicated specifications, but browsers have had a hard enough time getting even the simple stuff right. If you try to include a list of dozens or hundreds of IP addresses in the SAN, I'm guessing at least one browser will break.

I take it this means that if I want my server to act as a CA for other LAN devices, there had better be either (a) very few of them with well defined IPs, or (b) LAN devices accessed by host name + domain, and locally resolvable using local DNS, hosts file, or some other kind of local resolver?

 

[jgreco]

I take it this means that if I want my server to act as a CA for other LAN devices, there had better be either (a) very few of them with well defined IPs, or (b) LAN devices accessed by host name + domain, and locally resolvable using local DNS, hosts file, or some other kind of local resolver?

Okay, so stepping back a minute, let me just say I know very little about the FreeNAS CA system other than to have observed it exists and appears to be able to set up a private and intermediate CA. I have, however, worked extensively with OpenSSL, and to a lesser extent Microsoft, and the principles are generally the same. I've done OpenSSL local CA designs for enterprise purposes where it is undesirable, impractical, or impossible to reasonably maintain certificates, due to location of a host (not Internet-reachable), security model, etc. You cover a lot of territory in a short question.

Certificates and DNS are not, despite the deceptive nature of "SAN: DNS," linked - you can do certs without the DNS protocol, using /etc/hosts or something else instead. When a name is referred to in a certificate SAN DNS field, it really means that the validating host will try to do a host lookup, typically a gethostbyname(3) variant, which in this modern era is implemented as DNS, but can also be implemented by /etc/hosts or YP/NIS or other more obscure technologies, and FreeBSD fully supports these. See nsswitch.conf(5) for more info on that.

You can create "local DNS" with a variety of tools and if you do so, and all your systems are configured to use that service, then yes, you can have "yourstuff.local" or something like that. And you can make certificates for that, and it'll work. You will not be able to generate LetsEncrypt certificates for something in a locally defined domain, so creating your own CA and loading those certs into your systems is the only practical solution.

If you decide to roll your own CA, you *can* generate a wildcard certificate for *.local, but this is a poor implementation. You are better off creating a CSR on each of your devices, signing it with your private CA, and getting a unique certificate per device. Ideally you also want to do this with a nailed-down IP, which lets you add the SAN:IP field. DHCP is kinda very evil for most things you'd want to install a server certificate on. This is the only practical way to generate hundreds of certificates and have the security mean anything.