I ask this question, because Comodo are telling me that a wildcard certificate for *.example.com will also secure the root domain example.com. So with a single certificate, both my.example.com and example.com 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 *.example.com and example.com, whereas the recent certificate from Comodo only lists *.example.com as the Common Name and NOT example.com 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: http://www.digicert.com/subject-alternative-name.htm It seems that the SAN must list both in order to work as I need it to. What's your experience?

Thanks very much.

5 Answers 5


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 *.example.com cert,

  • a.example.com should pass
  • www.example.com should pass
  • example.com should not pass
  • a.b.example.com 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., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

RFC 2459 says:

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

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


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


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.

  • 11
    This is not true for AWS Certificate Manager as of 2017-09-20. Sep 20, 2017 at 18:42
  • There is no "the" root domain for a SAN certificate which can secure multiple root domains.
    – Jez
    May 23, 2018 at 11:58
  • 1
    Apparently, Let'sEncryp free TLS wildcard certificates do not carry that SAN in an automatic fashion. I wasted a day of work blaming nginx settings for an ambiguous oversight regarding SSL Wildcard certificates
    – alejandrob
    Feb 9, 2020 at 0:05
  • Agree AWS ACM wild card does not support naked domain Mar 13, 2021 at 8:46

Basically, and for your needs (that started this whole thread) your wildcard certificate should be specified as both root AND first-level wildcards:

"example.com, *.example.com"

This way, a single wildcard certificate will cover both the root domain (example.com) AND any first-level subdomains (sub1.example.com, sub2.example.com, ...)

A certificate in the form of "*.example.com" MUST have a sub-domain name. Thus the root domain is explicitly excluded since the asterisk does not accept NULL as a valid name.

TIP: Free Let's Encrypt (LE) certification authority allows this. Not all Certification Authorities abide to multilevel wildcards. You should always check with your CA provider.

  • It's weird but you may have to explicitly do this in in your AWS cert request. I ran into issue because I assumed this would be default Aug 30, 2022 at 14:28

Wildcard certificates are ideally generated for *.example.com 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 *.example.com one.example.com - server 1 example.com - server 2

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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