alt Hacker NewsIt is done with intermediate certs, though! It's a common method of establishing trust in new root certs: sign the intermediate with an already-trusted root cert, then wait for the community to adopt the new root cert over the years.
For example, the initial Let's Encrypt Authority X3 was signed by both their own (new, not-yet-universally-trusted) ISRG Root X1, and the universally-trusted third-party IdenTrust DST Root CA X3.
One crucial detail is that it isn't the same certificate. Rather, it is two separate certificates which just so happen to be using the same key pair, so the leaf cert is in essence signed by both intermediate certs at once.
I wonder if it would be possible to do the same thing on your own, actually: can a server present two completely separate cert chains to a connecting client - as long as the leaves use the same key pair? Technically AFAIK the only requirements should be 1) the key pair in use for the connection matches the cert, 2) the domain matches the cert's Subject, and 3) the cert is trusted, so at first glance it might be possible...
Replies
AFAIK, that's what google does: it sends a second post-quantum chain in addition to ecc chain.
That's an interesting wrinkle I was not aware of.
If the client uses "certificate_authorities" extension to list support CA's, a TLD server that holds multiple x509 certificates can present to the client the certificate signed by the clients trusted CA.
Of course, the browsers don't use the "certificate_authorities" because the list would be hilariously large for a TLS CLient Hello packet.