If the actual issuing CA is in your trust store and can be shown to have validly issued the server certificate, then by definition you trust that server.
.................................... Erik Tkal Juniper OAC/UAC/Pulse Development -----Original Message----- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of David Woodhouse Sent: Thursday, July 12, 2012 9:36 AM To: openssl-dev@openssl.org Subject: [RFC] OpenSSL accepts "invalid" server cert chain I have encountered a server which presents an invalid set of certificates in its TLS handshake. It's presenting four certificates, where the second cert is *not* the issuer of the first cert in the list. The chain from #2->#3->#4 is fine, but #2 isn't actually the issuer of #1. (It just happens to have the same *name* as the issuer of #1; cf. RT#1942). This violates RFC5246 §7.4.2, which says of the certificate_list that: This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. However, the missing intermediate CA *is* found in my local trust database, and OpenSSL verifies the server quite happily using *that*. This seems wrong — surely the handshake should be rejected? Should I submit a patch? I note that GnuTLS *does* reject the server's handshake — and rightly so, as far as I can tell from the RFC. -- dwmw2
