An SSL cert that is valid for any and all domains and all levels of subdomains
github.com
github.com
This is still very cheeky, though!
One common example is antivirus software that block malicious content. It can install this wild-wildcard certificate, and act as a proxy to all sites the user visits. There are obvious security issues to it of course.
> Issuer: C = US, ST = GA, L = Atlanta, OU = Junk
Ooh, I bet WoSign would do it!
To use this, you have to install node, and use that to run generate.js[1]... and what does generate.js do?
1. It generates an openssl.conf-file, which could have been checked into the repo as static content.
2. It runs a bash-script[2] which calls the openssl CLI-tool, with this config-file as a parameter.
I get it that we are programmers, but how many layers of indirection are we going to add to what could have been a simple README, and pre-supplied config-file?
Less is more. Not everything needs to be NodeJS.
[1] https://github.com/flotwig/the-one-cert/blob/master/generate...
[2] https://github.com/flotwig/the-one-cert/blob/master/run-open...
I mean, after 20 years of UNIX, I don't even have a clue why expressions fail in bash sometimes ¯\_(ツ)_/¯
Bash is esoteric, obscure and awful.
*.*.example.com
foo.*.example.com
Not sure what the current state of software accepting these things is, but minimally, CAs are not allowed to issue anything like that.
security/nss/lib/mozpkix/lib/pkixnames.cpp
Likewise for Chromium:
trunk/src/net/base/x509_certificate.cc
(I've intentionally not linked these because burdening the relatively heavyweight source viewers with idle HN readers who are mostly going to glaze over and not read once they discover it's tricky C++ code seems unfair)
My guess would be that because it's harder to process multiple wildcards at all, and indeed even the sketchy single wildcard in odd position (which Symantec used to issue and argued wasn't technically prohibited e.g. dev-*.auditcompany.example where auditcompany.example was a domain belonging to Symantec's auditors...) it's less likely anybody goes to the effort to do this even though it's a bad idea.
But I guess if the wrong programmer is assigned the problem they might cheerfully write a nice loop to process wildcards even though it's more effort and the wrong thing so we can't rule out that it has happened somewhere at least once.
Seems like a good use case for linking to their respective GitHub mirrors
https://github.com/chromium/chromium/blob/master/net/cert/x5...
https://github.com/mozilla/gecko-dev/blob/master/security/ns...
I'd say that statement seems a bit unfair and glad someone else linked to a source below.
Here is a report on dotless domains you may find interesting.
...snip...
commonName = *
...
[alt_names]
DNS.1 = *.*
DNS.2 = *.*.*
...More fun than generating this cert would be doing an analysis of who will accept it, who will reject it and who will accept up to a point. (Obviously I dontbexpect anyone to issue it, if you handed in a CSR for it.)
The Baseline Requirements require that Public CAs ensure CN if present (which for compatibility it usually will be) is set to the same name as one of the SANs. Historically breaches were not uncommon, but as noted above now these certificates won't work as intended in Chrome so that's another practical reason above getting a slap on the wrist from m.d.s.policy.
My point being the Common Name missing from the Subject Alt Names is the least of the problems with this certificate.
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).1. is about wildcards in the domain part while having a hostname and 2. is in effect, which is why there are so many alternative subject names.
they just added 127 subject alternative names to adhere to these rules.
I haven't seen the latter either.
*.*.example.com
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)
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.
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.
DNS:*.*,
There's a mechanism called certificate chains that allows browsers to validate that the certificte actually has the authority it claims to have - obviously, this certificate would not pass that validation.
Some sites have a multitude of domains and they don’t want to have a different certificate for each. Fortunately, there is a way to specify wildcard expressions in a certificate. For example, many SaaS tools where your account name is part of the domain (e.g., my company’s PagerDuty account is at opsevel.pagerduty.com). A certificate that could be provisioned would be for .pagerduty.com and that would work for all of their subdomains (one per customer).
This site invented a cute trick where they used wildcards to essentially match any* domain or arbitrarily deep level of subdomains. It literally is a certificate that could be used by any domain because its wildcards match everything. Of course, it provides no security because it’s vacuously passing.
AFAICT, the wildcard symbol (asterisk) will not match across the separator (i.e. the period).
So ¤.¤ will only match example.com or contoso.com etc, not blog.example.com or sales.contoso.com.
If you look at the cert, it has lots of line that looks like this:
DNS:¤.¤.¤.¤.¤.¤.¤.¤.¤.¤,
DNS:¤.¤.¤.¤.¤.¤.¤.¤.¤.¤.¤,
(Asterisk substituted for ¤ in order to not trip up the formatting here on HN.)
You have to have a separate alt name specified for every possible number of subdomains.
* does *not* match *.*, or *.*.*, etcYou can't wildcard at the root or TLD, and you can't have two wildcard labels in a DNS name.
The go-to solution for this is to load a certificate authority into the proxy itself and have it generate certificates on the fly.
I think the wildcard rules are more to protect people in case of a certificate authority breach than to protect against MitM. Imagine if DigiNotar would sign a certificate in the form of ⁎.⁎.⁎ instead of just some Google domains and browser would actually accept that!
The browser restrictions were in place before SNI was really widespread, and you needed funky certificates like the one in the original link because you had no way to predict if someone was trying to access google.com or facebook.com and you risked generating a browser warning if you offered up the wrong one.