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.

You must log in to answer this question.

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