We have a dev server that is accessible through the Internet, but is IP restricted, so security here is merely a way of allowing us to reproduce the live environment as opposed to trying to be secure. The top level domain, let's call it
dev.com, isn't used, but devs have each site set up in their own specific sub-domain. So let's say there is
site3.com, then developers
nico would have full URLs like:
I originally thought that a wildcard self-signed certificate would do, but later found that the
*.dev.com applied only to
something.dev.com and not sub-sub domains. I decided to follow the instructions in this answer. When I use:
DNS.1 = www.site2.com.nico.dev.com DNS.2 = www.site1.com.george.dev.com
everything works fine, but unfortunately there are plenty of developers of many sites, so there would be well in excess of 100 entries for
DNS.x here. I wanted to know if it's possible to use wildcards in the
[ alternate_names ] section of my
openssl.cnf. I tried the following:
DNS.1 = dev.com DNS.2 = www.site1.com.george.dev.com DNS.3 = *.*.*.nico.dev.com
DNS.3 doesn't, giving me the error
NET::ERR_CERT_COMMON_NAME_INVALID in Chrome.
Is there a way to do this, or will I have to generate a very long list of
DNS.x entries to cover all the sites?
I heard that by creating my own CA this would be possible. I followed the great instructions on this answer. With my own CA intact I created a certificate with
DNS.1 the same as the common name and
DNS.3 with wildcards like so:
DNS.1 = dev.com DNS.2 = *.dev.com DNS.3 = *.*.*.*.nico.dev.com
I then imported
cacert.pem from the first step of the guide linked to above in to chrome as a trusted root certification authority and restarted the browser. For each domain config I set the
SSLCertificateFile to the
servercert.pem respectively and tested a few domains:
- When going to the main domain, https://dev.com, I see the green padlock!
- When going to a sub-domain, https://www.dev.com, I also see the green padlock!
- When going to a URL, https://www.test.com.nico.dev.com, I see the error
- When I go to any variation of https://www.xxxxxxxxxx.com.nico.dev.com, I see the error
So it appears the first level of wildcard worked OK, but beneath that, it didn't. This is the same for Chrome and IE (which use the Windows certificates) and for Firefox (which manages its own).
So my question remains, is using sub-sub(-sub*) domains in this manner possible?