Comment by wnoise
3 days ago
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...
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.
That's an interesting wrinkle I was not aware of.
AFAIK, that's what google does: it sends a second post-quantum chain in addition to ecc chain.
https://en.wikipedia.org/wiki/Convergence_(SSL)
shame it wasn't adopted. rent seeking CAs would never go for it.
Actually it sounds too complicated for users. It's basically doing web of trust.
Web of trust required a lot of work by users and was pretty bad in practice. This isn't that.
This would effectively be the same "root CAs come pre-installed" but they would be notaries rather than root CAs, with a predefined trust policy (maybe minimum of 2 notaries per leaf certificate)
Users would still just see a green lock icon same as before, no action needed.
Would it really be worth the extra complexity?
Another option: Use ACME together with ARI (RFC 9773). The client checks ARI data every hour. If the cert needs to be replaced – for example like in this scenario – the CA will inform the client, which in turn would then request a new cert.
I know it’s not convenient to automate for every kind of device though. I guess in some of those cases it might be better to have a load balancer in front of the device. Or use an alternative PKI.
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.
Identical signing of the same cert also runs into issues like "who gets to decide the serial number" and "how to deal with revocation lists: all of, or any of?".
And turning fields like issuer and serial into arrays risks someone accidentally using index 0 for one field and index 1 for another.
Combine that with the insane back-and-forth nightmare that the issuance process would turn into, and I have a very hard time seeing the benefit in it. After all, nobody is stopping you from requesting multiple certs independently, watching the revocation logs, and switching to the backup when required.
1 reply →
I think certificates should be like badges that you can collect – the more badges the higher the trust. So if you are a French company, maybe the tax office in France can sign your certificate to show that you indeed is a real company. If you are accepting card payments – Visa and Mastercard could sign your certificate. If you have a domain the TLD owner could sign your certificate to show that it's indeed your domain… And so on…
And then the browser could present these badges in a nice way to the user.
I just worry that this would just bring us back to the: "Pay $$$$$$ for a certificate, those pesky lets encrypt free certs are not expensive enough to give trust", BS that always happens.
Imagining those little "Intel Inside" "AMD Athlon" "Windows Vista" style stickers all over my browser address bar
And then you have that one website trying to collect them all.
Every time there is a CA issue, someone comes up with "this would be so much better if we'd make it more complex than it already is, as it would make it a bit more convenient to deal with the most recent issue".
I don't think that's the right way to think about it.