Score:10

Do SSL Certs containing two wildcards work (esp. on Let's Encrypt)?

vn flag

I want to include two wildcards in an SSL cert (will be) signed by Let's Encrypt: *.*.thost3.de. Will this cert match any hostnames matching that rule (e.g. example.example.thost3.de, hello.world.thost3.de), and can Let's Encrypt accept such wildcards exist in certs they signed?

Score:10
cl flag
A.B

No this SHOULD NOT (in the RFC meaning of "SHOULD NOT") work, as documented in RFC 6125 (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)):

If a client matches the reference identifier against a presented
identifier whose DNS domain name portion contains the wildcard
character '*', the following rules apply:

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

  2. If the wildcard character is the only character of the left-most label in the presented identifier, the client SHOULD NOT compare against anything but the left-most label of the reference identifier (e.g., *.example.com would match foo.example.com but not bar.foo.example.com or example.com).

[...]

Putting these two together:

  • you can't have a wildcard elsewhere than the leftmost part (separated by a dot) of the certificate: an inner wildcard is invalid.
  • you can't have a wildcard certificate match additional label part (ie: separated by a dot) on its left: again that means that if a valid single wildcard were used, nothing with an additional left part can match (so hello.world.thost3.de can't match the certificate *.thost3.de).

What you can do is issue a certificate with a lot of SAN parts possibly themselves with a (valid) wildcard. But I'm not sure at all that you can get this accepted by Let's Encrypt.

EDIT: *.stackexchange.com is signed by Let's Encrypt with multiple SANs having a wildcard.

Example:

$ openssl s_client -connect stackexchange.com:443 </dev/null 2>/dev/null| openssl x509 -noout -text | grep -A1 'X509v3 Subject Alternative Name' | tr ',' '\n'
            X509v3 Subject Alternative Name: 
                DNS:*.askubuntu.com
 DNS:*.blogoverflow.com
 DNS:*.mathoverflow.net
 DNS:*.meta.stackexchange.com
 DNS:*.meta.stackoverflow.com
 DNS:*.serverfault.com
 DNS:*.sstatic.net
 DNS:*.stackexchange.com
 DNS:*.stackoverflow.com
 DNS:*.stackoverflow.email
 DNS:*.superuser.com
 DNS:askubuntu.com
 [...]
cn flag
"is issue a certificate with a lot of SAN parts", yes, you could issue that (in a self-signed cert for example), but no browser (at least as far as I know) accepts that. So these are utterly useless :)
cn flag
No, what I meant was: dual (or more) wildcard certificates, so *.*.serverfault.com would not be accepted by browsers, even if you managed to sign such a certificate.
A.B avatar
cl flag
A.B
@TobiasMädel ah yes I agree with this.
ro flag
Tim
Is there documented rationale for why this is a “should not” as opposed to a “must not”?
sa flag
And why this is a "should not" as opposed to a "must"?
U. Windl avatar
it flag
The point is whether an RA (Registration Authority) would actually accept such CSR (Certificate Signing Requests) when the subject is not allowed. It's a rather useless discussion what such a certificate would do unless you actually get one. See the definition of **Wildcard Domain Name** in https://letsencrypt.org/documents/isrg-cp-v3.3/
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.