5

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 site1.com, site2.com and site3.com, then developers george and nico would have full URLs like:

  • www.site1.com.george.dev.com
  • www.site2.com.george.dev.com
  • www.site1.com.nico.dev.com
  • etc

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

Whereas DNS.2 worked, 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.2 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 SSLCertificateKeyFile and SSLCertificateFile to the serverkey.pem and servercert.pem respectively and tested a few domains:

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?

Michael
  • 173
  • 9
Leonard Challis
  • 23
  • 3
  • 12
  • 26

2 Answers2

3

Public Signed Certs:

Technical Answer

Yes. There is nothing preventing the creation of wildcard sub-domain SAN certificates with any mix of wildcard levels and domains. If you manage your own internal CA, then you can create a SAN cert with any combination of sub-domains, wildcards, etc.

Practical Answer based on my own experiences

No. or not likely... I am not aware of any CA's that will sell you one of these. I have asked several CA's for this very solution and every one of the immediately rejected the request. I suspect they fear losing money on offering such certs. They prefer you have one wildcard for each zone (sub-domain or not) or one SAN cert with up to n number of entries. n being the number that particular CA will limit you to. I could not find a CA that will sell a SAN cert with a mix of wildcard sub-domain entries. I would provide a list of the CA's I queried, but I suspect that may not be appropriate here.

[Update]

Self Signed Certs

I had mis-understood the intent of the question. I believe an example openssl.cnf was desired. Here is one example You would need to replace the DNS entries with your wildcard sub-domain names. There are some posts on security.stackexchange.com as well around this setup. I have not tested this, as my needs were around publicly accessible URL's and CA's would not allow this as an option.

Community
  • 1
Aaron
  • 2,809
  • 2
  • 11
  • 29
  • I probably didn't make this clear enough, but I don't want (a) paid cert(s) - this is a dev server and it's *only* for staff from specific IPs. So, if I setup my own CA I could do this and it should work? Using the method I specified above? – Leonard Challis Aug 09 '15 at 12:09
  • Apologies @LeonardChallis, I thought you were masking a TLD and I indeed mis-understood the intent of the question. I updated my answer, though I have not tested this myself, since the CA's would not sell such a certificate to me. I know it can be done as others in my field of done this. – Aaron Aug 10 '15 at 19:45
  • Much appreciated Aaron, I'll try this tomorrow and report back, hopefully with a nice green tick :) – Leonard Challis Aug 10 '15 at 21:29
  • I've updated my question – Leonard Challis Aug 12 '15 at 09:11
  • Without knowing the actual domains, I can not see what your cert looks like. You may also want to test using dNSName vs. alt_names see [this F5 KB](https://support.f5.com/kb/en-us/solutions/public/11000/400/sol11438.html) Perhaps also test having several non-wildcard entries to ensure your SAN cert is valid, then add the wildcards. – Aaron Aug 12 '15 at 15:40
2

You can only have one level of wildcard.

*.example.com will cover anything.example.com, but not one.anything.example.com.

*.subdomain.example.com will handle anything.subdomain.example.com.

Sean
  • 36
  • 1
  • Thanks Sean, this certainly seems to line-up with my tests. Do you have any documentation or links to support this? Thanks – Leonard Challis Aug 14 '15 at 06:30
  • 2
    @LeonardChallis See http://serverfault.com/questions/104160/wildcard-ssl-certificate-for-second-level-subdomain and http://stackoverflow.com/questions/5295521/problems-with-ssl-and-multi-level-subdomains . Also see the Baseline Requirements at https://cabforum.org/baseline-requirements-documents/ which define Wildcard Certificate as an asterisk (\*) in the **left-most position** of a FQDN. (The Extended Validation requirements don't allow **any** wildcards.) – dave_thompson_085 Aug 19 '15 at 08:27