Debian Bug report logs - #812708
Alternative chain verification failure after 1024b root CAs removal

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Leszek Dubiel <leszek.dubiel@dubielvitrum.pl>

To: submit@bugs.debian.org

Subject: ca-certificates: on fresh debian install typical ssl session fails on Thawte certificates

Date: Tue, 26 Jan 2016 00:53:59 +0100

Subject: ca-certificates: on fresh debian install typical ssl session fails on Thawte certificates
Package: ca-certificates
Version: 20141019+deb8u1
Severity: normal

Dear Maintainer,

After updating from Debian Jessie 8.2 to 8.3 some certificates got broken. When I run command:

	echo GET | openssl s_client -connectwww.ecod.pl:443  2>&1 | head -n3

the result is:

	depth=2 C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA
	verify error:num=20:unable to get local issuer certificate
	verify return:0

I have done fresh Debian Jessie installation. Certificate verification also fails.

To solve the problem I have had to copy /etc/ssl/certs and /usr/share/ca-certificates directories from Ubuntu.



-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-586
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  openssl                1.0.1k-3+deb8u2

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information:
  ca-certificates/new_crts:
  ca-certificates/trust_new_crts: yes
  ca-certificates/title:
  ca-certificates/enable_crts: mozilla/ACCVRAIZ1.crt, mozilla/ACEDICOM_Root.crt, mozilla/AC_Raíz_Certicámara_S.A..crt, mozilla/Actalis_Authentication_Root_CA.crt, mozilla/AddTrust_External_Root.crt, mozilla/AddTrust_Low-Value_Services_Root.crt, mozilla/AddTrust_Public_Services_Root.crt, mozilla/AddTrust_Qualified_Certificates_Root.crt, mozilla/AffirmTrust_Commercial.crt, mozilla/AffirmTrust_Networking.crt, mozilla/AffirmTrust_Premium.crt, mozilla/AffirmTrust_Premium_ECC.crt, mozilla/ApplicationCA_-_Japanese_Government.crt, mozilla/Atos_TrustedRoot_2011.crt, 
mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt, 
mozilla/Baltimore_CyberTrust_Root.crt, mozilla/Buypass_Class_2_CA_1.crt, 
mozilla/Buypass_Class_2_Root_CA.crt, 
mozilla/Buypass_Class_3_Root_CA.crt, mozilla/CA_Disig.crt, 
mozilla/CA_Disig_Root_R1.crt, mozilla/CA_Disig_Root_R2.crt, 
mozilla/Camerfirma_Chambers_of_Commerce_Root.crt, 
mozilla/Camerfirma_Global_Chambersign_Root.crt, 
mozilla/CA_WoSign_ECC_Root.crt, 
mozilla/Certification_Authority_of_WoSign_G2.crt, mozilla/Certigna.crt, 
mozilla/Certinomis_-_Autorité_Racine.crt, mozilla/Certinomis_-_Root_CA.crt, 
mozilla/Certplus_Class_2_Primary_CA.crt, mozilla/certSIGN_ROOT_CA.crt, 
mozilla/Certum_Root_CA.crt, mozilla/Certum_Trusted_Network_CA.crt, 
mozilla/CFCA_EV_ROOT.crt, mozilla/Chambers_of_Commerce_Root_-_2008.crt, 
mozilla/China_Internet_Network_Information_Center_EV_Certificates_Root.crt, 
mozilla/CNNIC_ROOT.crt, mozilla/Comodo_AAA_Services_root.crt, 
mozilla/COMODO_Certification_Authority.crt, 
mozilla/COMODO_ECC_Certification_Authority.crt, 
mozilla/COMODO_RSA_Certification_Authority.crt, 
mozilla/Comodo_Secure_Services_root.crt, 
mozilla/Comodo_Trusted_Services_root.crt, mozilla/ComSign_CA.crt, 
mozilla/Cybertrust_Global_Root.crt, 
mozilla/Deutsche_Telekom_Root_CA_2.crt, 
mozilla/DigiCert_Assured_ID_Root_CA.crt, 
mozilla/DigiCert_Assured_ID_Root_G2.crt, 
mozilla/DigiCert_Assured_ID_Root_G3.crt, 
mozilla/DigiCert_Global_Root_CA.crt, 
mozilla/DigiCert_Global_Root_G2.crt, 
mozilla/DigiCert_Global_Root_G3.crt, 
mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, 
mozilla/DigiCert_Trusted_Root_G4.crt, mozilla/DST_ACES_CA_X6.crt, 
mozilla/DST_Root_CA_X3.crt, mozilla/D-TRUST_Root_Class_3_CA_2_2009.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_EV_2009.crt, 
mozilla/EBG_Elektronik_Sertifika_Hizmet_Sağlayıcısı.crt, 
mozilla/EC-ACC.crt, mozilla/EE_Certification_Centre_Root_CA.crt, 
mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt, 
mozilla/Entrust_Root_Certification_Authority.crt, 
mozilla/Entrust_Root_Certification_Authority_-_EC1.crt, mozilla/Entrust_Root_Certification_Authority_-_G2.crt, mozilla/ePKI_Root_Certification_Authority.crt, 
mozilla/Equifax_Secure_CA.crt, 
mozilla/Equifax_Secure_eBusiness_CA_1.crt, 
mozilla/Equifax_Secure_Global_eBusiness_CA.crt, 
mozilla/E-Tugra_Certification_Authority.crt, 
mozilla/GeoTrust_Global_CA_2.crt, mozilla/GeoTrust_Global_CA.crt, 
mozilla/GeoTrust_Primary_Certification_Authority.crt, 
mozilla/GeoTrust_Primary_Certification_Authority_-_G2.crt, mozilla/GeoTrust_Primary_Certification_Authority_-_G3.crt, mozilla/GeoTrust_Universal_CA_2.crt, 
mozilla/GeoTrust_Universal_CA.crt, mozilla/Global_Chambersign_Root_-_2008.crt, mozilla/GlobalSign_ECC_Root_CA_-_R4.crt, mozilla/GlobalSign_ECC_Root_CA_-_R5.crt, mozilla/GlobalSign_Root_CA.crt, mozilla/GlobalSign_Root_CA_-_R2.crt, mozilla/GlobalSign_Root_CA_-_R3.crt, mozilla/Go_Daddy_Class_2_CA.crt, 
mozilla/Go_Daddy_Root_Certificate_Authority_-_G2.crt, 
mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt, 
mozilla/Hongkong_Post_Root_CA_1.crt, 
mozilla/IdenTrust_Commercial_Root_CA_1.crt, 
mozilla/IdenTrust_Public_Sector_Root_CA_1.crt, mozilla/IGC_A.crt, 
mozilla/Izenpe.com.crt, mozilla/Juur-SK.crt, 
mozilla/Microsec_e-Szigno_Root_CA_2009.crt, 
mozilla/Microsec_e-Szigno_Root_CA.crt, mozilla/NetLock_Arany_=Class_Gold=_Főtanúsítvány.crt, mozilla/NetLock_Business_=Class_B=_Root.crt, mozilla/NetLock_Express_=Class_C=_Root.crt, mozilla/NetLock_Notary_=Class_A=_Root.crt, mozilla/NetLock_Qualified_=Class_QA=_Root.crt, mozilla/Network_Solutions_Certificate_Authority.crt, 
mozilla/OISTE_WISeKey_Global_Root_GA_CA.crt, 
mozilla/OISTE_WISeKey_Global_Root_GB_CA.crt, mozilla/PSCProcert.crt, 
mozilla/QuoVadis_Root_CA_1_G3.crt, mozilla/QuoVadis_Root_CA_2.crt, 
mozilla/QuoVadis_Root_CA_2_G3.crt, mozilla/QuoVadis_Root_CA_3.crt, 
mozilla/QuoVadis_Root_CA_3_G3.crt, mozilla/QuoVadis_Root_CA.crt, 
mozilla/Root_CA_Generalitat_Valenciana.crt, 
mozilla/RSA_Security_2048_v3.crt, mozilla/Secure_Global_CA.crt, 
mozilla/SecureSign_RootCA11.crt, mozilla/SecureTrust_CA.crt, 
mozilla/Security_Communication_EV_RootCA1.crt, 
mozilla/Security_Communication_RootCA2.crt, 
mozilla/Security_Communication_Root_CA.crt, 
mozilla/Sonera_Class_1_Root_CA.crt, mozilla/Sonera_Class_2_Root_CA.crt, 
mozilla/Staat_der_Nederlanden_EV_Root_CA.crt, 
mozilla/Staat_der_Nederlanden_Root_CA.crt, 
mozilla/Staat_der_Nederlanden_Root_CA_-_G2.crt, mozilla/Staat_der_Nederlanden_Root_CA_-_G3.crt, mozilla/Starfield_Class_2_CA.crt, 
mozilla/Starfield_Root_Certificate_Authority_-_G2.crt, mozilla/Starfield_Services_Root_Certificate_Authority_-_G2.crt, mozilla/StartCom_Certification_Authority_2.crt, 
mozilla/StartCom_Certification_Authority.crt, 
mozilla/StartCom_Certification_Authority_G2.crt, 
mozilla/S-TRUST_Authentication_and_Encryption_Root_CA_2005_PN.crt, 
mozilla/S-TRUST_Universal_Root_CA.crt, mozilla/Swisscom_Root_CA_1.crt, 
mozilla/Swisscom_Root_CA_2.crt, mozilla/Swisscom_Root_EV_CA_2.crt, 
mozilla/SwissSign_Gold_CA_-_G2.crt, mozilla/SwissSign_Platinum_CA_-_G2.crt, mozilla/SwissSign_Silver_CA_-_G2.crt, mozilla/Taiwan_GRCA.crt, 
mozilla/TC_TrustCenter_Class_3_CA_II.crt, 
mozilla/TeliaSonera_Root_CA_v1.crt, mozilla/thawte_Primary_Root_CA.crt, 
mozilla/thawte_Primary_Root_CA_-_G2.crt, mozilla/thawte_Primary_Root_CA_-_G3.crt, mozilla/Trustis_FPS_Root_CA.crt, 
mozilla/T-TeleSec_GlobalRoot_Class_2.crt, 
mozilla/T-TeleSec_GlobalRoot_Class_3.crt, 
mozilla/TÜBİTAK_UEKAE_Kök_Sertifika_Hizmet_Sağlayıcısı_-_Sürüm_3.crt, 
mozilla/TURKTRUST_Certificate_Services_Provider_Root_2007.crt, 
mozilla/TÜRKTRUST_Elektronik_Sertifika_Hizmet_Sağlayıcısı_H5.crt, 
mozilla/TÜRKTRUST_Elektronik_Sertifika_Hizmet_Sağlayıcısı_H6.crt, 
mozilla/TWCA_Global_Root_CA.crt, 
mozilla/TWCA_Root_Certification_Authority.crt, 
mozilla/USERTrust_ECC_Certification_Authority.crt, 
mozilla/USERTrust_RSA_Certification_Authority.crt, 
mozilla/UTN_USERFirst_Email_Root_CA.crt, 
mozilla/UTN_USERFirst_Hardware_Root_CA.crt, 
mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt, 
mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.crt, mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.crt, 
mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.crt, mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.crt, 
mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_2.crt, 
mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt, 
mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.crt, mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.crt, 
mozilla/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.crt, mozilla/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.crt, mozilla/VeriSign_Universal_Root_Certification_Authority.crt, mozilla/Visa_eCommerce_Root.crt, mozilla/WellsSecure_Public_Root_Certificate_Authority.crt, mozilla/WoSign_China.crt, mozilla/WoSign.crt, mozilla/XRamp_Global_CA_Root.crt, spi-inc.org/spi-cacert-2008.crt

Message #10 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Yvan - Dugwood <yvan@dugwood.com>

To: 812708@bugs.debian.org

Subject: Same issue

Date: Tue, 26 Jan 2016 22:44:19 +0100

Before upgrading the package, if you run:
strace curl -O /dev/null -Iv https://www.ecod.pl
(I kept your url as a test)

=> stat("/etc/ssl/certs/98ec67f0.0", {st_mode=S_IFREG|0644, 
st_size=1155, ...}) = 0

ls -al /etc/ssl/certs/98ec67f0.0
lrwxrwxrwx 1 root root 28 avril 27  2015 /etc/ssl/certs/98ec67f0.0 -> 
Thawte_Premium_Server_CA.pem

ls -al /etc/ssl/certs/Thawte_Premium_Server_CA.pem
lrwxrwxrwx 1 root root 63 avril 29  2014 
/etc/ssl/certs/Thawte_Premium_Server_CA.pem -> 
/usr/share/ca-certificates/mozilla/Thawte_Premium_Server_CA.crt

But, after the upgrade:
stat("/etc/ssl/certs/98ec67f0.0", 0x7fff3c5501d0) = -1 ENOENT (No such 
file or directory)

Same file, but can't be found anymore.

I've already tried «sudo update-ca-certificates --fresh», with no luck, 
as there's no Thawte Premium CA anymore. The only way is to copy the 
file from an older release (see http://curl.haxx.se/docs/caextract.html, 
under «RSA-1024 removed»).

So far I don't know if the issue is the missing file or the fact that 
the certificate should be in another file, which is badly linked.

Best regards,
Yvan.

Message #15 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Christian Beer <christian.beer@aei.mpg.de>

To: 812708@bugs.debian.org

Subject: Re: ca-certificates: on fresh debian install typical ssl session fails on Thawte certificates

Date: Wed, 27 Jan 2016 13:47:13 +0100

Hi,

I can maybe shed some more light on this. The problem is that the
"Thawte Premium Server CA" was removed from the certificate store with
20141019+deb8u1. On Stretch this is not a problem because openssl is on
1.0.2 there. On Jessie we have 1.0.1 which can not verify cross signed
certificates as it seems.

I tested with a current Jessie and Stretch installation and it turns out
that openssl 1.0.2 verifies the "Thawte Primary Root CA" correctly
because it is in the certificate store. With openssl 1.0.1 this
verification fails because it looks for the (removed) "Thawte Premium
Server CA". I first thought it only affects servers that send both
chains but as Leszek writes this also affects him.

We publish the chain like this: servercert, thawte SSL CA - G2, Thawte
Primary Root CA, Thawte Premium Server CA

Looking at the Thawte website you can clearly see that the "Thawte
Premium Server CA" is still operational and should not be excluded from
certificate stores (https://www.thawte.com/roots/index.html). The
certificate is obviously still need for openssl 1.0.1

For reference here are the openssl bug reports that fix the alternate
chain problem in 1.0.2:
https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3637
https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3621

So I would like to see the "Thawte Premium Server CA" in the Debian
Jessie certificate store again very soon. This currently will disconnect
all Volunteers running BOINC from at least two big projects
(Einstein@home, WorldCommunityGrid) as soon as they update to
20141019+deb8u1. Another solution would be to update openssl to 1.0.2 on
Jessie but I doubt that this is easier than re-adding the certificate.

I have done more troubleshooting and can provide more evidence if needed.

Kind regards
Christian

Message #20 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org>

To: Christian Beer <christian.beer@aei.mpg.de>, 812708@bugs.debian.org

Subject: Re: Bug#812708: ca-certificates: on fresh debian install typical ssl session fails on Thawte certificates

Date: Wed, 27 Jan 2016 10:32:21 -0600

On 01/27/2016 06:47 AM, Christian Beer wrote:
> I tested with a current Jessie and Stretch installation and it turns out
> that openssl 1.0.2 verifies the "Thawte Primary Root CA" correctly
> because it is in the certificate store. With openssl 1.0.1 this
> verification fails because it looks for the (removed) "Thawte Premium
> Server CA". I first thought it only affects servers that send both
> chains but as Leszek writes this also affects him.

Thank you for the details!

> So I would like to see the "Thawte Premium Server CA" in the Debian
> Jessie certificate store again very soon.

Yep, sorry for the regression, but I appreciate the extra info - it 
helps solve some of my own troubleshooting.

-- 
Kind regards,
Michael

Message #29 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Peter Dahlberg <catdog2@tuxzone.org>

To: 812708@bugs.debian.org

Subject: Similar issue with "GTE CyberTrust Global Root"

Date: Thu, 28 Jan 2016 16:44:09 +0100

Hi,

There seems to be a similar looking issue because of the removed "GTE 
CyberTrust Global Root".

jessie:

$ openssl s_client -connect pictureis24-a.akamaihd.net: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=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net
   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
---

testing:

 % openssl s_client -connect pictureis24-a.akamaihd.net:443
CONNECTED(00000003)
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify return:1
depth=1 C = NL, L = Amsterdam, O = Verizon Enterprise Solutions, OU = 
Cybertrust, CN = Verizon Akamai SureServer CA G14-SHA2
verify return:1
depth=0 C = US, ST = MA, L = Cambridge, O = Akamai Technologies Inc., CN = 
a248.e.akamai.net
verify return:1
---
Certificate chain
 0 s:/C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net
   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
---

Kind regards,
Peter

Message #34 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Rich <forums@artfulrobot.uk>

To: 812708@bugs.debian.org

Subject: Also affected: Baltimore CyberTrust Root used by Mailchimp

Date: Fri, 5 Feb 2016 11:49:14 +0000

subject says it all.

Message #39 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org>

To: Rich <forums@artfulrobot.uk>, 812708@bugs.debian.org

Subject: Re: Bug#812708: Also affected: Baltimore CyberTrust Root used by Mailchimp

Date: Fri, 5 Feb 2016 09:40:53 -0600

On 02/05/2016 05:49 AM, Rich wrote:
> subject says it all.

Please provide a specific URL to test. The "Baltimore CyberTrust Root" 
CA may be a different issue, looking at several mozilla bugzilla 
tickets, but I can't tell without any detail.

Thanks, Michael

Message #44 received at 812708@bugs.debian.org (full text, mbox, reply):

From: nandhp <nandhp@gmail.com>

To: 812708@bugs.debian.org

Subject: Re: Similar issue with "GTE CyberTrust Global Root"

Date: Sun, 07 Feb 2016 12:22:53 -0600

I am having the same problem with apis.live.net:443. I am running Debian
stable with ca-certificates 20141019+deb8u1.

Thanks.
-nandhp

$ openssl s_client -connect apis.live.net: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=WA/L=Redmond/O=Microsoft Corporation/OU=Microsoft
Corporation/CN=storage.live.com
   i:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft
IT/CN=Microsoft IT SSL SHA2
 1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft
IT/CN=Microsoft IT SSL 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
---
Server certificate
[...]
subject=/C=US/ST=WA/L=Redmond/O=Microsoft Corporation/OU=Microsoft
Corporation/CN=storage.live.com
issuer=/C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/OU=Microsoft IT/CN=Microsoft IT SSL SHA2
---
No client certificate CA names sent
---
SSL handshake has read 6828 bytes and written 509 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-SHA384
    Session-ID: [...]
    Session-ID-ctx:
    Master-Key: [...]
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1454865834
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
^C

On Thu, 28 Jan 2016 16:44:09 +0100 Peter Dahlberg <catdog2@tuxzone.org>
wrote:
> Hi,
> 
> There seems to be a similar looking issue because of the removed "GTE 
> CyberTrust Global Root".
> 
> jessie:
> 
> $ openssl s_client -connect pictureis24-a.akamaihd.net: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=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net
>    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
> ---
> 
> testing:
> 
>  % openssl s_client -connect pictureis24-a.akamaihd.net:443
> CONNECTED(00000003)
> depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
> verify return:1
> depth=1 C = NL, L = Amsterdam, O = Verizon Enterprise Solutions, OU = 
> Cybertrust, CN = Verizon Akamai SureServer CA G14-SHA2
> verify return:1
> depth=0 C = US, ST = MA, L = Cambridge, O = Akamai Technologies Inc., CN = 
> a248.e.akamai.net
> verify return:1
> ---
> Certificate chain
>  0 s:/C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net
>    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
> ---
> 
> Kind regards,
> Peter
> 
> 
> 

Message #49 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Rich Lott - Artful Robot <forums@artfulrobot.uk>

To: Michael Shuler <michael@pbandjelly.org>, 812708@bugs.debian.org

Subject: Re: Bug#812708: Also affected: Baltimore CyberTrust Root used by Mailchimp

Date: Mon, 8 Feb 2016 10:17:53 +0000

Hi Michael,

Thanks for getting back. Good you did as I was wrong!

Here's what's failing under Debian Jessie:

echo GET | openssl s_client -CApath /etc/ssl/certs/ -connect 
us9.api.mailchimp.com:443  2>&1  | head -n5
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


I tracked this down to the following change in ca-certificates.conf:

Was:
mozilla/GTE_CyberTrust_Global_Root.crt

Is:
#!mozilla/GTE_CyberTrust_Global_Root.crt

By adding that certificate back in (from a local Ubuntu), adding it back 
to /etc/ca-certificates.conf and running update-ca-certificates, 
Mailchimp's API works again.

Hope this is useful, I have to admit I'm at the limit of my 
understanding on this!

Thanks,

Rich




On 05/02/16 15:40, Michael Shuler wrote:
> On 02/05/2016 05:49 AM, Rich wrote:
>> subject says it all.
>
> Please provide a specific URL to test. The "Baltimore CyberTrust Root" 
> CA may be a different issue, looking at several mozilla bugzilla 
> tickets, but I can't tell without any detail.
>
> Thanks, Michael

Message #54 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Miguel Jacq <mig@mig5.net>

To: 812708@bugs.debian.org

Subject: Re: Bug#812708: Also affected: Baltimore CyberTrust Root used by Mailchimp

Date: Thu, 11 Feb 2016 07:44:52 +1100

[Message part 1 (text/plain, inline)]

Confirming that I too had to re-add the Thawte_Premium_Server_CA.crt and GTE_CyberTrust_Global_Root.crt before I could make requests to Twilio and Mailchimp APIs (respectively) again on Debian 8.3.

[signature.asc (application/pgp-signature, inline)]

Message #59 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Tom Freudenberg <th.freudenberg@googlemail.com>

To: <812708@bugs.debian.org>

Subject: Also failed on binary and akamai servers

Date: Mon, 15 Feb 2016 18:26:23 +0100

[Message part 1 (text/plain, inline)]

As we got an issue while doing downloads of 

curl -L -O https://dl.bintray.com/4commerce-technologies-ag/meteor-universal/arm_dev_bundles/dev_bundle_Linux_armv7l_0.5.16.tar.gz 


that was happened too to the latest debian stable update

A fix was to install a previous package of ca-certificates by downloading from pool and manual replacement with dpkg.

Tom

P.S. Read more about that issue on :: https://github.com/4commerce-technologies-AG/meteor/issues/37

[Message part 2 (text/html, inline)]

Message #64 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Tony den Haan <tony@tuxick.net>

To: 812708@bugs.debian.org

Subject: works ok on testing

Date: Tue, 16 Feb 2016 18:22:12 +0100

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

on jessie:  (and ubuntu lts :)
Verify return code: 20 (unable to get local issuer certificate)

on testing:
Verify return code: 0 (ok)

Message #69 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org>

To: Tony den Haan <tony@tuxick.net>, 812708@bugs.debian.org

Subject: Re: Bug#812708: works ok on testing

Date: Thu, 25 Feb 2016 08:53:43 -0600

On 02/16/2016 11:22 AM, Tony den Haan wrote:
> openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
> 
> on jessie:  (and ubuntu lts :)
> Verify return code: 20 (unable to get local issuer certificate)
> 
> on testing:
> Verify return code: 0 (ok)
> 

This appears to be unrelated to this bug report and your command works
correctly on Jessie if given a CApath. I assume this is a behavioral
difference in openssl.

openssl s_client -CApath /etc/ssl/certs -connect
gmail-smtp-in.l.google.com:25 -starttls smtp
CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN =
mx.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
<...>
   Verify return code: 0 (ok)

Message #74 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org>

To: Tony den Haan <tony@tuxick.net>

Cc: 812708@bugs.debian.org

Subject: Re: Bug#812708: works ok on testing

Date: Thu, 25 Feb 2016 09:05:44 -0600

On 02/25/2016 08:58 AM, Tony den Haan wrote:
> That is the problem, it requires -CApath, while /etc/ssl/certs should be
> default. On testing it works ok without it.

Which is unrelated to the ca-certificates package - that's my point :)

Feel free to open a new bug report for the openssl package describing
your problem, although I would suggest that this behavior change between
openssl versions in stable and testing means that feature was fixed or
added between those versions. Regardless, this is not related to
ca-certificates in any way.

-- 
Kind regards,
Michael

Message #79 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Rémi Rampin <remirampin@gmail.com>

To: 812708@bugs.debian.org

Subject: Re: Bug#812708: works ok on testing

Date: Thu, 25 Feb 2016 12:54:43 -0500

I think you get the problem at this point, but I'm going to mention
that this prevents people from using the installer for the Anaconda
Python distribution. Neither curl nor openssl connects to
repo.continuum.io. Same CA: thawte_Primary_Root_CA.crt

https://github.com/ContinuumIO/anaconda-issues/issues/670.

This breaks automatic CI systems everywhere too.

Message #84 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Luca BRUNO <lucab@debian.org>

To: 812488@bugs.debian.org, "control@bugs.debian.org" <control@bugs.debian.org>, 812708@bugs.debian.org

Subject: Re: Bug#812488: Alternative chain verification failure after 1024b root CAs removal

Date: Fri, 26 Feb 2016 09:16:01 +0100

[Message part 1 (text/plain, inline)]

retitle 812488 Alternative chain verification failure after 1024b root CAs removal
severity 812488 grave
thanks

On Thu, 25 Feb 2016 09:14:19 -0600 Michael Shuler <michael@pbandjelly.org> wrote:

> On 02/22/2016 04:12 AM, Christian Beer wrote:
> > It seems that the openssl update is not happening soon. Can you please
> > include the 1024bit certificates again to solve this regression?
> 
> Yeah, I have a work in progress branch that re-includes the 1024-bit
> CAs. Ran back into #743339 on upgrade, so needs some additional testing..

After a jessie upgrade today, I got the same regression and spent some time
debugging it (before finding this report) and got to the same conclusion as 
other here: side effect of removing 1024b root CAs is that OpenSSL 1.0.1
fails to verify alternative chains (where a server-sent intermediate CA is
a locally trusted root one).

I'm re-titling an raising the severity here, hoping it will help other people
noticing the regression in the meanwhile.

Cheers, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.    | lucab (AT) debian.org
`. `'`                          | GPG: 0xBB1A3A854F3BBEBF
  `-     http://www.debian.org  | Debian GNU/Linux Developer

[signature.asc (application/pgp-signature, inline)]

Message #93 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Christian Beer <christian.beer@aei.mpg.de>

To: 812488@bugs.debian.org, 812708@bugs.debian.org

Subject: Ubuntu 14.04 also affected

Date: Tue, 1 Mar 2016 10:00:44 +0100

The removal of the 1024bit certificates just hit Ubuntu 14.04 and
because they use openssl 1.0.1f they are also affected. I filed a bug
report there:
https://bugs.launchpad.net/debian/+source/ca-certificates/+bug/1551615

Regards
Christian

Message #104 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Andreas Sewe <andreas.sewe@codetrails.com>

To: 812708@bugs.debian.org

Subject: Re: ca-certificates: on fresh debian install typical ssl session fails on Thawte certificates

Date: Thu, 19 May 2016 13:31:56 +0200

FYI, removal of the "Thawte Premium Server CA" causes problems not only
with openssl, but also when Java verifies certificates (e.g., when
installing signed plugins in the Eclipse IDE).

Here's the output of jarsigner:

> jarsigner -verify -certs -verbose ./eclipse/plugins/com.codetrails.aether_1.14.0.v20160518-2203-b207.jar
...
>       [entry was signed on 5/19/16 12:08 AM]
>       X.509, CN=Codetrails GmbH, OU=IT Department, O=Codetrails GmbH, L=Darmstadt, ST=Hessen, C=DE
>       [certificate is valid from 3/1/16 1:00 AM to 5/1/17 1:59 AM]
>       X.509, CN=thawte SHA256 Code Signing CA, O="thawte, Inc.", C=US
>       [certificate is valid from 12/10/13 1:00 AM to 12/10/23 12:59 AM]
>       X.509, CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US
>       [certificate is valid from 11/17/06 1:00 AM to 12/31/20 12:59 AM]
>       X.509, EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
>       [certificate is valid from 8/1/96 2:00 AM to 1/2/21 12:59 AM]
>       [CertPath not validated: Path does not chain with any of the trust anchors]

With the keystore Oracle ships with Java 1.8.0_91 this verifies fine:

> jarsigner -keystore cacerts.original -verify -certs -verbose ./eclipse/plugins/com.codetrails.aether_1.14.0.v20160518-2203-b207.jar
...
>       [entry was signed on 5/19/16 12:08 AM]
>       X.509, CN=Codetrails GmbH, OU=IT Department, O=Codetrails GmbH, L=Darmstadt, ST=Hessen, C=DE
>       [certificate is valid from 3/1/16 1:00 AM to 5/1/17 1:59 AM]
>       X.509, CN=thawte SHA256 Code Signing CA, O="thawte, Inc.", C=US
>       [certificate is valid from 12/10/13 1:00 AM to 12/10/23 12:59 AM]
>       X.509, CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US
>       [certificate is valid from 11/17/06 1:00 AM to 12/31/20 12:59 AM]
>       X.509, EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA (thawtepremiumserverca)
>       [certificate is valid from 8/1/96 2:00 AM to 1/2/21 12:59 AM]

Note, however, that it doesn't find the "thawte Primary Root CA"
*intermediate* certificate in its keystore, as no alias (like for
"(thawtepremiumserverca)") is shown.

However, the keystore shipped with Debian 8.4 *does* contain that
intermediate certificate:

> keytool -list -alias debian:thawte_primary_root_ca.pem -v -keystore /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/cacerts
...
> Alias name: debian:thawte_primary_root_ca.pem
> Creation date: Apr 6, 2016
> Entry type: trustedCertEntry
> 
> Owner: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US
> Issuer: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US
> Serial number: 344ed55720d5edec49f42fce37db2b6d

If this were found by jarsigner, then everything would be fine; that the
root certificate is not trusted is immaterial, as an intermediate
certificate already is. But unfortunately that's not the case. :-(

Hope that helps.

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

Message #109 received at 812708@bugs.debian.org (full text, mbox, reply):

From: Christian Beer <christian.beer@aei.mpg.de>

To: Andreas Sewe <andreas.sewe@codetrails.com>, 812708@bugs.debian.org

Subject: Re: Bug#812708: ca-certificates: on fresh debian install typical ssl session fails on Thawte certificates

Date: Thu, 19 May 2016 15:33:42 +0200

On 19.05.2016 14:05, Andreas Sewe wrote:
> FYI, removal of the "Thawte Premium Server CA" causes problems not only
> with openssl, but also when Java verifies certificates (e.g., when
> installing signed plugins in the Eclipse IDE).

I think this is a separate issue with jarsigner not the ca-certificates
package.

> Note, however, that it doesn't find the "thawte Primary Root CA"
> *intermediate* certificate in its keystore, as no alias (like for
> "(thawtepremiumserverca)") is shown.
>
> However, the keystore shipped with Debian 8.4 *does* contain that
> intermediate certificate:

I think the tool can't find the "thawte Premium Server CA" certificate
(which was removed from ca-certificates) which is the old Root
certificate. But of course the "Thawte Primary Root CA" is still part of
ca-certificates because it is the "new" certificate. Both root certs are
eligible to certify your code signing intermediate certificate. You only
need one of the two certificates to be in the certificate store to
verify the intermediate, yet jarsigner wants to have both. This sounds
more like a problem with jarsigner which can not recognize alternative
certification chains. Much like the problem openssl has in the current
version in stable.

Regards
Christian

Message #110 received at 812488-done@bugs.debian.org (full text, mbox, reply):

From: Jonathan Wiltshire <jmw@debian.org>

To: Rosario Maddox <bugs@rcdrun.com>, 812488-done@bugs.debian.org

Subject: Re: Bug#812488: libsms-send-perl: After upgrade: Can't send SMS: 500 Can't connect to api.twilio.com:443 (certificate verify failed)

Date: Mon, 27 Jun 2016 14:51:17 +0200

[Message part 1 (text/plain, inline)]

Control: reassign -1 openssl
Control: fixed -1 1.0.1t-1+deb8u1

Hi,

On Sun, Jan 24, 2016 at 12:32:39PM +0100, Rosario Maddox wrote:
> Package: libsms-send-perl
> Version: 1.06-2
> Severity: important

This is really an issue in openssl, and has been resolved since May.
Reassigning, closing, and setting versions.

-- 
Jonathan Wiltshire                                      jmw@debian.org
Debian Developer                         http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.