Re: [TLS] Certificate handshake message - common config problems

[Martin Rex <[e-mail]>]

Martin Rex wrote:
> 
> Dear TLS,
> 
> I have just analyzed an interop problem reported by a customer
> that was caused by a misconfigured apache web server of a third
> party.
> 
> The problem is, that this apache sends a Certificate message
> that contains the EndEntity certificate twice in a row,
> followed by an otherwise correct chain of 3 CA certificates.
> 
> Browsers like Firefox and MSIE do not report this as an error.
> MSIE doesn't barf, because AFAIK it applies a generic cert chain building
> algorithm to all certs following the initial end entity cert.  I don't
> know what kind of algorithm firefox uses in order to eliminate the
> duplicated end entity cert.
> 
> The cause of the problem is the lack of consistency checks performed
> by OpenSSL when building the certificate_list in Certficate handshake
> messages.  The SSL&TLS spec are clear that what this server is sending
> is not compliant to the protocol.  The only one able to fix this
> configuration problem is the operator of the server, and the one
> who would be able to prevent this problem from occurring is OpenSSL.
> 
> 
> I think it that original protocol requirement (well-formed cert chain)
> is a very useful protocol feature, because it can save code,
> dynamic memory footprint and cpu-cycles, and it also leads to
> much more consistent results if everyone validates _the_same_
> certificate path.  Having OpenSSL build the chain before
> sending it (in addition to when receiving it) might be a good
> idea -- and could catch other errors, such as missing intermediate
> certs, immediately and under control of those who are able to
> and responsible for fixing it.

Clarifying myself:

the TLS peer receiving the Certificate message
(i.e. the TLS client receiving the server's Certificate message)
needs to do a certificate path validation, but could save
chain building when the well-formed chain requirement in the
spec is followed.

The TLS peer sending a Certificate message does not need to perform
a full certificate path validation, a chain building alone would 
already improve the situation and catch most of the current
interop problems in that area.

I know little about apache&OpenSSL (never installed or operated
one myself), but IIRC, there are two seperate files, one with
the EndEntity cert and one with the CertificateChain.
It appears that all of the certificates from the Chain file will
be blindly appended to the EndEntity cert when the certificate_list
for the Certificate handshake message is composed. 


To easily see the cause of the problem, you need either WireShark
or an SSL implementation that can visualize what it _receives_!.
MSIE is fairly useless for this purpose, because it does _not_
show you what it receives.  If anything, it shows
what it _validates_, which is something entirely different.
This becomes apparent in situations like this (duplicated cert
in the chain), incorrectly ordered certs, or _missing_ certs
in the chain if there's AIA information included.


-Martin