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

Martin Rex <mrex@sap.com> Fri, 29 January 2010 23:39 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918B53A695E for <tls@core3.amsl.com>; Fri, 29 Jan 2010 15:39:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.219
X-Spam-Level:
X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKTVm5Qt+zfW for <tls@core3.amsl.com>; Fri, 29 Jan 2010 15:39:51 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 7BBC93A68AD for <tls@ietf.org>; Fri, 29 Jan 2010 15:39:50 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o0TNeDkn020354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Sat, 30 Jan 2010 00:40:13 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001292340.o0TNeC5f018719@fs4113.wdf.sap.corp>
To: tls@ietf.org
Date: Sat, 30 Jan 2010 00:40:12 +0100 (MET)
In-Reply-To: <4B63621F.7000208@fifthhorseman.net> from "Daniel Kahn Gillmor" at Jan 29, 10 05:33:03 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Subject: Re: [TLS] Certificate handshake message - common config problems
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2010 23:39:52 -0000

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

Daniel Kahn Gillmor wrote:
> 
> On 01/29/2010 01:13 PM, Martin Rex wrote:
> > 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. 
> 
> 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.
> 
> > 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.
> 
> I think you want:
> 
>  openssl s_client -connect $HOST:$PORT -showcerts
> 
> hth,
> 
> 	--dkg