Sectigo Root and Intermediate Certificate Expiry - May 2020

Updated -

Sectigo CA Certificate Expiry

Summary

TLS clients not capable of building an alternative certificate chain stopped working correctly when connecting to servers which advertise a certificate chained to the Sectigo root CN = AddTrust External CA Root on May 30, 2020. These servers direct clients to the expired root by supplying one of several possible intermediate certificates that expired at the same time.

To address the problem across platforms, administrators of affected TLS servers must configure them to not advertise the expired Sectigo root CA certificates (see the Quick Fix Details section).

There is a workaround for RHEL 7 client applications using openssl (see Alternative Fix), but there is no workaround for RHEL 6 client applications. RHEL 8 contains features that allow clients to discover alternative paths to expired root CA certificates. Earlier versions contain a simpler variant of the certificate verification routine that does not discover alternative paths in cases like that. Red Hat does not plan to update these versions, because the risks we identified in bringing the updated code outweigh the benefits for the clients affected.

Quick Fix Details

On the server, delete any expired intermediate or root certificates from the server configuration to ensure that the server do not send them to clients. Replace the expired certificates with the updated certificates.

Background

The root Certificate Authority (CA) certificate with CN = AddTrust External CA Root expired at 2020:05:30 10:48:38 GMT.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
        Validity
            Not Before: May 30 10:48:38 2000 GMT
            Not After : May 30 10:48:38 2020 GMT
        Subject: C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
            X509v3 Authority Key Identifier:
                keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
                DirName:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
                serial:01

A number of intermediate certificates signed by this root certificate expired at the same time. Those currently identified are as follows

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            27:66:ee:56:eb:49:f3:8e:ab:d7:70:a2:fc:84:de:22
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
        Validity
            Not Before: May 30 10:48:38 2000 GMT
            Not After : May 30 10:48:38 2020 GMT
        Subject: C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1
            X509v3 Subject Key Identifier:
                BB:AF:7E:02:3D:FA:A6:F1:3C:84:8E:AD:EE:38:98:EC:D9:32:32:D4


Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            13:ea:28:70:5b:f4:ec:ed:0c:36:63:09:80:61:43:36
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
        Validity
            Not Before: May 30 10:48:38 2000 GMT
            Not After : May 30 10:48:38 2020 GMT
        Subject: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
            X509v3 Subject Key Identifier:
                53:79:BF:5A:AA:2B:4A:CF:54:80:E1:D8:9B:C0:9D:F2:B2:03:66:CB

Root certificate expiry is a normal, if infrequent, occurrence. In most cases servers should not be affected as the intermediates for their End-Entity certificates are updated whenever the EE certificate is renewed and the CA websites on the renewal and installation pages should document the need to remove the soon to be expired root and intermediate certificates before the expiration happens. Where this procedure is not followed, unexpired EE certificates end up being provided together with a chain of intermediates that include an expired intermediate that points to the expired root.

In this particular case, the system certificates bundle contains alternative root certificates in which the unexpired intermediates provided by the server can be directly chained to. These alternative roots have the correct name and key identifier which allow them to function as the client trust point. To fix this on the server, remove any expired intermediate certificates that appear in application certificate files, for example, intermediates in the SSLCertificateChainFile of an httpd web server.

Alternative Fix

For configurations that maintain a private bundle of an EE certificate, intermediate certificates, and a root certificate, it is necessary to rebuild the bundle with unexpired certificates. Specific details depend on the type of bundle and the EE certificate involved.
You can find replacement intermediate certificates on the How to Download & Install Sectigo Intermediate Certificates - RSA page. You have to identify the required certificate in the current intermediate bundle, and substitute the new certificate and root (if applicable) in the bundle.

Known variations that use private bundles:

  • katello certificate bundles
  • NSS certificate bundles

To work around the openssl client problem on RHEL 7, remove the expired root CA from the system trust store. In RHEL 7.4 or later releases, use a trust command for explicitly disabling the CA certificate:

  • Figure out the expired CA certificate with:
# trust list
  • Create a blacklist file:
# trust dump --filter "pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert" > /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
  • Update the system trust store:
# update-ca-trust
  • Make sure that the CA is not listed anymore as trusted with:
# trust list

Related

Comments