|
|
|
|
|
|
by stefan_
895 days ago
|
|
|
You are overthinking it. Some sysadmin copying the same cert into the chain twice because AWS is confusing and doesn’t care and OpenSSL doesn’t care isn’t resolving the grand problem of the trust graph, it’s just a loss overall, for everyone. Nobody wins here. (Of course the 1.3 approach of throwing a bunch of certificates and then asking to resolve over all of them breaks BearSSL comprehensively) |
|
|
But requiring the cert chain to be exactly correct is also useless if you need to address clients with different root cert packages. If some clients have only root A and some have only root B, but B did a cross-sign for A, you're ok if you send entity signed by intermediate, intermediate signed by A, A signed by B and clients with A only short circuit after they see an intermediate signed by A, and the clients with B only should be fine too. Of course it gets real weird when the B root has expired, and clients often have A and B, but some don't check if their roots expired, and some won't short circuit to validating with A, so they fail the cert because B is expired.
Oh, and TLS handshakes in the wild don't give you explicit information about what roots they have or what client / version they are. Sometimes you can get a little bit of information and return different cert chains to different clients, but there's also not a lot of support for that in most server stacks.
I don't necessarily like TLS 1.3's approach of end entity cert comes first and then just try all the permutations and accept any one that works, but at least it presents a way to get to success given the reality we live in. I'd also love to see some way to get your end entity cert signed by multiple intermediates, but that's a whole nother level of terrible.
#notbitter