Summary

On May 30, 2020 the commonly used Sectigo (Comodo) Root certificate, named AddTrust External CA Root certificate, expired. Applications that rely on an operating system’s list of trusted root certificates and most applications have not be impacted.

However, some members of the campus community experienced issues logging in to UMass Amherst IT and administrative services that are secured by InCommon SSL/TLS certificates. These special cases may include clients using older browsers or operating systems not containing an updated list of trusted root certificates or Java keystores or other special cases requiring the root certificate in addition to the intermediate certificates. 

• 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 may also miss other essential security updates. We strongly encourage retiring legacy devices if the software cannot be upgraded. 

Other considerations

• Client software based on OpenSSL prior to version 1.1.1 may have broken certificate path validation logic and will require workarounds
• OpenLDAP clients on some platforms may 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 Mac OS 
• OpenLDAP clients that connect to ldap.umass.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.

More information

The majority of  applications are unaffected by this expiration date, 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: The client is too old and does not have the USERTrust RSA Certification Authority root in its operating system or vendor managed truststore. 
• Condition 2: The client does not properly process Trust Chain B and instead always tries to follow Trust Chain A.
• Condition 3: 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. 

Next steps

Campus IT professionals are urged to check the SSL certificate configuration for the applications they maintain and contact it@umass.edu as soon as they detect an issue. 

Many thanks to Carnegie Mellon University and UC Berkeley whose CalNet - Identity & Access Management documentation served as the basis for this page.