On Thu, 2012-07-12 at 20:44 +0200, Erwann Abalea wrote: > 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?
It has a different X509v3 Subject Key Identifier. The Subject Key Identifier of the second cert in the list does not match the Authority Key Identifier of the first cert. It's a broken chain. The server MUST NOT do this. > > 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? Yes. If the server had *omitted* the invalid intermediate CAs from its handshake and presented only the leaf certificate, GnuTLS would have accepted it. But when the server has blatantly violated the TLS standard, GnuTLS fails validation without checking further. To be honest, I don't care much whether it's accepted or not. The responses so far seem to suggest that accepting it would be a good idea. But what I care most about is that my VPN client behaves consistently whether it's linked against OpenSSL or GnuTLS. It sounds like I should 'fix' the GnuTLS side to accept this, even though it's broken behaviour on the part of the server. Thanks to everyone who replied. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
