[oefrha]

That's typically a limitation imposed by CAs (e.g. Let's Encrypt), not a limitation in the spec. RFC 6125 even contains an example of a multilevel wildcard domain (but says support in existing implementations is unclear):

  Specifications for existing application technologies are not clear
  or consistent about the allowable location of the wildcard
  character, such as whether it can be:

  ...

  *  included as all or part of more than one label (e.g.,
     *.*.example.com)

https://tools.ietf.org/html/rfc6125#section-7.2

Edit: Actually, according to https://community.letsencrypt.org/t/allow-multiple-level-wil..., browsers are behind the "only one level of wildcard" rule, too:

> We would also have to contend with the CA Browser Forum’s Baseline requirements. Presently they define a “wildcard domain” as:

> “A Domain Name consisting of a single asterisk character followed by a single full stop character (“*.”) followed by a Fully-Qualified Domain Name.”,

> Allowing multiple wildcard labels would likely run afoul of the baseline requirements.

[a10c]

Is there a particular reason why CAs don't allow this? Security or otherwise?

[tialaramex]

Do you mean practically, or philosophically, and do you mean just the Public CAs or the trust stores that set policy?

Practically these certificates would simply not work in popular web browsers. So if you sold them you're going to get lots of complaints because stuff doesn't work.

It's already very complicated (because of name constraint rules and conflicting policy requirements over 20+ years) to do name matching, so there's no incentive in the browsers to make it even more complicated so as to enable CAs to sell yet another product of dubious value.

As a general rule you should try to have less stuff covered by one certificate, the same way a large estate would try not to use the same key on every lock but instead have a diversity of keys, possibly with a "master key" arrangement. So from that point of view it's hard to justify multiple wildcards - ⭑.⭑.example.com suggests there might be... dozens? hundreds? thousands? of services with perhaps unrelated content all "secured" using the same keys and that clearly isn't a good idea.

Edited to add:

It occurs to me that you might not know the "CA/B Forum" is not just Certificate Authorities deciding their own rules.

CAB is a standing meeting between (some) CAs and the Browser vendors who in practice are almost exactly the OS vendors (Microsoft, Apple, Google, Mozilla, with Mozilla effectively standing in for the Free Unixes). The purpose of CAB is that Browser vendors get to set their own policy for their browser, but to the extent everybody agrees together on a common policy it's simpler than having lots of different and perhaps conflicting policies, this is done in the form of the Baseline Requirements, a document you can find here:

https://cabforum.org/baseline-requirements-documents/

Unlike OPEC the bodies at CA/B are not sovereign entities and so there are competition rules, they must not be or give the appearance of being a cartel. As a result CA/B never talks about prices, nor about which products you might actually sell to customers, but it does talk about policy decisions which can indirectly impact those products.

Because there are a lot of public CAs and few browser vendors the body is deliberately not using simple majority rules, like successful governments in places that have historically had violent conflict on ethnic lines. Instead a change to the BRs must have support of both CAs and browsers to pass.