ADDTrust External Root Expiration May 2020

ADDTrust External CA Root Expiration in 2020

More Information:

https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020

https://www.cmu.edu/iso/service/cert-auth/addtrust.html

Summary:

Sectigo's legacy AddTrust External CA Root certificate expires on May 30, 2020. Modern clients should largely be unaffected. However, a compilation of affected users is listed below.

Devices that received security updates after mid 2015 should have the modern USERTrust RSA Certification Authority root certificate (valid until Jan 2038) in their operating system or browser truststores and should be largely unaffected.

Legacy devices that have not received updates to support newer roots will also likely be missing other essential security updates and support for standards required by the modern Internet. We strongly encourage decommissioning these devices if their software cannot be upgraded. Non-upgraded, legacy devices should never be exposed to the Internet and special mitigations should be applied to isolate them from neighbor systems.

Additional Impacts:

Client software based on OpenSSL prior to version 1.1.1 appears to have broken certificate path validation logic and will require workarounds
OpenLDAP clients on some platforms appear to have broken certificate path validation logic and will require workarounds
Clients configured to explicitly trust the AddTrust root may need client reconfiguration to either:
- rely on operating system or vendor managed truststores or
- explicitly trust the USERTrust RSA Certification Authority root or the alternative legacy AAA Certificate Services root (valid until Dec 2028).

Who is affected?

Anyone who Administers:

Legacy clients that have not received security updates since before mid 2015 and connect to Secure Sockets Layer (SSL) or Transport Layer Security (TLS) encrypted services such as web and email
OpenSSL based client software
Linux or macOS OpenLDAP clients that connect to ldap.berkeley.edu

Clients configured to explicitly trust the AddTrust External CA Root instead of relying on an operating system or vendor managed truststore. For example:

Java applications that do not use the default truststore
Lightweight Directory Access Protocol over SSL (LDAPS)
Anyone who administers SSL or TLS encrypted services connected to by the above clients.

Details:

The majority of modern clients are unaffected by this expiry, browsers simply choose a chain directly to the SHA-2 root (COMODO or USERTrust) and the cross-cert back to AddTrust is simply ignored. When the AddTrust External CA Root expires, Trust Chain A will no longer be used by clients, instead they will chain up via Trust Chain B.

Certificate path validation is done client-side from leaf to root. Modern clients that receive Trust Chain A with the cross signed intermediate (see below) from servers should ignore it and instead follow Trust Chain B. This applies even after the root of Trust Chain A expires on May 30, 2020. However, some clients may have problems if one or more of the following conditions is true:

Condition 1	Condition 2	Condition 3
The client is too old and does not have the USERTrust RSA Certification Authority root in its operating system or vendor managed truststore.	The client does not properly process Trust Chain B and instead always tries to follow Trust Chain A.	The client is configured to explicitly trust the AddTrust External CA Root and ignores its operating system or vendor managed truststore.

Conditions 1 and 2 may be addressed by configuring the server to send Trust Chain C.

Condition 3 requires the client to be reconfigured to either: 1) use the operating system or vendor managed truststore or 2) explicitly trust the USERTrust RSA Certification Authority root or the alternative legacy AAA Certificate Services root.

Certificates issued by the UC Berkeley Authority from April 30, 2020 through InCommon (Sectigo) will include a link to download Trust Chain C. We encourage you to use Trust Chain B unless you specifically need Trust Chain C for legacy device compatibility or to work around broken client issues.

Trust Chain Path A:	Trust Chain Path B:	Trust Chain Path C (not shown):
AddTrust External CA Root [Root] USERTrust RSA Certification Authority (Intermediate) [Intermediate 2] InCommon RSA Server CA [Intermediate 1] End Entity [Leaf Certificate]	USERTrust RSA Certification Authority (Root CA) [Root] InCommon RSA Server CA [Intermediate 1] End Entity [Leaf Certificate]	AAA Certificate Services [Root] (Exp: Dec 31, 2028) USERTrust RSA Certification Authority [Intermediate 2] (Exp: Dec 31, 2028) InCommon RSA Server CA [Intermediate 1] (Exp: Oct 5, 2024) End Entity [Leaf Certificate]

What you need to do:

_{(Big thank you to Carnegie Mellon for detailed testing and identification)}

Evaluate whether you have devices that meet Conditions 1, 2, or 3 by setting a client device clock to after June 1, 2020 and testing connectivity.
Apply the recommended fix for clients and/or servers meeting one or more of the Conditions below.

Condition 1 - Legacy Devices - Known Examples

We strongly encourage decommissioning these legacy devices if their software cannot be upgraded. Non-upgraded, legacy devices should never be exposed to the Internet and special mitigations should be applied to isolate them from neighbor systems. Legacy compatibility may be extended by reconfiguring servers to send Trust Chain C (see above). Contact your server admins to discuss whether that is possible.

Apple Mac OS X 10.11 (El Capitan) or earlier
Apple iOS 9 or earlier.
Google Android 5.0 or earlier.
Microsoft Windows Vista & 7 if the Update Root Certificates Feature has been disabled since before June 2010.
Microsoft Windows XP if an Automatic Root Update has not been received since before June 2010.
Mozilla Firefox 35 or earlier.
Oracle Java 8u50 or earlier.
Embedded devices (especially copy machines) that have not installed a firmware update since before mid 2015.

Condition 2 - Broken Clients - Known Examples

Reconfigure the server to send Trust Chain B or Trust Chain C and reconfigure the client to use the operating system managed truststore. Click the link for additional configuration information.

OpenSSL based client software

Client software that use OpenSSL libraries prior to version 1.1.1 for certificate path validation appear to always validate the full Trust Chain A sent from the server even though modern roots were configured to validate Trust Chain B.

This behavior was observed on Red Hat Enterprise Linux 6 (OpenSSL 1.0.1e-fips) and 7 (OpenSSL 1.0.2k-fips). Advancing the clock past June 1, 2020 and attempting connections to servers that sent Trust Chain A resulted in failed connections. In these tests, OpenSSL returned expired certificate errors even though Trust Chain B's root was available in the truststores. This behavior appears to be fixed in Red Hat Enterprise Linux 8 (OpenSSL 1.1.1c FIPS) and Ubuntu 14.04 (OpenSSL 1.1.1) as the same clock advancing tests resulted in successful connections and OpenSSL validating properly to Trust Chain B's root.

To work around this behavior, remove the expired AddTrust root from the client's operating system managed truststore or explicitly trust either the USERTrust RSA Certification Authority root or AAA Certificate Services root (depending on what the server sends).

ldap.berkeley.edu is already configured to send Trust Chain B

Examples of client programs that use OpenSSL for certificate path validation and were tested include OpenLDAP and postfix.

OpenLDAP clients on Linux and macOS

OpenLDAP clients on Red Hat Enterprise Linux 6 and 7 appear to always validate the full Trust Chain A sent from the server even though modern roots were configured to validate Trust Chain B. Once the client device clock was advanced to June 1, 2020, LDAPS connections failed validation on the expired AddTrust root until our test server was reconfigured to send either Trust Chain B or Trust Chain C.

OpenLDAP clients only enable TLS when either TLS_CACERT or TLS_CACERTDIR is set in ldap.conf. Either set TLS_CACERT to be the operating system managed PEM file or set TLS_CACERTDIR to an empty directory to force fallback to the operating system managed truststore.

Test whether a successful LDAPS connection can be made with:
ldapsearch -H ldaps://ldap.berkeley.edu:636 -x '(uid=111111)'

A successful connection will show query results while failing to negotiate TLS will show:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Or display debug info including the names of the chain certificates with:
ldapsearch -d 1 -H ldaps://ldap.berkeley.edu:636 -x '(uid=111111)'

ldap.berkeley.edu is currently sending Trust Chain B. Please reconfigure your OpenLDAP clients to use the operating system managed truststore if you are experiencing query failures.

Condition 3 - Explicit CA Trust - Known Examples

Reconfigure the client to use the operating system or vendor managed truststore if possible. If not, reconfigure the client to explicitly trust either the USERTrust RSA Certification Authority root or AAA Certificate Services root (depending on what the server sends). Click the links for additional configuration information.

Java applications that do not use the default truststore at $JAVA_HOME/lib/security/cacerts

Reconfigure the Java application to use the default truststore that is included with the JDK/JRE for client SSL/TLS connections. See vendor documentation for more information.

Lightweight Directory Access Protocol over SSL (LDAPS) clients

See vendor documentation for more information.

ldap.berkeley.edu is currently sending Trust Chain B. Please reconfigure your OpenLDAP clients to use the operating system managed truststore if you are experiencing query failures.

Simple Mail Transfer Protocol Secure (SMTPS) and SMTP with STARTTLS
- Postfix
  Set smtp_tls_CAfile to the operating system managed truststore (e.g. for RHEL7 /etc/pki/tls/certs/ca-bundle.crt)
- Sendmail
  Set confCACERT_PATH to the operating system managed truststore (e.g. for RHEL7 /etc/pki/tls/certs)

Downloads:

Please download CA certificates from trusted sources: For the root certificate download the "SHA-2 Root: USERTrust RSA Certification Authority" (Expires Jan 2038) from SectigoFor the intermediate certificate download the "InCommon RSA Server CA [PEM]" (Expires October 5, 2024) from Internet2

An example using only the InCommon RSA, typical for general purpose web servers would look like this, saved as ca_bundle.crt:

A full chain example CA bundle in this case would look like this, saved as ca_bundle.crt:

To validate the contents of your custom CA bundle:

openssl crl2pkcs7 -nocrl -certfile ca_bundle.crt | openssl pkcs7 -print_certs -text -noout

To validate the server certificate agasint the CA bundle:

openssl verify -CAfile ca_bundle.crt my_host_cert.crt

Quick Links