On Tue, 2 Feb 2016 19:14:24 +0100 Kurt Roeckx <k...@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
