3

I've got a wildcard SSL certificate for *.example.com.

I'm using Nginx, and redirecting all traffic for HTTP to HTTPS, and also rewriting the URLs to remove a www subdomain (if there is one).

So it has,

  1. http://subdomain.example.com ---> https://subdomain.example.com
  2. http://www.subdomain.example.com ---> https://subdomain.example.com
  3. https://www.subdomain.example.com ---> https://subdomain.example.com
  4. https://subdomain.example.com ---> https://subdomain.example.com

However, since my cert is for *.example.com, case 3 gets an SSL error in chrome ("This is probably not the site that you are looking for!"), but if you click through it gets redirected and all is well.

I understand why, since the initial connection is for HTTPS with a www (2 levels of subdomains), which doesn't match what is on the wildcard certificate.

I thought a solution would be to get an additional cert for *.*.example.com to cover www.*.example.com. But it seems like that won't work. I spoke to agents from Namecheap and Comodo, and both said *.*.example.com was not possible.

I also came across this article that states:

Will SSL work with multilevel wildcards?

With the distribution of Firefox 3.5, all major browsers allow only a single level of subdomain matching with certificate names that contain wildcards, in conformance with RFC 2818.

In other words the certificate *.mydomain.com will work for one.mydomain.com or two.mydomain.com but NOT one.two.mydomain.com.

Is there a solution to this? To be able to cover www.*.example.com?

Community
  • 1
user173326
  • 33
  • 3
  • sort of similar to http://serverfault.com/questions/520168/can-i-create-a-wildcard-ssl-cert-for-a-subdomain but defeats my purpose of getting a wildcard subdomain – user173326 Jul 03 '13 at 14:58

3 Answers3

4

Wildcard certs only go one level deep. You will need to get a wildcard that also has subject-alternate names for all www.<subdomain>.example.com sites. This will allow the redirection to happen.

Any solution other than putting valid certs on the two-level-deep subdomains will not work, because the SSL handshake will always happen before any redirection or re-writing.

MDMarra
  • 100,734
  • 32
  • 197
  • 329
  • I've read about SAN before and understand it can cover multiple domains. Can it also do something like www.*.example.com? The reason I needed a wildcard, was because I am giving out subdomains to users. Thanks – user173326 Jul 03 '13 at 15:52
  • 1
    It cannot. You can add SANs to wildcard certain but you can never have a wildcard in the middle like you want. This is why you almost never see anyone with the setup you are describing. – MDMarra Jul 03 '13 at 16:05
  • Thanks. I was looking around for other sites that have setups similar to mine, like .uservoice.com, and they also get the warning I am trying to avoid. – user173326 Jul 03 '13 at 16:12
  • This is similar to the problem that Stack Exchange itself is trying to solve. They have `meta..stackexchange.com` and haven't come up with a good way to handle SSL. I think they're probably going to throw a lot of money and some config management tools at it to automatically provision and install new certs when new sites are added. A single-cert solution just doesn't really exist for this kind of thing. – MDMarra Jul 03 '13 at 16:14
1

Small workaround is to rewrite URLs before establishing SSL connection, but you will never get https://www.subdomain.mydomain.com working without a warning before you get certificate for this domain name. Something like that:

server {
 listen 111.222.333.444:80;
 server_name www.subdomain.mydomain.com;

 rewrite ^ https://$host$request_uri permanent;
}

server {
 listen 111.222.333.444:443
 server_name subdomain.mydomain.com
 ssl on;
 ...
}
StamPit
  • 26
  • 3
-1

The problem is how wildcard certs work. They only work on first-level subdomains as you're seeing. To work around this, you'd want to use a PTR record to point www.subdomain.domain.com to subdomain.domain.com and it should be invisible to the server.

Nathan C
  • 15,059
  • 4
  • 43
  • 62
  • 2
    A PTR record isn't going to help anything here. I think you may have meant CNAME, but even that won't help. DNS solutions can't fix this. – MDMarra Jul 03 '13 at 15:41