Re: [TLS] Verifying X.509 Certificate Chains out of order

Nelson B Bolyard <> Tue, 14 October 2008 00:55 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id A24F73A6A5C; Mon, 13 Oct 2008 17:55:40 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E5983A6A5C for <>; Mon, 13 Oct 2008 17:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j3BKcwwaSZsG for <>; Mon, 13 Oct 2008 17:55:28 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id C6C0F3A6A17 for <>; Mon, 13 Oct 2008 17:55:28 -0700 (PDT)
Received: (qmail 630 invoked from network); 14 Oct 2008 00:56:22 -0000
Received: from unknown ( by ( with ESMTP; 14 Oct 2008 00:56:22 -0000
Message-ID: <>
Date: Mon, 13 Oct 2008 17:56:20 -0700
From: Nelson B Bolyard <>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20080930003201 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote, On 2008-10-12 00:05:
> Nelson B Bolyard <>; writes:

>> - Client certs are requested in EVERY handshake.
>> [...]
>> - If the server receives a client certificate that it does not recognize
>>  as being authorized to authenticate any user, instead of ignoring the
>>  cert, and going on to request authentication using one of the other
>>  methods (e.g. user name and password), it drops the connection, usually
>>  without sending any alert.
> Hmm, that's new, the behaviour I saw was that the servers always asked for
> certs but when sent a no-cert response they continued as normal.  What you're
> seeing could just be a variant of the same broken behaviour, only now the
> server does a bit more checking and fails on the cert it doesn't know it's
> asked for rather than just ignoring it.

I think we've been seeing the behaviors of the same product.
As you say, if you send a no-certificate response, the server continues
in the "normal" (no client auth) fashion.  But if you DO provide a client
cert, then the server drops the connection.
TLS mailing list