Skip Menu |
 
Ticket metadata
The Basics
Id: 3621
Status: resolved
Priority: 0/
Queue: OpenSSL-Bugs

Custom Fields
Milestone: (no value)
Subsystem: (no value)
Severity: (no value)
Broken in: (no value)

People
Owner: Nobody in particular
Requestors: Kai Engert
Steffen Ullrich
Cc:
AdminCc:

More about the requestors

Kai Engert

Comments about this user: No comment entered about this user
Groups this user belongs to
  • Everyone
  • Unprivileged

Steffen Ullrich

Comments about this user: No comment entered about this user
Groups this user belongs to
  • Everyone
  • Unprivileged

New reminder:
Subject:
Owner:
Due:

Dates
Created: Fri Dec 05 14:18:30 2014
Starts: Not set
Started: Mon Dec 15 13:54:46 2014
Last Contact: Fri May 29 10:05:19 2015
Due: Not set
Closed: Fri May 29 10:05:20 2015
Updated: Thu Sep 10 00:16:47 2015 by Emilia Käsper



CC: Alexander Bluhm <Alexander_Bluhm@genua.de>
Subject: Bug: verification fails if muliple certification path (EV/Verisign)
Date: Fri, 24 Feb 2012 19:14:26 +0100
To: rt@openssl.org
From: Steffen Ullrich <Steffen_Ullrich@genua.de>
Download (untitled) / with headers
text/plain 4.3k
Hi, we get the following verification problem in our product, because
some servers like signin.ebay.de, comdirect.de or meine.deutsche-bank.de
add additional certicates to the chain, which are needed for some
clients but not for others. Unfortunatly these are not minor companies
and all of the certificates are EV.
Tests done with various openssl versions from 0.9.7j up to 1.0.0a on
OpenBSD and 1.0.0e and 1.0.1beta2 on Ubuntu 11.10.

Details:

The server sends 3 certificates (cert3, cert2 and cert1) while the client
has certB and/or certR as a trusted root certificate.
certR signs cert1, while certB signs cert2 by using the same public key
as cert1.
The certificate hierarchy as a picture:

---------
| Cert3 |
| | |
| Cert2 ----------
| | | |
| Cert1 | |
|___|___| |
| |
| |
CertR -\ CertB -\
|____| |____|


cert3.pem
- ..CN=meine.deutsche-bank.de
- SHA1 Fingerprint=6C:F2:11:14:DC:4F:77:95:1A:67:63:E1:64:2B:AE:2F:DF:33:EB:BC
cert2.pem
- ..CN=VeriSign Class 3 Extended Validation SSL SGC CA
- SHA1 Fingerprint=B1:80:39:89:98:31:F1:52:61:46:67:CF:23:FF:CE:A2:B0:E7:3D:AB
cert1.pem
- ..CN=VeriSign Class 3 Public Primary Certification Authority - G5
- SHA1 Fingerprint=29:B7:3D:9F:75:01:B8:C0:AD:FD:5E:43:37:A3:90:D1:AD:20:5F:48

certB.pem
- ..CN=VeriSign Class 3 Public Primary Certification Authority - G5
- SHA1 Fingerprint=4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5
- this has the same public key as cert1, but is self signed
certR.pem
- C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
- SHA1 Fingerprint=74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2
- this is very old but still valid, but MD2/RSA signed and thus probably not
added in some products
(it's not in /etc/ssl/certs on Ubuntu 11.10)


The following tests will be done

- openssl verify -verbose -CAfile chain21.pem cert3.pem
cat cert2.pem cert1.pem > chain21.pem
will FAIL because neither certB nor certR are present and so no root is found

- openssl verify -verbose -CAfile chain21R.pem cert3.pem
cat cert2.pem cert1.pem certR.pem > chain21R.pem
will SUCCEED because a complete hierarchy to the root can be found:
cert3 - cert2 - cert1 - certR

- openssl verify -verbose -CAfile chain2B.pem cert3.pem
cat cert2.pem certB.pem > chain2B.pem
will SUCCEED because a complete hierarchy to the root can be found:
cert3 - cert2 - certB

so far everything is like expected, but it gets interesting if we have
both cert1 and certB. Note that cert1 has the same public key as certB
so that both certificates sign cert2.

- openssl verify -verbose -CAfile chain21B.pem cert3.pem
cat cert2.pem cert1.pem certB.pem > chain21B.pem
The expected thing is, that it will succeed because it can verify
cert3 - cert2 - cert B and just ignore cert1.
But it FAILs because it tries cert3 - cert2 - cert1 - .. and then it
is missing certR

- openssl verify -verbose -CAfile chain2B1.pem cert3.pem
cat cert2.pem certB.pem cert1.pem > chain2B1.pem
same certificates as last test, but this time certB is before cert1.
I would expect, that the order does not matter, but this SUCCEEDs
because of cert3 - cert2 - certB and it ignores cert1

And this is where the bug is: one should expect, that it ignores an
the unneeded cert1 in both cases, but the behavior depends on the order
of the certicates in the chain.

The bug causes konqueror (using openssl) to fail on certificate check,
while Chrome and firefox (using NSS) succeed. At least FF seems to
have certR too, but uses certB, probably because the trust chain is
shorter. Opera on Linux and MSIE8 on Windows XP succeed too, also using
certB and not certR for verification.

A similar problem was already reported, but w/o response:
http://rt.openssl.org/Ticket/Display.html?id=2634
and maybe http://rt.openssl.org/Ticket/Display.html?id=1851
is also related.

If you need more information or tests please let me know.

Regards,
Steffen Ullrich

--
GeNUA Gesellschaft f\xFCr Netzwerk - und Unix-Administration mbH
Domagkstr. 7, D-85551 Kirchheim. http://www.genua.de
Tel: (089) 99 19 50-0, Fax: (089) 99 10 50 - 999

Gesch\xE4ftsf\xFChrer: Dr. Magnus Harlander, Dr. Michaela Harlander,
Bernhard Schneck. Amtsgericht M\xFCnchen HRB 98238
Download cert1.pem
text/plain 5.2k

Message body is not shown because sender requested not to inline it.

Download cert2.pem
text/plain 6.3k

Message body is not shown because sender requested not to inline it.

Download cert3.pem
text/plain 6.3k

Message body is not shown because sender requested not to inline it.

Download certB.pem
text/plain 5k

Message body is not shown because sender requested not to inline it.

Download certR.pem
text/plain 2.5k

Message body is not shown because sender requested not to inline it.

Subject: [openssl.org #2732] Bug: verification fails if muliple certification path (EV/Verisign)
Date: Tue, 06 Mar 2012 13:10:48 +0100
To: rt@openssl.org
From: Dan Lukes <dan@obluda.cz>
Download (untitled) / with headers
text/plain 1.4k

Same problem apply for cross-certificates which create multiple paths also.

Imagine the expiring CA (expiring within year or two, not expired
already). The organization will create the new one, but want to maintain
transition period for the users. So create two cross certificates - the
public of oldCA will sign by new CA and vice versa. So resulting
structure is:


a) public key of newCA is selfsigned, creating root certificate of new tree
b) same public key is signed by oldCA with CA:TRUE attribute, creating
certificate of intermediate CA authority within old tree

End servers with certificate issued by (newCA|intermediate CA) should
send following chain:

----------------------------
s: /CN=EndCertificate
i: /CN=newCA

s: /CN=newCA # This is intermediate CA certificate
i: /CN=oldCA
----------------------------

Scenario 1:
User is not aware of existence newCA yet (but oldCA is still not expired
and trusted by user). Verification:

EndCertificate issued by (newCA|intermediate CA) issued by oldCA

Conclusion: certificate considered trusted

----------------------------

Scenario 2:
User trusting newCA. Verification:

EndCertificate issued by (newCA|intermediate CA) which is considered
trusted by user, no further steps required

Conclusion: certificate considered trusted

----------------------------

Unfortunately, scenario 2 doesn't work with OpenSSL.
End-of-chain certificates are verified against trusted store only.

So painless transition from one CA to other CA is not possible

Dan
Subject: [openssl.org #2732][PATCH] search for trust anchor while validating chain
Date: Wed, 13 Jun 2012 17:09:53 +0200
To: rt@openssl.org
From: Arne Becker <abecker@genua.de>
Download (untitled) / with headers
text/plain 518b
Hi.

Attached is a patch that changes the behavior of X509_verify_cert in
crypto/x509/x509_vfy.c
While copying the cert chain into the X509_STORE_CTX, before adding a
cert, a check is done to see if we could reach one of our trust anchors
instead.
This solves the problem with a certificate chain ending in a
certificate not in the trust store, that would be acceptable using a
different path.

Please see this as a request for comments, since I'm not an expert (yet)
on X509 path discovery.

Thanks in advance,
Arne

Message body is not shown because sender requested not to inline it.

Subject: Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default
Date: Thu, 04 Dec 2014 13:33:35 +0100
To: rt@openssl.org
From: Kai Engert <kaie@kuix.de>
Download (untitled) / with headers
text/plain 4.3k
Enhancement request.

I suggest to enhance the trust chain discovery used by openssl, when
verifying a SSL/TLS server certificate, to make it work with a popular
server configuration.

Recently, Mozilla has started to cleanup the Mozilla CA trust list and
remove CA certificates that use a weaker 1024-bit RSA key. I'll call
them legacy CAs.

When upgrading the trust store used by openssl to exclude the legacy CA
certificates, by default, openssl (e.g. s_client) can no longer verify
the server certificate of several popular SSL/TLS servers, examples are
www.flickr.com and www.amazon.com.

The reason is the approach that CA organizations have used for a smooth
rollover from legacy CA certificates to more recent CA certificates
(with stronger keys). That approach is compatible with the NSS library,
and also with recent versions of the GnuTLS library (e.g. version
3.3.10).

The approach works like explained in the following simplified example.
Let's say we have:
- a legacy CA, self-signed, with issuer/subject name: OLD-CA-1024
- an intermediate CA, with subject name NEW-CA-2048, signed by the
issuer OLD-CA-1024.
- a server certificate, with subject name www.server, signed by the
issuer NEW-CA-2048.

In the past, only OLD-CA-1024 was included in the Mozilla CA trust list.
When the above chain is found, the www.server certificate can be
verified.

In addition to the above, the CA organization creates another
certificate, an alternative version of the NEW-CA-2048 certificate,
which is based on the same public/private key pair, but which is self
signed (issuer and subject names are both NEW-CA-2048).

The CA has worked with Mozilla to get the self-signed version of
NEW-CA-2048 included in the Mozilla trust list. When trusting
NEW-CA-2048, this CA certificate is sufficient to find a valid issuer
chain for www.server.

In practice, the OLD-CA-1024 certificate and the issued certificates
have a remaining lifetime of up to several years, but the web server
configurations are keeping their old configuration. They still send the
intermediate CA version of the NEW-CA-2048 certificate, which is signed
by OLD-CA-1024. This is done for two reasons. First, it is helpful for
enhanced compatibility, the server can work with client software that
trusts OLD-CA-1024, only, and which hasn't been upgraded to trust the
self-signed version of NEW-CA-2048. Second, there are many
administrators who aren't updating their servers, because their server
certificate is still valid.

This means, those servers will keep sending the intermediate CA version
of NEW-CA-2048 in the SSL/TLS handshake.

In order to function correctly with those servers when using the cleaned
up trust list (OLD-CA-1024 removed), it is necessary that client
software attempts to discover more than one version of a trust chain. In
particular, it should be able to ignore an unnecessary intermediate sent
by the server, in order to find a shorter trust path.

However, by default, openssl will not find the shorter path, and will
reject the server certificate, e.g. reporting the inability to get the
issuer certificate.

Unfortunately, this current default behaviour of openssl blocks the
removal of the legacy CA certificates with weaker keys from the CA trust
list, because many existing applications use the openssl default, and
removing the legacy CAs would cause the applications to fail connecting
to the affected servers.

Therefore I'd like to suggest to change the openssl default behaviour,
to make it possible to allow client applications to be compatible with
the above scenario, by upgrading to a newer version of the openssl
library.

When discussing this issue, my colleague Hubert Kario made me aware of a
flag offered by e.g. the openssl s_client utility: "-trusted_first".
When using -trusted_first, the server verification works successfully in
the above scenario.

Given that the suggestion is to change openssl's default behaviour,
changing openssl to use the -trusted_first mode by default might
potentially be a solution. However, it's not obvious if this mode could
have other side effects that are undesirable.

Therefore I suggest to discuss which approach is best to support the
removal of legacy CAs, either by changing the default of the
-trusted_first setting, or by implementing another solution. I think it
would be good to find a solution that could be backported to the openssl
1.0.1 branch.

Thanks in advance for discussing and working on this issue.
Kai
Subject: Re: [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default
Date: Mon, 15 Dec 2014 14:54:36 +0100
To: "'rt@openssl.org'" <rt@openssl.org>
From: Hubert Kario <hkario@redhat.com>
Download (untitled) / with headers
text/plain 1.8k
On Friday 05 December 2014 15:18:30 you wrote:
Show quoted text
> When discussing this issue, my colleague Hubert Kario made me aware of a
> flag offered by e.g. the openssl s_client utility: "-trusted_first".
> When using -trusted_first, the server verification works successfully in
> the above scenario.
>
> Given that the suggestion is to change openssl's default behaviour,
> changing openssl to use the -trusted_first mode by default might
> potentially be a solution. However, it's not obvious if this mode could
> have other side effects that are undesirable.
>
> Therefore I suggest to discuss which approach is best to support the
> removal of legacy CAs, either by changing the default of the
> -trusted_first setting, or by implementing another solution. I think it
> would be good to find a solution that could be backported to the openssl
> 1.0.1 branch.

For what it's worth, I have tested the Alexa top 1 million servers with the
-trusted_first option and haven't found a single server that looses its
trusted status, on the other hand, good few percent of servers do gain it.
That doesn't mean there aren't any (or that I haven't made a mistake in the
tests), but I can't think of a CA structure that would validate correctly with
old mode while not with the new mode (so at least the experiment matches
theory).

More specifically the test was done by setting X509_STORE_set_flags(store,
X509_V_FLAG_TRUSTED_FIRST); during verification. Full code that I used for
testing is available here:
https://github.com/jvehent/cipherscan/blob/master/top1m/parse_CAs.c
https://github.com/jvehent/cipherscan/blob/master/top1m/process-certificate-statistics.sh
(the baseline was achieved by just commenting out the above mentioned line)
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
Subject: RE: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default
Date: Mon, 15 Dec 2014 09:23:26 -0500
To: "rt@openssl.org" <rt@openssl.org>, "openssl-dev@openssl.org" <openssl-dev@openssl.org>, "kaie@kuix.de" <kaie@kuix.de>
From: "Salz, Rich" <rsalz@akamai.com>
Download (untitled) / with headers
text/plain 304b

Show quoted text
> For what it's worth, I have tested the Alexa top 1 million servers with the -
> trusted_first option and haven't found a single server that looses its trusted
> status, on the other hand, good few percent of servers do gain it.

It's worth a great deal. Thanks! I love fact-based analysis. :)
CC: "kaie@kuix.de" <kaie@kuix.de>
Subject: Re: [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default
Date: Mon, 29 Dec 2014 11:07:58 -0800
To: "openssl-dev@openssl.org" <openssl-dev@openssl.org>, "rt@openssl.org" <rt@openssl.org>
From: Yuhong Bao <yuhongbao_386@hotmail.com>
Download (untitled) / with headers
text/plain 248b
As a warning, the Equifax root expires in August 2018 and hopefully will removed from Mozilla soon. Right now GeoTrust is still promoting the use of their GeoTrust to Equifax cross-certificate, and they do issue four year certificates.
Please see the following commits to master in relation to this issue:

da084a5ec6
15dba5be6a
25690b7f5f
fa7b01115b

The behaviour is now that openssl will attempt to build a trust chain as it did previously. If that fails, it will then look to see if there is an alternative chain that can be constructed that does succeed. This behaviour can be suppressed using the X509_V_FLAG_NO_ALT_CHAINS flag - this will make openssl behave as it does now.

Closing this ticket.

Matt
Subject: Re: [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default
Date: Mon, 16 Mar 2015 10:44:40 +0100
To: rt@openssl.org
From: Kai Engert <kaie@kuix.de>
Download (untitled) / with headers
text/plain 312b
Thank you very much for your work on this issue!
In my testing so far, it works as requested.

I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2
stable branch, and the test suite succeeeds.

Will you consider to add this enhancement in a feature release on the
1.0.2 branch?

Regards
Kai
Subject: Re: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default
Date: Wed, 27 May 2015 00:41:12 -0400
To: rt@openssl.org, openssl-dev@openssl.org
From: Ray Satiro <raysatiro@yahoo.com>
Download (untitled) / with headers
text/plain 2.4k
On 3/16/2015 5:45 AM, Kai Engert via RT wrote:
Show quoted text
> Thank you very much for your work on this issue!
> In my testing so far, it works as requested.
>
> I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2
> stable branch, and the test suite succeeeds.
>
> Will you consider to add this enhancement in a feature release on the
> 1.0.2 branch?

I second this. It looks like this is also discussed in bug #2634 where
it was considered an enhancement and therefore will not be in 1.0.2. It
seems more like a bug fix to me though. If OpenSSL can complete the
chain it should. What would be the disadvantage of doing so?

I work on the cURL project and I've encountered this problem twice in
the last month.

The first time was a reporter mentioned an issue connecting to Apache
git-wip-us.apache.org. That looks to be the VeriSign issue discussed in
#2634. The server at the time had sent the old intermediate "VeriSign
Class 3 Public Primary Certification Authority - G5" signed by "Class 3
Public Primary Certification Authority" (VeriSign root legacy) which is
no longer included in the Mozilla bundle. The bundle does include the
newer "VeriSign Class 3 Public Primary Certification Authority - G5"
(now a root) but OpenSSL didn't use it to complete the chain. It looks
like the Apache team fixed the issue [1] by removing the old VeriSign
intermediate. But by doing that clients with an older bundle can no
longer connect.

The second time just this evening, I'm investigating a reported latency
issue (unrelated) with mediafire.com. Its server sends 6 intermediate
certificates and one of the intermediates (actually 2 if you count the
dupe) is a legacy intermediate that is now a root. "thawte Primary Root
CA" sent by the server is signed by "Thawte Premium Server CA" (thawte
root legacy) which is no longer included in the Mozilla bundle. The
bundle does include the newer "thawte Primary Root CA" (now a root) and,
same as above, OpenSSL didn't use it to complete the chain.

Internet Explorer and Firefox handled both verifications correctly, as
one would expect. I understand you may consider the behavior in OpenSSL
< 1.1.0 to be correct but the end result here is that those clients with
the newer bundles are going to fail verify unable to get issuer. There
is a compatible issuer in the bundle. I don't know of any other examples
but I can imagine as legacy certificates are removed the issue could
persist.


[1]: https://issues.apache.org/jira/browse/INFRA-9605
RT-Send-CC: raysatiro@yahoo.com
On Wed May 27 06:41:51 2015, raysatiro@yahoo.com wrote:
Show quoted text
> On 3/16/2015 5:45 AM, Kai Engert via RT wrote:
> > Thank you very much for your work on this issue!
> > In my testing so far, it works as requested.
> >
> > I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2
> > stable branch, and the test suite succeeeds.
> >
> > Will you consider to add this enhancement in a feature release on the
> > 1.0.2 branch?
>
> I second this. It looks like this is also discussed in bug #2634 where
> it was considered an enhancement and therefore will not be in 1.0.2. It
> seems more like a bug fix to me though. If OpenSSL can complete the
> chain it should. What would be the disadvantage of doing so?

This issue is now being treated as a bug fix and the fix was already applied to the 1.0.2 tree a while ago (and therefore will appear in the next 1.0.2 release). A backport for 1.0.1 also exists but has not yet hit the repo.

Matt


Subject: Re: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default
Date: Thu, 28 May 2015 23:40:16 -0400
To: rt@openssl.org, openssl-dev@openssl.org
From: Ray Satiro <raysatiro@yahoo.com>
Download (untitled) / with headers
text/plain 1.3k
On 5/27/2015 4:21 AM, Matt Caswell via RT wrote:
Show quoted text
> On Wed May 27 06:41:51 2015, raysatiro@yahoo.com wrote:
>> On 3/16/2015 5:45 AM, Kai Engert via RT wrote:
>>> Thank you very much for your work on this issue!
>>> In my testing so far, it works as requested.
>>>
>>> I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2
>>> stable branch, and the test suite succeeeds.
>>>
>>> Will you consider to add this enhancement in a feature release on the
>>> 1.0.2 branch?
>> I second this. It looks like this is also discussed in bug #2634 where
>> it was considered an enhancement and therefore will not be in 1.0.2. It
>> seems more like a bug fix to me though. If OpenSSL can complete the
>> chain it should. What would be the disadvantage of doing so?
> This issue is now being treated as a bug fix and the fix was already applied to
> the 1.0.2 tree a while ago (and therefore will appear in the next 1.0.2
> release). A backport for 1.0.1 also exists but has not yet hit the repo.
>
> Matt

Thanks Matt. TRUSTED_FIRST flag has been brought up a few times on
curl-library and we are wondering what would be the disadvantages if we
added it to our default flags? Also, the alt chain check in x509_vfy.c
isn't done if TRUSTED_FIRST and I'm having trouble grasping why that is.
Why not check for alternate chains regardless of whether or not you're
checking trusted store first?
On Fri May 29 05:40:51 2015, raysatiro@yahoo.com wrote:
Show quoted text
> On 5/27/2015 4:21 AM, Matt Caswell via RT wrote:
> > On Wed May 27 06:41:51 2015, raysatiro@yahoo.com wrote:
> >> On 3/16/2015 5:45 AM, Kai Engert via RT wrote:
> >>> Thank you very much for your work on this issue!
> >>> In my testing so far, it works as requested.
> >>>
> >>> I noticed the code changes in x509_vfy.c apply fine on top of the
> 1.0.2
> >>> stable branch, and the test suite succeeeds.
> >>>
> >>> Will you consider to add this enhancement in a feature release on
> the
> >>> 1.0.2 branch?
> >> I second this. It looks like this is also discussed in bug #2634
> where
> >> it was considered an enhancement and therefore will not be in
> 1.0.2. It
> >> seems more like a bug fix to me though. If OpenSSL can complete the
> >> chain it should. What would be the disadvantage of doing so?
> > This issue is now being treated as a bug fix and the fix was already
> applied to
> > the 1.0.2 tree a while ago (and therefore will appear in the next
> 1.0.2
> > release). A backport for 1.0.1 also exists but has not yet hit the
> repo.
> >
> > Matt
>
> Thanks Matt. TRUSTED_FIRST flag has been brought up a few times on
> curl-library and we are wondering what would be the disadvantages if
> we
> added it to our default flags? Also, the alt chain check in x509_vfy.c
> isn't done if TRUSTED_FIRST and I'm having trouble grasping why that
> is.
> Why not check for alternate chains regardless of whether or not you're
> checking trusted store first?
>
From 1.0.2b onwards OpenSSL will support three different strategies for achieving the goal of building a valid certificate chain:

1) Old style
2) Trusted first
3) Alt chains

With old style (all current versions of OpenSSL) we start with the peer provided certificate, then we add as many certificates to the chain as we can from the list provided by the peer. Finally we add as many as we can from the trusted certificate store. If we end up with a valid chain then we have been successful.

From 1.0.2 we additionally support the trusted first strategy (although this is not the default). In this strategy we start with the peer provided certificate and then see if we can add certificates from the trusted store to build a chain. If we can then great - we're done. Otherwise we add a certificate from the peer provided list and then check the trusted store again, and so on until we have either found a chain or run out of peer provided certificates to add.

We considered making trusted first the default strategy however there is a problem with this. The trusted store logic will cache certificates that we look up. However we only cache *success* but not *failure*. Therefore there is a potential performance hit every time we go through the trusted store but fail to find any certificates. The trusted first strategy could end up doing this a lot. Its unclear exactly how big this performance hit is - but that is the reason why we were wary of making this the default.

From 1.0.2b we will also support the alt chains strategy (and this will be the default). This starts off in exactly the same way as the old style approach.  However if after adding all the certificates from the peer provided list we are unable to build a trusted chain, then we pop the last certificate off the chain we've built so far and go back to the trusted store to have another go. We continue this until we've got no more certificates to pop.

The primary advantage of the alt chains strategy is that there is no performance hit over any chain that would be successfully built using the old style strategy (because it starts off in the same way). There might be a performance hit on unsuccessful chain building over the old style - but we assume this is less of an issue.

It makes no sense to combine the trusted first and alt chains strategies. With trusted first we have already checked all of the possible chains by the time we get to the end of the peer provided list - so there is no point in then popping certs off the top of our chain and checking the trusted store again.

Hope that clarifies things,

Matt