Sort of. Here is a way to do it, but I don't a practical use for this hack right now. But it is fun anyway :)
Here we go!
I was thinking about ways to distribute trust, and played a bit with CA generation and OpenSSL, when it occured to me: it depends more on a key pair than on a certificate! If I consider that I trust a key instead of a certificate, I begin to see a way (certificates are only restrictions on the trust between keys).
It is really easy to get multiple certification authorities to sign a certificate for the same key (even for the same subject name in some cases). You send the certificate signing request to two certificate authorities, and you get two certificates, for the same keys and same subject names. But the issuer, dates, serial and signature are different. That's why a certificate has only one certification chain.
But what will happen if I delegates the certification to another key? Here is the idea:
- create a first key pair
- create a CSR for this key pair, and add the certification authority extension
- ask the certification authorities to sign this CSR
- you now have multiple certificates, for one key pair, all of them with the same subject name, and with certification authority powers
- create a second key pair
- create a CSR for this key pair, with a subject name for your email/domain name/organisation/whatever
- sign this CSR with the first key pair, and any of the CA certificates you obtained before
You are now the proud owner of a valid certificate for your domain name, with multiple certification chains going up to each of the root CAs. Why? The issuer's subject name and public key is the same for all of the generated CAs, and they're included in the end certificate. Any generated CA certificate can be used to verify that signature, and all the certification paths will work. Cool, huh?
Okay, but...
- Creating a sub CA is very expensive (if you want it to be recognized by all the browsers)
- good luck with creating multiple sub CA and getting away with it
- Assuming that certification authorities accept it, the sub CA private key could be thrown away after signing the certificate. But who will create and delete the subCA key? you, one of the CAs?
- In the case of TLS, serving all the certification chains will have no impact: the browsers take the first matching sub CA in the list for the verification, they will not retry with another sub CA if they don't find a root (but if you serve one certification chain at a time, it will work).
See, I said "no practical use" :)