The deprecation of the AddTrust root certificate has led to failures in systems with OpenSSL and GnuTLS.

On May 30, the 20-year validity period of the root certificate expired. AddTrust, which IRC was used for generating a cross-signature in the certificates of one of the largest certificate authorities, Sectigo (Comodo). The cross-signature allowed for compatibility with outdated devices that had not included the new root certificate USERTrust in their root certificate storage.

Theoretically, the expiration of the AddTrust root certificate should have led to only a loss of compatibility with outdated systems (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, etc.), since the second root certificate used in the cross-signature remains valid and modern browsers recognize it when checking the trust chain. In practice, issues were discovered with validating the cross-signature in non-browser TLS clients, including those based on OpenSSL 1.0.x and GnuTLS. A secure connection failed to establish, displaying an error about the certificate's obsolescence if the server uses a Sectigo certificate linked by trust chain to the AddTrust root certificate.

While users of modern browsers did not notice the obsolescence of the AddTrust root certificate when processing cross-signed Sectigo certificates, various third-party applications and server processors began experiencing issues, leading to issues the operation of many infrastructures using encrypted communication channels for interaction between components.

For example, there were issues access issues to some package repositories in Debian and Ubuntu (apt began displaying certificate validation errors), script calls using 'curl' and 'wget' started failing, and errors were observed when using Git, the operation of the Roku streaming platform was disrupted, handlers stopped being called, Stripe and DataDogcrashes began to occur in Heroku applications, clients could not connect to OpenLDAP, problems were fixed with sending emails to SMTPS and SMTP servers with STARTTLS. Additionally, issues were observed in various Ruby, PHP, and Python scripts that use the HTTP client module. Among browsers, the problem affected Epiphany, which stopped loading ad-blocking lists. Programs written in Go are not affected by this issue, as Go offers affects TLS.

It was anticipated a proprietary implementation and ignored the warning.

This led to complications in various services., which affects older releases of distributions (including Debian 9, Ubuntu 16.04, RHEL 6/7) that use problematic OpenSSL branches, but the issue also manifested when using the APT package manager in the current releases of Debian 10 and Ubuntu 18.04/20.04, as APT relies on the GnuTLS library. The crux of the problem is that many TLS/SSL libraries parse the certificate as a linear chain, while according to RFC 4158, a certificate can represent a directed distributed cyclic graph with multiple anchors of trust that need to be considered. This shortcoming in OpenSSL and GnuTLS it was it is known has been around for many years. In OpenSSL, the issue was resolved in version 1.1.1, while in GnuTLS remains it remains unaddressed.

. As a workaround to prevent crashes, it is suggested to remove the certificate "AddTrust External CA Root" from the system store (for example, delete from /etc/ca-certificates.conf and /etc/ssl/certs, then run "update-ca-certificates -f -v"), after which OpenSSL will begin to handle cross-signed certificates involving it correctly. When using the APT package manager, users can disable certificate verification at their own risk for individual requests (for example, "apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false").

To block the problem in Alpine and SUSE/openSUSE , it is recommended to blacklist the AddTrust certificate:

trust dump —filter "pkcs11:id=;type=cert"
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract

However, this method doesn't work for GnuTLS (for instance, the certificate verification error continues to be issued when running wget).

On the server side, it is possible to change the order of certificates in the trust chain sent from the server to the client (if the certificate associated with "AddTrust External CA Root" is removed from the list, then the client verification will succeed). To check and generate a new trust chain, the service whatsmychaincert.com. Sectigo has also provided an alternative cross-signed intermediate certificate "AAA Certificate Services", which will be valid until 2028 and will allow compatibility with older OS versions.

Addition: The issue also manifests exists in LibreSSL.

Source: opennet.ru