On 04/21/2016 11:59 PM, Sebastian Andrzej Siewior wrote: > On 2016-03-28 18:57:59 [+0200], Christian Seiler wrote: >> For example, this breaks curl with those sites, which is used in a >> large variety of contexts, especially scripting languages. This might >> lead some people to disable certificate checking altogether because >> they don't know how to fix this, which is _much_ worse than keeping >> 1024 bit CAs in the root store. > > Do you have a test case for this?
The following came up as a question in #debian a while back (which is how I became aware of this bug in the first place, while trying to figure out what the problem of the person asking the question was): curl -I https://www.usaepay.com/ On Jessie, this currently fails with: curl: (60) SSL certificate problem: unable to get local issuer certificate Certificate chain of that domain: 0: subject `C=US,ST=California,L=Glendale,O=USA ePay,OU=Secure Services,CN=www.usaepay.com', issuer `C=US,O=thawte\, Inc.,CN=thawte SSL CA - G2', RSA key 2048 bits, signed using RSA-SHA256, activated `2015-11-16 00:00:00 UTC', expires `2018-01-01 23:59:59 UTC' 1: subject `C=US,O=thawte\, Inc.,CN=thawte SSL CA - G2', issuer `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2013-10-31 00:00:00 UTC', expires `2023-10-30 23:59:59 UTC' 2: subject `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', issuer `C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,EMAIL=premium-ser...@thawte.com', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-17 00:00:00 UTC', expires `2020-12-30 23:59:59 UTC' Certificate 2 is signed by "CN=Thawte Premium Server CA", which is just 1024bit, which was removed in version 20141019+deb8u1 from the ca-certificates package. Bug here is that openssl can't find the last issuer, so it fails verification. But if the last certificate hadn't been chained by the TLS server, openssl would have properly verified the certificate, as the "CN=thawte Primary Root CA" is actually in the certificate store by default [1]. The server sending this additional certificate in the chain does not impede security, but does increase compatibility with older clients, so the server admins are actually doing the right thing here. If you try to use gnutls-cli (GnuTLS) or Firefox (NSS) to connect to the server, it will not fail the connection, and properly indicate that the certificate is valid. I can confirm that this is indeed fixed on Stretch. Regards, Christian [1] openssl x509 -in /etc/ssl/certs/thawte_Primary_Root_CA.pem -noout -text
signature.asc
Description: OpenPGP digital signature
