AddTrust Root Certificate Obsolete Causes Crashes on OpenSSL and GnuTLS Systems

30-year root certificate expired on May 20 AddTrustWhich applied for the formation of a cross-signature (cross-signed) in certificates of one of the largest certification centers Sectigo (Comodo). Cross-signing allowed for compatibility with legacy devices that did not have the new USERTRust root certificate added to their root certificate store.

Theoretically, the termination of the AddTrust root certificate should only lead to a violation of compatibility with legacy systems (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, etc.), since the second root certificate used in cross-signing remains relevant and modern browsers take it into account when checking the chain of trust. On practice showed up issues with cross-signature verification in non-browser TLS clients, including those based on OpenSSL 1.0.x and GnuTLS. A secure connection fails with a certificate expiration error if the server uses a Sectigo certificate that is chained to an AddTrust root certificate.

If users of modern browsers did not notice the aging of the AddTrust root certificate when processing cross-signed Sectigo certificates, then problems began to surface in various third-party applications and server handlers, which led to breaking work many infrastructures that use encrypted communication channels for interaction between components.

For example, there were problems with access to some package repositories in Debian and Ubuntu (apt began to give a certificate verification error), access from scripts using the "curl" and "wget" utilities began to fail, errors were observed when using Git, violated Roku streaming platform work, handlers stopped being called Stripe и DataDog, started crashes occur in Heroku apps, stopped connect OpenLDAP clients, problems with sending mail to SMTPS and SMTP servers with STARTTLS are fixed. In addition, there are problems in various Ruby, PHP and Python scripts that use the http client module. From browsers problem affects Epiphany which stopped loading ad blocking lists.

Go programs are not affected by the problem, as Go offers own implementation TLS.

Was supposedthat the issue affects older distribution releases (including Debian 9, Ubuntu 16.04, RHEL 6/7) that use problematic OpenSSL branches, but the problem appeared also when running the APT package manager on current releases of Debian 10 and Ubuntu 18.04/20.04, since APT uses the GnuTLS library. The crux of the problem is that many TLS/SSL libraries parse a certificate as a linear chain, while in accordance with RFC 4158 a certificate can represent a directed distributed cyclic graph with several trust anchors that need to be taken into account. About this flaw in OpenSSL and GnuTLS было is known for many years. In OpenSSL, the problem was fixed in the 1.1.1 branch, and in GnuTLS remains uncorrected.

As a workaround to fix the failure, it is suggested to remove the "AddTrust External CA Root" certificate from the system store (for example, remove it from /etc/ca-certificates.conf and /etc/ssl/certs, and then run "update-ca-certificates -f -v"), after which OpenSSL starts to process normally cross-signed certificates with its participation. When using the APT package manager, at your own risk, you can disable certificate verification for individual requests (for example, "apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false").

To block the problem in Fedora и RHEL it is proposed to add the AddTrust certificate to the black list:

trust dump —filter «pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract

But this method does not work for GnuTLS (for example, it keeps getting a certificate verification error when running the wget utility).

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

Addendum: The problem is also is manifested in LibreSSL.

Source: opennet.ru