[Pkg-openssl-devel] Bug#813468: Bug#813468: cross-references and workaround

[Simon Ruggier]

On Tue, 2 Feb 2016 19:14:24 +0100 Kurt Roeckx <kurt at roeckx.be> wrote:
>[ ...]
> On Tue, Feb 02, 2016 at 03:04:41PM +0100, Christian Beer wrote:
> > Since it works in openssl 1.0.2 you can either upgrade the package in
> > Jessie to 1.0.2 (which is unlikely I think) or backport the fix for
> > 1.0.2 to 1.0.1 upstream (which is even more unlikely).
>
> This has already been fixed in the upstream 1.0.1 release of a
> year ago.

Can you elaborate on which release of 1.0.1 you think fixes this
issue? I've looked in the 1.0.1 changelog[1] and I don't see any items
that look like they would address this. To confirm my suspicion, I
downloaded and built the 1.0.1r tarball and tested it, it still fails
to accept a valid certificate whose trust chain should end in a
non-self-signed/intermediate certificate. In my case, I'm looking at a
site whose trust chain ends with the Baltimore CyberTrust Root, which
is "issued by" the weak GTE CyberTrust Global Root that is now gone
from ca-certificates. The openssl 1.0.2f command from stretch accepts
it, while 1.0.1 tries and fails to get the issuer cert:
> $ /tmp/openssl/1.0.1r/installprefix/bin/openssl s_client -connect us12.api.mailchimp.com:443
> CONNECTED(00000003)
> depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
> verify error:num=20:unable to get local issuer certificate
> verify return:0
> ---
> Certificate chain
>  0 s:/C=US/ST=GA/L=Atlanta/O=ROCKET SCIENCE GROUP/OU=Rocket Science Group/CN=*.api.mailchimp.com
>    i:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
>  1 s:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
>    i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
>  2 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
>    i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
> ---

I suspect that this is the change in 1.0.2 that fixes this problem:[2]
>  *) Initial experimental support for explicitly trusted non-root CAs.
>     OpenSSL still tries to build a complete chain to a root but if an
>     intermediate CA has a trust setting included that is used. The first
>     setting is used: whether to trust (e.g., -addtrust option to the x509
>     utility) or reject.
>     [Steve Henson]

This is a pretty big issue for a tool whose main job description
includes verifying SSL certificates. I think it would be reasonable to
fix this in Jessie, even if that means putting 1.0.2 in its entirety
into a SRU. I'm going to chime in on 765639 as well.

[1] https://www.openssl.org/news/openssl-1.0.1-notes.html
[2] https://www.openssl.org/news/changelog.html#x7