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?


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.

  • 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 3 '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 3 '13 at 16:05
  • Thanks. I was looking around for other sites that have setups similar to mine, like <subdomain>.uservoice.com, and they also get the warning I am trying to avoid. – user173326 Jul 3 '13 at 16:12
  • This is similar to the problem that Stack Exchange itself is trying to solve. They have meta.<site>.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 3 '13 at 16:14

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;

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.

  • 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 3 '13 at 15:41

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.