If you buy a domain, you may think you then have full control over its sub-domains. Well, not necessarily true. As this question and its answers point out, you may need multiple SSL certificates to cover multi-level sub-domains because wildcard matching only works with a single level of sub-domain (ref).

For example, *.example.com will match foo.example.com but not bar.foo.example.com.

I simply cannot figure out the security concerns therein. My best guess is that it may reduce the number of victims when the certificate is compromised. Are there any other valid security benefits from the wildcard matching restriction?

EDIT: Not a dup. The answers to that question are hardly satisfying from a security point of view. They are either too simple or focusing on something else.

  • Also worth noting: you do have full control over a domain you purchase. What you not have full control over is the certificates you buy.
    – Tobi Nary
    Nov 26, 2017 at 17:53
  • The question matches, but the answers are basically "because writing software is hard and people will get it wrong", which is hardly satisfying :/ Nov 26, 2017 at 17:54
  • @SteffenUllrich Read that answer. It said: the core business of a professional CA is to sell many certificates, and wildcard certificates don't help for that.
    – Cyker
    Nov 26, 2017 at 17:57
  • @Cyker: this is a very narrow and IMHO wrong interpretation of the extensive answer. What you treat as essence of the answer I would consider only a small remark. Nov 26, 2017 at 18:00
  • @MikeOunsworth: I think the answer is not satisfying since there is no satisfying answer to the question of why multi-level wildcards are not allowed :) Nov 26, 2017 at 18:01

2 Answers 2


A certificate should be issued for the entity which manages the specific domain. There are environments where different sub-domains are managed by different entities. This is for example often the case within universities where different departments have their own sub-domain and have their own systems within this sub-domain. These systems are usually managed by the department itself and not centrally by the university.

If *.example.com would match every sub-domain and subsub-domain it would not be possible to limit the wildcard certificate to only match the hosts managed by the specific entity.

Apart from that domains were used differently at the time when these standards were made. The domain name system was actually designed to be used more hierarchical then it is used today. The idea was to use the domain name as the main entry point for an organisation, have sub-domains for organisational parts of the organisations like departments and have hostnames within the sub-domains and main domain to identify systems. Using just the main domain name as in example.com instead of www.example.com is a "relatively" new thing and also multi-level sub-domains without having any organisational structure behind it. In this "old" world a design of having the wildcard matching only a single part made more sense than it seems to make today where it is often more important that a domain name looks fancy than that it reflects an actual organisational structure.

  • Wikipedia has [language].wikiepdia.com, and my alma mater has math.uchicago.edu for the math department (and individual professors have math.uchicago.edu/~drh). Is this in line with how people were expecting to use it? Nov 26, 2017 at 20:49
  • @StellaBiderman: [language].wikipedia.com fits the traditional scheme. Regarding math.uchicago... - if there is also ftp.math... , mail.math... etc then it is not the traditional use since a name was considered either an organisational structure or an actual system but not both. Nov 27, 2017 at 6:06

My understanding is that a lot of sites that offered hosting services got in trouble with this.

Example: imagine a site cheaphosting.com offers you to register domains under sites.cheaphosting.com. So I go set up a website at mike.sites.cheaphosting.com. Maybe I'm handling credit card transactions, so I get myself a TLS certificate for my site.

Now, if CheapHosting, inc has a wildcard cert for *.cheaphosting.com and the subdomain limitation wasn't there, then they would be able to use this cert to man-in-the-middle my site so that anyone connecting to mike.sites.cheaphosting.com will still get the green lock in their browser, even though the connection is being evesdropped by the higher-level wildcard cert.

Similarly, if a bad guy ever got hold of a wildcard certificate for *.com with no subdomain limit, then they could man-in-the-middle 3/4 of the internet! So let's just ban that outright.

  • 1
    "if a bad guy ever got hold of a wildcard certificate for *.com" - no CA should issue such a certificate. And at least Chrome and FF check the public suffix and would not accept this certificate. I don't know about IE/Edge. Nov 26, 2017 at 18:04
  • @SteffenUllrich Oh I agree that no CA should issue it. Does that mean it's impossible? I like that you're going around commenting on all the answers, rather than posting any yourself. I'll be happy to upvote a better answer. Nov 26, 2017 at 18:24
  • A CA has to publish all signed certificates to a certificate log, so if someone creates a wildcard certificate for *.co.uk, people will discover that and the CA would loose all it's trust. And trust is the only thing that keeps them in the trusted CA repository. Nov 27, 2017 at 4:41
  • 1
    @JohannesKuhn I like your comment that "trust is the only thing that keeps them in the trusted CA repository". Actually I'm also interested in how that trust is managed nowadays. It's hard to believe we trust a website simply because somebody we never know has trusted it. It's a little bit out of topic for this question, though.
    – Cyker
    Nov 28, 2017 at 3:05
  • 1
    @Cyker Yeah. The whole stack of turtles for TLS rests on Certificate Authorities being honest when they say they background checked a website before issuing them a cert, on an browsers and Certificate Transparency logs monitoring them to make sure they stay honest. (since I work for a CA, I can tell you the auditing requirements to stay in Firefox and Chrome are very strict) Nov 28, 2017 at 3:08

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