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?


3 Answers 3


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, 2013 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, 2013 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, 2013 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, 2013 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, 2013 at 15:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .