Expiry of InCommon Certificate AddTrust External CA Root (May 2020)

The InCommon root certificate AddTrust External CA Root expired Saturday, May 30, 2020, at 6:48 a.m. See Sectigo AddTrust External CA Root Expiring May 30, 2020, for details. Sectigo is the company that provides the InCommon certificates used at U-M.

Sectigo sets the expiry dates for its certificates, and U-M cannot change or extend them.

Take action if your unit has installed an InCommon certificate (usually requested and received via WASUP) on a system, site, or service and it is experiencing problems related to the expiry.  Current certificates are available at ITS: SSL Server Certificates.

General Action Needed

U-M units that manage systems or services that use InCommon Certificates (usually requested and received via WASUP) need to ensure that updated certificates are installed and rconfigured to follow the new InCommon certificate chain best practices:

  1. If you have one of the following certificates installed that expired on May 30, 2020—whether in a certificate chain or in a “CApath directory”—remove them:
    • Remove the AddTrust External CA Root certificate (expired May 30, 2020)
    • Remove the USERTrust RSA Certification Authority intermediate certificate (expired May 30, 2020).  You will need to check the expiration date on this certificate to determine whether to remove it, since there is also a root certificate with the same subject and hash that you need to keep.
  2. Configure your system or service to follow the new InCommon certificate chain best practices (outlined at SSL Server Certificates​):
    • Ensure you have the InCommon RSA Server CA intermediate certificate (expires 2024)  installed. Install it if it is not present.
    • For mod_cosign and any other middleware that requires a full certificate chain, also install the USERTrust RSA Certification Authority root certificate (expires 2038). This root certificate should not be installed when configuring a web server for HTTPS, but it may be needed in many other cases.
  3. Test to be sure clients can access your system or service.

Specific Action Needed for mod_cosign

For sites that authenticate using Apache mod_cosign:

  1. Find the CosignCrypto setting in your Apache configuration files:
    CosignCrypto /path/certificate.key /path/certificate.cert /path/to/ca/certs
  2. If the last argument in the line is a directory (common case), run this command:
    openssl x509 -noout -subject -issuer -in /path/to/ca/certs/fc5a8f99.0
    Old versions of OpenSSL (such as RHEL5): Use 35105088.0 instead of fc5a8f99.0 for the hashed file name.
  3. If the last argument is a file, run this command:
    openssl crl2pkcs7 -nocrl -certfile /path/to/ca/certs | openssl pkcs7 -noout -print_certs \ | grep -A1 '^subject.*USERTrust RSA'

The results of running the commands above will let you know if you need to take action:

Action needed: If the certificate is signed by AddTrust, you must replace it before May 30
subject= /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
issuer= /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

Check for AAA root cert: The version signed by AAA will work if you also have the AAA root certificate
subject= /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
issuer= /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services

Okay if self-signed: Many OS and browser CA bundles use a self-signed version
subject= /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
issuer= /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority

Download the self-signed version, 2038 USERTrust RSA Certification Authority (root), if needed.

Known At-Risk Systems, Sites, and Services

Systems, sites, and services your unit manages that may use InCommon certificates include:

  • Web servers
  • Any server or service that supports TLS, including directory servers, email servers, and middleware/API servers
  • IT appliances
  • Embedded systems
  • Remote server management cards
  • Networking devices
  • Cloud computing, including Amazon Web Services, Google Compute Platform, and Microsoft Azure
  • SaaS vendors to whom you have provided certificates
  • ITS MiServer instances (both managed and unmanaged MiServer)
  • ITS Container Service instances

These systems, sites, and services are know to be at-risk for issues related to the certificate expiry:

  • Web servers using mod_cosign (an authentication filter module for Apache). See mitigation details above.
  • Java 8 prior to JRE 8u51, Java 7 prior to JRE 7u85, and any release of Java 6 will not be able to verify InCommon certificates using the old root certificates starting May 30, 2020. Options to address this include:
    • Update to a newer version of Java (preferred).
    • Add the newer UserTrust root certificate to the Java certificate store.
    • Update the certificate chains presented by upstream systems to use the newer certificate bundle that is valid until the end of 2028.
  • Software, services, and appliances that are configured to use a full certificate chain for verifying certificates and do not also use a trust store that is provided by an operating system or platform vendor.
    • Example: a VPN or other network appliance that authenticates users using MCommunity LDAP might check only the certificates present in the chain it was configured to use.
  • Software, services, and appliances that have their own local trust store for verifying certificates that does not automatically receive updates from an upstream vendor.
  • Operating systems, software, or appliances that verify certificates provided by other systems, and for which the last general update was prior to 2015.
  • Services that are accessed by clients that use OpenSSL prior to version 1.1.1. This includes all fully patched and up-to-date RHEL5, RHEL6, and RHEL7 clients, and likely includes macOS. This is because of a bug in OpenSSL that prevents the client from using an alternate certificate path to successfully verify the server's certificate. For details, see references below.

Users of Older, Unsupported Web Browsers and Systems Affected

People using outdated, unsupported operating systems and web browsers may see a warning or error message when trying to access some websites. They may be able to work around this issue by switching to the Firefox web browser. We urge people to use supported software and keep it updated.

The following operating systems and web browsers are known to be at risk:

  • Apple:
    • macOS El Capitan 10.11 and older
    • iOS 9 and older
  • Microsoft:
    • Windows XP and older
    • Windows Phone 6 and older
  • Mozilla:
    • Firefox 35 and older
  • Google:
    • Android 5.0 and older
  • Oracle:
    • Java JRE 8u51 and older, 7u85 and older, and any version of Java 6
  • Opera:
    • Versions of Opera released before December 2012

References

Last Updated: 
Saturday, May 30, 2020