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

Martin Rex <> Tue, 07 October 2008 21:30 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 0A5113A6B7C; Tue, 7 Oct 2008 14:30:36 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB6013A6AD3 for <>; Tue, 7 Oct 2008 14:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.966
X-Spam-Status: No, score=-5.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bHTAoxPDfOkE for <>; Tue, 7 Oct 2008 14:30:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2D44E28C0DE for <>; Tue, 7 Oct 2008 14:30:23 -0700 (PDT)
Received: from by (26) with ESMTP id m97LUQhK004836; Tue, 7 Oct 2008 23:30:26 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (Stefan Santesson)
Date: Tue, 7 Oct 2008 23:30:25 +0200 (MEST)
In-Reply-To: <> from "Stefan Santesson" at Oct 7, 8 06:01:12 pm
MIME-Version: 1.0
X-Scanner: Virus Scanner virwal05
X-SAP: out
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

Stefan Santesson wrote:
> On the original question:
> > It is claimed that OpenSSL, IE and Firefox does not enforce the second
> > MUST in the paragraph above, and succeeds in verifying an
> > out-of-sequence chain.  I haven't verified the claim.
> A Microsoft based SSL server will insert the certificates in order.
> A Microsoft based SSL client doesn't require the certificates to be
> in order. The client simply passes these certificates to the
> CertGetCertificateChain API in the hAdditionalStore parameter.
> This will validate the subject certificate regardless of order.

I would appreciate if we could discuss the issue with terms of simple
facts instead of in terms of a proprietary API.

My familiarity with Microsoft CryptoAPI is close to zero,
but a first glance suggests that you MUST explicitly provide
an End Entity cert to CertGetCertificateChain(), parameter pCertContext.

Either you have a hen-and-egg problem, or the certificate_list
is not as unsorted as you claim it is.  How do you know which one
is the End Entity cert without either relying that it is the first
cert (as required by all existings TLS specs) or by first doing
a manual search and applying heuristics (something that I seriously
frown upon).

TLS mailing list