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

[Kurt Roeckx]

On Fri, Feb 19, 2016 at 10:09:51PM -0500, Simon Ruggier wrote:
> 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?

It should be part of the 1.0.1n release.

(For some reason this doesn't seem to be in the changelog?)

> 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

Try adding -CApath /etc/ssl/certs/

Or use --openssldir=/usr/lib/ssl when building to get the correct
default.


Kurt