It is a shame that you cannot have a cert signed by multiple CAs.
(The format seems like it would allow it, but nothing supports it, and in practice CAs demand the ability to actually modify some fields, and then sign that.)
It 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...
Yeah, that's one of the complications. It would have to be ignored in processing, or multiple variants be presented at once (preferred).
Certificates are not the same as the public key; multiple certs sharing the same key is essentially the way around this. It's not as elegant as identical signing of the same cert, but it could work.
It's mostly historical. They used to suck in the past, but the implementations remain. Nowadays you are better off configuring to use OS certificates if possible.
Clearly the platform isn't designed to do this. Nobody thought this was going to be a necessary facility. They have just crammed an array of numbers as literal values deep into the standard library. So clearly this is an exceptional event, and not the exercise of a feature that was foreseen.
A bit more info (and some discussion linked from these Bugzilla reports):
https://bugzilla.mozilla.org/show_bug.cgi?id=2083709
https://bugzilla.mozilla.org/show_bug.cgi?id=2018979
"Sir, this is a Wendy's" moment where my compiler thought it was a root certificate authority
It is a shame that you cannot have a cert signed by multiple CAs.
(The format seems like it would allow it, but nothing supports it, and in practice CAs demand the ability to actually modify some fields, and then sign that.)
It 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...
That's an interesting wrinkle I was not aware of.
X.509v3 just has one issuer Name in the certificate, unless you're talking about something else?
Yeah, that's one of the complications. It would have to be ignored in processing, or multiple variants be presented at once (preferred).
Certificates are not the same as the public key; multiple certs sharing the same key is essentially the way around this. It's not as elegant as identical signing of the same cert, but it could work.
This seems to be the list of certs https://gist.github.com/mendymm/ff7a9fd00339260b4d2dbdcb0f48...
data from https://www.ccadb.org/resources
It's interesting that this sort of policy is baked into a language platform.
Indeed. But the Java keystore and the Firefox/Chrome/VSCode NSSDB and whatever Python is shipping this week aren't really better.
I wonder what's so annoying about OS certs.
It's mostly historical. They used to suck in the past, but the implementations remain. Nowadays you are better off configuring to use OS certificates if possible.
What about it makes it so interesting?
Clearly the platform isn't designed to do this. Nobody thought this was going to be a necessary facility. They have just crammed an array of numbers as literal values deep into the standard library. So clearly this is an exceptional event, and not the exercise of a feature that was foreseen.
Ah, yes that seems to be what URGENT track self-documents as.