app-misc/ca-certificates contains some certificates which have expired since last year. Simple check for expired CA certificates: (not guaranteed to be complete) now=$(date +'%s'); for file in /usr/share/ca-certificates/*/*; do datestring=$(openssl x509 -in $file -inform PEM -noout -enddate | sed -e 's/notAfter=//'); expires=$(date +'%s' --date="$datestring"); if [[ "$now" -gt "$expires" ]]; then echo -n "$datestring"; echo -ne '\t'; echo "$file"; fi; done As of now this yields the following list of expired certificates: May 30 10:48:38 2020 GMT /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt Jul 6 23:59:59 2019 GMT /usr/share/ca-certificates/mozilla/Certplus_Class_2_Primary_CA.crt Jul 9 23:59:00 2019 GMT /usr/share/ca-certificates/mozilla/Deutsche_Telekom_Root_CA_2.crt Mar 25 11:03:10 2020 GMT /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_Root_CA_-_G2.crt Usually I would not expect that to cause issues but it seems that some applications may get a (false positive?) verification error when CAs preform cross-signing and the first match yields an expired certificate (the other CA can still be fine but apparently is not being checked/trusted in that case). In case of sci-misc/boinc (ships with its own CA bundle but Gentoo ebuild replaces it by a symlink to the system's CA bundle), yesterday's expiration of the AddTrust root CA (somehow associated with Comodo) has broken communication with several servers. Since the CA appears to have been popular I don't think this issue will be limited to just BOINC but may affect other applications as well: https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020 I don't have sufficient knowledge about cryptography to determine if the CA just simply broke itself or if something is wrong on Gentoo's/ca-certificate's side. However, from a user's perspective I can tell that OpenSSL currently refuses connections to servers with an expired AddTrust root CA even if the chain of trust is cross-signed with a non-expired Comodo CA. In the case of AddTrust deletion of the expired CA file from /usr/share/ca-certificates solves the issue. From my personal point of view there should be no need to keep expired certificates around so I would assume those could simply be removed to solve any possible issue but maybe I am missing some use-case. Original chain of trust: (openssl s_client -connect bwsrv1.bakerlab.org:443) depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify error:num=10:certificate has expired notAfter=May 30 10:48:38 2020 GMT --- Certificate chain 0 s:/C=US/postalCode=98195/ST=WA/L=Seattle/street=4545 15th Ave NE/O=University of Washington/OU=UW-IT/CN=*.bakerlab.org i:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA 1 s:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root After a simple deletion of expired AddTrust CA and update-ca-certificates -f: depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority verify return:1 depth=1 C = US, ST = MI, L = Ann Arbor, O = Internet2, OU = InCommon, CN = InCommon RSA Server CA verify return:1 depth=0 C = US, postalCode = 98195, ST = WA, L = Seattle, street = 4545 15th Ave NE, O = University of Washington, OU = UW-IT, CN = *.bakerlab.org verify return:1 --- Certificate chain 0 s:/C=US/postalCode=98195/ST=WA/L=Seattle/street=4545 15th Ave NE/O=University of Washington/OU=UW-IT/CN=*.bakerlab.org i:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA 1 s:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root Reproducible: Always
Created attachment 642868 [details] emerge --info output
The breakage you are experiencing is around this certificate: https://crt.sh/?id=1 There is a writeup here: https://www.agwa.name/blog/post/fixing_the_addtrust_root_expiration TL;DR buggy clients fail to use the cross-signed cert that's valid. Gentoo ca-certificates tries to stay close to upstream, in this case Debian+NSS bundled together, and we'd like to keep it that way I feel. I do see an upstream discussion about the removal, so hopefully there is progress shortly.
Debian has just published a new ca-certificates package which removes the AddTrust cert (+obsolete symantec certs), so re-syncing with upstream should do this.
hanno: I think Debian screwed up their release. It's NOT on https://packages.debian.org/source/sid/ca-certificates yet (still shows 20190110). Some of the Debian mirrors DO have ca-certificates_20200601.tar.xz that I'm going to see about using anyway after verifying content.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=617b767f5022f81117e028e258d8b0e008594a31 commit 617b767f5022f81117e028e258d8b0e008594a31 Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2020-06-02 16:48:35 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2020-06-02 17:13:18 +0000 app-misc/ca-certificates: bump Bump to unreleased latest Debian sources which haven't been formally announced but are available via the Debian git systems. Removes expired AddTrust External CA root causing problems with GnuTLS & OpenSSL 1.0. Closes: https://bugs.gentoo.org/726412 Bug: https://bugs.gentoo.org/show_bug.cgi?id=726650 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> app-misc/ca-certificates/Manifest | 1 + .../ca-certificates-20200601.3.53.ebuild | 192 +++++++++++++++++++++ 2 files changed, 193 insertions(+)
Seems that this upgrade of ca-certificates broke some apps for me. Notably I noticed some Steam games having trouble connecting to their servers. I don't know which certificate is to blame for this (or how to check it).
(In reply to Tomasz Golinski from comment #6) > Seems that this upgrade of ca-certificates broke some apps for me. Notably I > noticed some Steam games having trouble connecting to their servers. I don't > know which certificate is to blame for this (or how to check it). Can you open a new bug please? In terms of trying to trace it, forcing Steam to go via a MITMproxy and tcpdump/https dump of what's going on should be enough. Would need to compare behavior with old vs new ca-certificates present. At the very least, finding out what it's trying to connect to (hostname/IP, port, SNI or other TLS headers)
