This is cute. Does this have any practical value? You would never get someone to sign it obviously, and for self-signed certs you have no revokability here without reissuing a cert to everything in your domain. Most people with a PKI setup don't need this, right?
I suppose you can use such certificate to MITM yourself to inspect the traffic to/from nodes you control, but pretty much every tool out there has features to generate certificates on the fly.
Any software or hardware that needs to intercept HTTPS.
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.
Obviously, this is for internal environments under one’s control. I found this bit amusing and wondered if the author had some kind of meta message here:
This should be on top since the title can be confusing. I thought someone found a vulnerability but it's indeed just a script to generate a certificate without having to care which common name or alternative names you give it.
I realize this is not an overly serious project, but still..
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?
May be I don't understand something, but this repository does have static openssl.conf and even generated key/certificate, so you absolutely don't have to install node. You need to install node, if you want to regenerate it with different parameters or something like that.
I’ve written a fair share of bash scripts over the years and because of that I prefer any other high level scripting language to do shell scripting. I use node a lot like this project but python or ruby are also good penknives for these kinds of tasks.
Maybe for inexperienced developers the whole point of this approach is that bash loops and string manipulations are inguessable (and by any means not similar to any real programming language)?
I mean, after 20 years of UNIX, I don't even have a clue why expressions fail in bash sometimes ¯\_(ツ)_/¯
Popular browsers don't accept these prohibited names, e.g. here's the relevant code for Mozilla's NSS:
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.
> (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)
I'd say that statement seems a bit unfair and glad someone else linked to a source below.
> 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
Seems like a good use case for linking to their respective GitHub mirrors
Although I will say that the code-browsing experience on https://source.chromium.org beats GitHub by a mile; you can hover over anything, the search tools are better, and it makes it easier to actually understand the code you're reading.
The two remaining browser engines are of course very important here, but there is a large number of other libraries and software that uses those libraries (in different configurations, and all with their particular bugs) as well. E.g. openssl didn't have a good name validation API (or any such API at all) for a long time, and a few years back I saw a ton of software which rolled their own stuff. I'd guess a lot of that code is still in production.
So are we pretty certain or very certain that at least one implementation (probably in an IoT device) will no bother with this validity check and accept it anyway?
So this is a self-signed TLS certificate. Perhaps pair the CSR with mkcert[1], it will be even more useful (without seeing the warning messages in browsers.) to be used locally.
SubjectAltNames should always include the common name, modern browsers won’t even look at the common name value any more (because it’s validation algorithm is not well defined, whereas it is for subjectAltNames).
Should be not must. The RFC doesn't required it. SSL implementations are complicated. Browsers might accept this up until hmthe Nth SAN, at which point they stop reading because they have arbitrary SAN limits (not in the spec). Some issuers care about CN/Alt match and some don't
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.)
From a purely pragmatic point of view, in the Web PKI CN is ignored by Chrome for some time now and I think Firefox did that too. There were, and might still be, exceptions for certificates you trust which aren't from the Web PKI. You break it, you bought 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.
Having possibilities as a technology perspective is always a good thing. But without a good use case, it seems to be worthless. CA's will review it from a business perspective and if the market doesn't need it, they will not implement.
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).
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)
> 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.
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:
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.
Probably would be more useful with less subdomain levels. This will inevitably trigger problems with some tools and you do not typically need anything more than 3-4.
Certificates are used to prove the identity of a given domain. e.g., if you visit https://news.ycombinator.com (https), when your browser connects, the server offers a certificate that basically says “this is the certificate for news.ycombinator.com”. Your browser verified that the domain on the certificate is the same as the domain you’re visiting. If they’re different (or if there’s is something else wrong with the certificate like it expired), you are shown a warning that says “It may not be safe”.
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.
Certificates list what website they are a certificate for. Wildcards are allowed in some cases.
This certificate claims it certifies every website.
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.
For this to be useful in production, it would need to be signed by a proper CA. No CA will sign this. And if they accidentally did, it would be revoked immediately in order to not end up like Diginotar and Symantec
Diginotar and Symantec ended up like Diginotar and Symantec. Even Let's Encrypt backed down. There seems to be strong pressure on CAs to not do the secure thing when they've made a mistake.
MITM proxies ran by organizations (governments) that also own certificate authorities is exactly why certificates like this are rejected by browsers on syntax alone.
You can't wildcard at the root or TLD, and you can't have two wildcard labels in a DNS name.
Browsers not only accept MitM certificates, they have special exceptions for them. If you import a CA certificate, Chrome and Firefox will ignore certain features (such as certificate transparency requirements) even for domains and IPs that resolve to the routable internet.
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!
Yes, the _correct_ way to do it is with a CA certificate. But since CA certificates do not have a CommonName or SAN, you have to have clients that support SNI so you know what host the client is requesting so you can quickly generate and sign a one-off certificate.
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.
