SSL certificate for all domains

Question

is it possible to generate with openssl certificate for all domains? I dont need to sign it with CA, no CA will ever do this if it is possible. I just need it for specific reason. Or is there any way to do this?

Answer 1

is it possible to generate with openssl certificate for all domains?

It depends, but mostly, yes. I call it a "Super Cert".

I can only say "mostly" because browsers will reject the technique below. Other user agents, frameworks, libraries and even operating systems will accept it.

---

The short of it is you add the following to your openssl.cnf file:

[ x509_ext ]
...
subjectAltName          = @alternate_names
...

[ alternate_names ]

DNS.1       = *.com
DNS.2       = www.*.com
DNS.3       = *.net
DNS.4       = www.*.net
DNS.5       = *.gov
DNS.6       = www.*.gov
DNS.7       = *.mil
DNS.8       = www.*.mil
...

Then, you serve the same certificate for every request.

---

The reason it works is... There are two groups that publish the rules that the majority of user agents follow. The first is the CA/Browser Forum Baseline Requirements. The second is the IETF with RFC 5280 and RFC 6125. The browsers follow the CA/Browser Forum BR. Other user agents, like cURL and Wget, and frameworks like Java, Cocoa and .Net, follow the RFCs.

Both the CA/B and IETF have rules for matching the wildcard, and it means you have to work at creating the Super Cert. You can't simply use *.com and *.*.com for all cases.

Depending on the matching rules, sometimes multiple wildcards are allowed, sometimes the wildcard must be in the left-most label, and sometimes the wildcard cannot be in the domain label.

---

Now, the browsers will refuse to match a name like *.com in a certificate. Its codified in the Baseline Requirements, and the Global Top level Domains (gTLDs) are listed in the Public Suffix List (PSL) used by browsers.

Other users agents will happily match it even though it makes no sense. Here are the user agents, libraries and frameworks which can't seem to get the matching right. Here, "right" means provide a mediocre level of security. These user agents should know the channel is under attack when they encounter a certificate that claims to be issued for the entire gTLD:

• Python
• Ruby
• Java
• .Net
• Cocoa

I seem to recall PERL was the only one that got it partially right by rejecting *.com and friends. However, it accepted www.*.com, if I recall correctly.

Other user agents that failed to reject the nonsensical hostnames include:

• wget
• curl
• gnutls
• ...

When I filed the bug reports, the most cited answer for accepting it was "... but the RFC does not prohibit it".

I've tried to get both the PKIX working group (Internet's PKI) and the DBOUND working group (domain boundaries) to reject them (or at least advise against accepting them) since we know there's no single organization that issues certificates for all of .COM, all of .NET, etc. Also see Some work that will probably hit dbound sooner rather than later.

---

James Polk said this:

a CA will only sign it if they can verify that you control those domains. Unless of course you can fool the CA.

That's mostly true. If you are running you own PKI, then you create the Super Cert, sign it with your internal CA, and everything will work as expected like a Public CA signed it.

This assumes you installed the internal CA certificate as appropriate, but that's what you do when you run your own CA.