Upcoming AddTrust Root Expiration – What You Need to Know
Sectigo at present offers the ability to cross-sign certificates with the AddTrust legacy root to increase support among very old systems and devices. This root is due to expire at the end of May, 2020. Any applications or installations that depend on this cross-signed root must be updated by May, 2020 or run the risk of outage or displayed error message.
For more information read:
- https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020
- https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA03l00000117WR#Q2
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 to 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 (Root CA) [Root]
|
AAA Certificate Services [Root] (Exp: Dec 31, 2028) |
|
What you need to do
- 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 workaround this behavior, configure the server to send Trust Chain B or Trust Chain C and configure the clients to use the 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)
- Postfix
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 Sectigo. For the intermediate certificate download the "InCommon RSA Server CA [PEM]" (Expires October 5, 2024) from Internet2.
