Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I ask this question, because Comodo are telling me that a wildcard certificate for * will also secure the root domain So with a single certificate, both and are secured without warning from a browser.

However, this is not the case with the certificate I've been provided. My sub-domains are secured fine and do not give an error, but the root domain throws up an error in the browser, saying the identify can't be verified.

When I compare this certificate to other similar scenarios, I see that in the scenarios that work without error, the Subject Alternative Name (SAN) lists both * and, whereas the recent certificate from Comodo only lists * as the Common Name and NOT as the Subject Alternative Name.

Can anyone confirm/clarify that the root domain should be listed in SAN details if it is also to be secured correctly?

When I read this: It seems that the SAN must list both in order to work as I need it to. What's your experience?

Thanks very much.

share|improve this question
up vote 40 down vote accepted

There's some inconsistency between SSL implementations on how they match wildcards, however you'll need the root as an alternate name for that to work with most clients.

For a * cert,

  • should pass
  • should pass
  • shouldn't pass
  • may pass depending on implementation (but probably not).

Essentially, the standards say that the * should match 1 or more non-dot characters, but some implementations allow a dot.

The canonical answer should be in RFC 2818 (HTTP Over TLS):

Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., * matches but not f*.com matches but not

RFC 2459 says:

  • A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, * would match,, etc. but would not match

If you need a cert to work for, and, you need a certificate with subjectAltNames so that you have "" and "*" (or and all the other names you might need to match).

share|improve this answer

You're correct, the root domain needs to be an alternate name for it to validate.

share|improve this answer

Every SSL provider I have ever used will automatically add the root domain as a Subject Alternative Name to a wildcard SSL certificate, so DOMAIN.COM will work automatically for a *.DOMAIN.COM wildcard cert.

share|improve this answer

Wildcard certificates are ideally generated for * In order to secure your sub-domains and domains with this certificate, all you need to do is install the same certificate on servers pointing to these domains.

For ex - you have wildcard certificate for * - server 1 - server 2

you need to install this certificate on server 1 and server 2.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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