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

From: Martin Rex <[email-masked]>
Date: Fri, 29 Jan 2010 18:15:50 +0100 (MET)

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.

What do other implementers think about this issue?

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 Jan 2010 18:36:03 +0100

> What do other implementers think about this issue?

GnuTLS requires a correctly ordered certificate chain and will not
attempt to reorder it.

People have reported this as a problem from time to time, but it is
always a server problem that can/should be fixed, so right now I don't
see us spend any time to improving this on the validator side.  As you
noticed, some browser appears to accept this situation, hence people
might not notice the misconfiguration directly.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Fri, 29 Jan 2010 19:13:18 +0100 (MET)

> 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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 29 Jan 2010 17:33:03 -0500

> for the Certificate handshake message is composed. 

The docs for mod_ssl are pretty clear that the SSLCertificateChainFile
need not be used if the relevant certificates for the intermediate and
root CAs are already found in SSLCaCertificatePath, in which case it
appears that OpenSSL builds the chain automatically (and presumably
correctly):

http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslcertificatechainfile

Unfortunately, they also don't explicitly state that the certificates
*must* be properly ordered to be RFC-compliant.  in fact, they only say
"usually in certificate chain order".  This is probably a bug in mod_ssl
(at least in its documentation).  They should check and warn if the
provided CertificateChainFile does not form a proper chain.

> in the chain if there's AIA information included.

I think you want:

 openssl s_client -connect $HOST:$PORT -showcerts

hth,

	--dkg

---

From: Martin Rex <[email-masked]>
Date: Sat, 30 Jan 2010 00:40:12 +0100 (MET)

Thanks!

Having that information helps us providing clues.

We have to tell our customer what he will have to tell his
business partner to fix on that server...   :-)

-Martin