101

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.

josswinn
  • 1,125
  • 2
  • 7
  • 4

5 Answers5

91

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).

Dai
  • 2,251
  • 8
  • 27
  • 42
freiheit
  • 14,334
  • 1
  • 46
  • 69
18

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

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
6

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.

user2001798
  • 81
  • 1
  • 2
  • 11
    This is not true for AWS Certificate Manager as of 2017-09-20. – pho3nixf1re Sep 20 '17 at 18:42
  • There is no "the" root domain for a SAN certificate which can secure multiple root domains. – Jez May 23 '18 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 09 '20 at 00:05
  • Agree AWS ACM wild card does not support naked domain – DollarAkshay Mar 13 '21 at 08:46
5

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.

alejandrob
  • 151
  • 1
  • 2
  • 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 – james.c.funk Aug 30 '22 at 14:28
-3

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.

Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
skilledpeas
  • 43
  • 4