10

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?

0

1 Answer 1

10

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
 [...]
6
  • "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 :) May 15 at 17:58
  • 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. May 15 at 19:05
  • @TobiasMädel ah yes I agree with this.
    – A.B
    May 15 at 19:06
  • Is there documented rationale for why this is a “should not” as opposed to a “must not”?
    – Tim
    May 16 at 6:57
  • 1
    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 letsencrypt.org/documents/isrg-cp-v3.3
    – U. Windl
    May 16 at 9:19

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