Description of problem:

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

Sectigo's legacy AddTrust External CA Root certificate expires on May 30, 2020. Modern clients should largely be unaffected. However, legacy clients, OpenSSL based clients, OpenLDAP clients, and clients configured to explicitly trust the AddTrust root instead of relying on an operating system or vendor managed truststore may need client or server reconfiguration to avoid loss of service.

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 largely be unaffected.

Legacy devices that have not received updates to support newer roots will inevitably 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.

Client software based on OpenSSL prior to version 1.1.1 appear to have broken certificate path validation logic and require workarounds.

OpenLDAP clients on some platforms appear to have broken certificate path validation logic and require workarounds.

Clients configured to explicitly trust the AddTrust root may need client reconfiguration to either: 1) rely on operating system or vendor managed truststores or 2) explicitly trust the USERTrust RSA Certification Authority root or the alternative legacy AAA Certificate Services root (valid until Dec 2028).




Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:

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 unfortunate behavior was observed on Red Hat Enterprise Linux 6 (OpenSSL 1.0.1e-fips) and 7 (OpenSSL 1.0.2k-fips). On our test devices, 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 unfortunate 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).

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


Expected results:


Additional info: