
An SSL cert that is valid for any and all domains and all levels of subdomains - kick
https://github.com/flotwig/the-one-cert
======
virgilp
This gives a whole new meaning to the concept of "public key encryption".

------
liammonahan
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?

This is still very cheeky, though!

~~~
Ayesh
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.

~~~
guenthert
You mean like HTTP(S) proxies and deep-inspection firewalls?

~~~
Ayesh
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.

------
AnonC
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:

 _> Issuer: C = US, ST = GA, L = Atlanta, OU = Junk_

~~~
lucb1e
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.

------
jupp0r
Perfect. Let's get it signed by Digicert!

~~~
an_account_name
I mean out of the Symantec roots...

Ooh, I bet WoSign would do it!

~~~
Nextgrid
I bet Honest Achmed will sign it in exchange of a couple used cars:
[https://bugzilla.mozilla.org/show_bug.cgi?id=647959](https://bugzilla.mozilla.org/show_bug.cgi?id=647959)

~~~
craftinator
Hah I haven't stumbled across this in years! Thanks for sharing!

------
josteink
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?

Less is more. Not everything needs to be NodeJS.

[1] [https://github.com/flotwig/the-one-
cert/blob/master/generate...](https://github.com/flotwig/the-one-
cert/blob/master/generate.js)

[2] [https://github.com/flotwig/the-one-cert/blob/master/run-
open...](https://github.com/flotwig/the-one-cert/blob/master/run-openssl.sh)

~~~
cookiengineer
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 ¯\\_(ツ)_/¯

~~~
dcminter
You probably already know this tool, but it was new to me relatively recently:

[https://www.shellcheck.net/](https://www.shellcheck.net/)

~~~
cookiengineer
Yep, shellcheck helps a lot while debugging shell scripts and quirks. (ALE has
support for it, too, in case you use VIM)

------
reanimus
I'm curious how many SSL implementations will accept it (assuming you signed
it with a trusted root/self-signed certs are allowed)

~~~
mike_d
None. Wildcards are not allowed at the first or second level.

[https://en.wikipedia.org/wiki/Wildcard_certificate#Examples](https://en.wikipedia.org/wiki/Wildcard_certificate#Examples)

~~~
rndgermandude
The question wasn't whether if it is allowed, but how many implementations
will actually accept it ;)

~~~
tialaramex
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.

~~~
edf13
> (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.

~~~
cortesoft
It is also hilariously elitist

------
devy
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.

[1]:
[https://github.com/FiloSottile/mkcert](https://github.com/FiloSottile/mkcert)

~~~
dtech
Since this cert is valid for basically everything, you can trust and use that
one cert and don't need a CA plus generated certs like mkcert does.

------
eru
I wonder why they left out the single "DNS:*". Is that not valid?

~~~
imrehg
They didn't, that entry is in the top level commonName (CN in the openssl
output), or looking stright in openssl.cnf:

    
    
        ...snip...
        commonName = *
    
        ...
    
        [alt_names]
        DNS.1 = *.*
        DNS.2 = *.*.*
        ...

~~~
praseodym
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).

~~~
igetspam
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.)

~~~
tialaramex
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.

------
eddieoz
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.

------
coenhyde
This is not a valid certificate. See
[https://tools.ietf.org/html/rfc6125#section-6.4.3](https://tools.ietf.org/html/rfc6125#section-6.4.3)

    
    
      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).

~~~
thedanbob
Those are both “should not”, not “must not”. So technically this isn’t
breaking the rules, though it’s obviously incredibly not recommended.

~~~
coenhyde
yeah but i think you'll have a hard time finding a client library which will
consider the certificate valid. If it does i would consider it broken.

------
jonnybarnes
I thought you couldn’t put wildcards in multiple levels of the domain?

~~~
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](https://tools.ietf.org/html/rfc6125#section-7.2)

Edit: Actually, according to [https://community.letsencrypt.org/t/allow-
multiple-level-wil...](https://community.letsencrypt.org/t/allow-multiple-
level-wildcard-certificates/67242), 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/](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.

------
emilfihlman

      DNS:*.*,
    

Is this missing ai and other top level domains?

~~~
lucb1e
Someone posted that question 4 hours before you did and it was answered 3
hours ago.

~~~
emilfihlman
Ah I see, thanks!

------
lmilcin
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.

------
ganouti
Can someone do please do an ELI5? I know what a certificate is, but not more
than that so I don't really understand what's happening here. Thanks!

~~~
kenrose
Certificates are used to prove the identity of a given domain. e.g., if you
visit [https://news.ycombinator.com](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.

------
dmtroyer
someone please fork letsencrypt to provide this cert.

------
matthewtovbin
This seems like a very bad idea, though definitely less hassle to manage than
a regular set of certificates.

------
kalium-xyz
So *.?

~~~
x3n0ph3n3
Did you bother reading? _. doesn 't work with subdomains. You need more _'s
and .'s

~~~
pedrocx486
Doesn't the title here literally say that it works with subdomains? Or I'm
misunderstanding? (Not my field of work.)

~~~
cpach
Yes it does, due to the way that it’s structured.

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:¤.¤.¤.¤.¤.¤.¤.¤.¤.¤.¤,
    

In that way it will match all possible levels of subdomains.

(Asterisk substituted for ¤ in order to not trip up the formatting here on
HN.)

------
gigatexal
This is hilarious

------
skyzyx
This is grossly irresponsible.

~~~
nexuist
It's a joke, no? Nobody in their right mind would actually use this in
production (of course, now that I've said that, they will, but I digress).

~~~
el_dev_hell
It's 100% a joke and will 100% end up being used in production eventually.

~~~
pilif
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

~~~
squiggleblaz
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.

