Get best of the week

Sectigo's AddTrust root certificate expired on May 30, 2020, which caused problems in OpenSSL 1.0.x and GnuTLS clients



The Sectigo Certification Authority (Comodo) warned users in advance of the expiration of the AddTrust root certificate , which was used for cross-signing, to ensure compatibility with legacy devices that do not have a new USERTrust root certificate in storage.

AddTrust expired on May 20, 2020 at 10:48:38 UTC. Unfortunately, problems arose not only in outdated browsers, but also in non-browser clients based on OpenSSL 1.0.x, LibreSSL and GnuTLS . For example, in Roku set-top boxes (see the answer in tech support dated 05/30/2020), Heroku , in Fortinet, Chargify applications, on the .NET Core 2.0 platform under Linux and many others.

It was assumed that the problem would affect only legacy systems (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, etc.), as modern browsers can use the second USERTRust root certificate, as shown in the diagram.


Certificate Chain

But on May 30, 2020, in fact, crashes began in hundreds of web services that used the free OpenSSL 1.0.x and GnuTLS libraries. A secure connection has ceased to be established with a certificate obsolescence error.

The corresponding ticket in the OpenSSL bug tracker (username and password: guest) was closed on February 25, 2020 only for version OpenSSL 1.1.0.

Why an error occurs


When a client connects, the TLS server sends it its certificate. The client must build a chain of certificates from the server certificate to the root certificate that the client trusts. To help the client build this chain, the server sends an additional one or more intermediate certificates along with its own.



For example, a website sends the following two certificates:

1.
Subject = * .habr.com
Publisher = Sectigo ECC Domain Validation Secure Server CA
Start of action = Saturday, May 30, 2020 3:00:00
Expiration Date = Friday, December 3, 2021 2:59:59

2.
Subject = Sectigo ECC Domain Validation Secure Server CA
Publisher = USERTrust ECC Certification Authority
Start of action = Friday, November 2, 2018 3:00:00
End of action = Wednesday, January 1, 2031 2:59:59

The first certificate belongs to the server and is issued by the Sectigo certificate authority. The second is issued by the USERTrust ECC certification authority and is the root certificate. These two certificates form a complete chain to a trusted root.

However, the USERTrust certification authority is a relatively new root. It was created in 2010, and it took many years for all clients to trust it. Last year, there were reports that individual customers do not trust this root. Therefore, some servers send an additional USERTrust ECC Certification Authority intermediate certificate issued by AddTrust External CA Root to the client. This certificate was generated in 2000, and it was his certificate that expired on May 30, 2020.

For competent certificate validators, including modern browsers, this did not cause problems, because they themselves can build a chain of trust before USERTrust, but there was a problem with clients who use OpenSSL 1.0.x or GnuTLS. Even if these clients trust the USERTrust root certification authority and want to build a chain to it, they still end up with a chain to AddTrust External CA Root, which causes certificate verification to fail.

Sectigo has provided an alternative cross-signed intermediate certificate AAA Certificate Services , which will be valid until 2028.

Checking Your Services


Server handler and client application operators are encouraged to check their certificate chain for an outdated AddTrust root certificate.

Essentially, you just need to remove AddTrust External CA Root from the trust chain.

For server operators there is a service What's My Chain Cert? , which performs this check and helps generate a new trust chain with all the necessary intermediate certificates. It is not necessary to include a root certificate in this chain, since all clients already have it in the store. In addition, including it in the chain is simply inefficient due to the increase in the size of the SSL handshake.

Client application operators are advised to upgrade to the latest TLS library. If this is not possible, you must remove the AddTrust External CA Root certificate from your storage. If it is not in the repository, then the correct chain of trust is built for the new root certificate USERTrust RSA Certification Authority, so that the TLS check passes correctly.

To remove AddTrust External CA Root you need to do the following :

  1. Edit /etc/ca-certificates.confand commentmozilla/AddTrust_External_Root.crt
  2. Run update-ca-certificates

To fix the problem, Fedora and RHEL suggest adding the AddTrust certificate to the blacklist:

 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.

See also:
“ The problem with Sectigo certificates after May 30, 2020 and the method of solution ” on the Habr corporate blog




PKI solutions for your enterprise. Contact us +7 (499) 678 2210, sales-ru@globalsign.com.

More articles:


All Articles