I have a server that responds to domains like a.b.c.example.com. a b and c are dynamic parts and I want to cover them all with a single SSL certificate.

I created wildcard certificate here for *.example.com. But now I have en error ERR_CERT_COMMON_NAME_INVALID.

At the same time c.example.com works well.

Can I somehow issue certificate for more then one nested subdomain?

  • 2
    Wild card certificates only work at 1 level of depth. AFAIK, there is simply no way to have a valid cert that would work with multiple dynamic components. – Zoredache Apr 2 '18 at 19:31
  • 1
    If you control the clients and can have a private CA you could (not easily, but you could technically) generate the certificates dynamically upon HTTPS requests. See for example the generate-certificates option in HAProxy configuration. – Patrick Mevzek Apr 2 '18 at 23:07
  • @PatrickMevzek That only works if the clients are using non-standard certificate verification software. If they're following the relevant standards, they will consider those certificates as having non-matching hostnames. – Jenny D Apr 3 '18 at 15:05
  • @JennyD: no, if you control the clients, you can put your specific CA certificate in there, and then on your website you generate the relevant website certificate (for the exact specific host name queried about) signed by this CA you control, at the time the HTTPS query comes. The TLS/X.509 verification will be successful and exactly the same as if the certificate existed beforehand. See the example I gave. – Patrick Mevzek Apr 3 '18 at 15:27
  • @PatrickMevzek Well, it's true that it's a SHOULD NOT, not a MUST NOT, but according to RFC6125 a wildcard character that is not in the leftmost DNS label should not be considered a match. So even if they trust the CA, they still shouldn't consider the match to be successful if they follow the relevant standards. (I'm a bit of a PKI junkie...) – Jenny D Apr 3 '18 at 19:37

As @Zoredache pointed out, wildcards only go the appropriate depth for which they are created. If you have a wildcard for *.example.com, then only the domains within that [*].example.com domain are valid. If you need two-levels, you would have to create a multi-layer certificate encompassing those domains, such as *.a.example.com. I can't say I've ever heard of a multi-layer wild-card certificate, so you would likely need to create multiple wild-cards per sub-domain.

You can create a single certificate that can accomplish this through the use of Subject Alternative Names (SAN). Just take a look at the stackoverlow.com certificate and it's wild & crazy deployment ;)

| improve this answer | |
  • yes, looks like SAN is my best alternative – light_keeper Apr 3 '18 at 8:18

No, you cannot do that. According to RFC 2828, SSL certificate wildcards can be used to match a single domain name component, not multiple components. This has been amended and further clarified in RFC 6125, which states in section 5.2 that:

   o  The ’*’ (ASCII 42) wildcard character is allowed in the dNSName of
      the subjectAltName extension (and in common name, if used to store
      the host name), but only as the left-most (least significant) DNS
      label in that value.  This wildcard matches any left-most DNS
      label in the server name.  That is, the subject *.example.com
      matches the server names a.example.com and b.example.com, but does
      not match example.com or a.b.example.com.  Implementations MUST
      support wildcards in certificates as specified above, but MAY
      provide a configuration option to disable them.

In other words, multiple wildcards are not allowed, and any wildcard must be in the leftmost component of the DNS name. This is repeated in section 6.4.3, specifying how clients should behave when they encounter certificates with wildcards in them - any wildcards other than in the leftmost component of the domain name should result in the certificate not matching the domain name you're using it for. Specifically, the first point in 6.4.3 is:

   1.  The client SHOULD NOT attempt to match a presented identifier in
       which the wildcard character comprises a label other than the
       left-most label (e.g., do not match bar.*.example.net).

So, even if you could make Letsencrypt make those certificates, the visitors to your website still would not accept them.

| improve this answer | |
  • I fixed your link to RFC6125, as you were pointing to RFC5125 instead, which is irrelevant. – Patrick Mevzek Apr 3 '18 at 19:56

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.