Re:DigiCert: Threat of legal action to stifle Bugzilla disco...
by toast0 on Tuesday February 25, 2025 @09:34AM
(#43172346)
I think TLS 1.3 still requires the end entity (server/client) cert first. All the other certs can now be in any order and the verification is suppoaed to figure out a valid path.
In theory, you could make an intermediate CA and get cross signed certs from multiple CAs (hopefully with Name Constraints), your intermediate CA signs your server cert, and you include all your cross certs and the intermediate certs for those. And the client figures out which chains it can make and if it likes any of them.
But experience has shown, verification may find a chain with signatures that line up, but the CA is expired or revoked in the local trust store, and reject the verification, even though another chain could have been found with the provided certificates.
And, because of the limited information in tls handshakes from real world clients, it's difficult (maybe impossible) to know which CAs a client would accept, so that the server could present an appropriate chain.
In theory, you could make an intermediate CA and get cross signed certs from multiple CAs (hopefully with Name Constraints), your intermediate CA signs your server cert, and you include all your cross certs and the intermediate certs for those. And the client figures out which chains it can make and if it likes any of them.
But experience has shown, verification may find a chain with signatures that line up, but the CA is expired or revoked in the local trust store, and reject the verification, even though another chain could have been found with the provided certificates.
And, because of the limited information in tls handshakes from real world clients, it's difficult (maybe impossible) to know which CAs a client would accept, so that the server could present an appropriate chain.