Le 12/07/2012 15:36, David Woodhouse a écrit :
I have encountered a server which presents an invalid set of
certificates in its TLS handshake.
This is common. Really common.
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).
If it has the same name, then it's the same CA. Has it been rekeyed?
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*.
As do other toolkits and browsers.
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.
Does GnuTLS have access to the missing intermediate CA, too?
GnuTLS is not really a good example, it doesn't follow X.520 naming, and
doesn't enforce the pathLen constraints.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
