Skip to content

Instantly share code, notes, and snippets.

Last active Nov 5, 2020
What would you like to do?
Sectigo/Comodo/USERTrust/AddTrust Certificate Expiry May 30 2020 notes

Comodo/Sectigo/USERTrust/AddTrust root certificate expiry

On May 30th 2020 (10:48am GMT / 6:48am EDT / 3:48am PDT), several root & intermediate certificates that were part of the Comodo family expired.

The expired certificates

The following certificates expired on May 30 10:48:38 2020 GMT:


Thousands of web sites / services / APIs which present certificates that were issued by the vendor may have experienced trouble negotiating incoming secure connections from their clients. Exact issues, if any, depended on a mix of server configuration, client version, and client configuration.

A client validating any of those certificates had access to 3 "paths" to do so successfully. One of those paths (A) became invalid after the above certificates expired:

Trust Chain Path A: (INVALID)

Trust Chain Path B: (VALID)

  • USERTrust RSA Certification Authority (Type:Root) (Serial:01:fd:6d:30:fc:a3:ca:51:a8:1b:bc:64:0e:35:03:2d)
  • Sectigo RSA DV/OV/EV Secure Server CA (Type:Intermediate)
  • End Entity (Type:Leaf Certificate)

Trust Chain Path C: (VALID)

Problems and solutions

Client reports certificate not issued by trusted Certificate Authority

To address:


Ensure client updates their local CA roots trust store to include one/both of the (Type:Root) certificates in either of the Path B or Path C cases above


In the chain bundle you serve, include the (Type:Intermediate) certificates in path B and/or C above to encourage your clients to reach one of the two valid (Type:Root) certificates in their local CA roots trust store.

OpenSSL-based clients reporting certificate is expired

If a server is sending a bundled chain of certificates and it includes the above NOW EXPIRED certificates from Chain Path A, AND the client is using an older OpenSSL version (<1.1.0), AND the client's local CA roots trust store has the "AddTrust" root certificate, it will trigger a bug where the client will report an Expired error.

To address, do any/some/most of the following:


Update the server to no longer include the above 2 expired certificates in the chain bundle.


Update the OpenSSL library software version.

Edit the local CA roots trust store and remove/disable/blacklist the "AddTrust External CA Root" root certificate.

More details

Copy link

asurak commented May 30, 2020

There is a path towards AAA Certificates that does not require using the USERTrust cert as a root - Since some old clients will not recognise it as a trusted root CA, going with the path to AAA is safer. (we had to do it for Algolia production systems)

Copy link

minaguib commented May 30, 2020

Fascinating, will dig in and update as necessary. Thanks @asurak

Copy link

minaguib commented May 30, 2020

@asurak Thanks, done.

Copy link

minaguib commented May 30, 2020

Also, TIL, client validation walking up the chain just looks for the issuer by CN. There can be multiple matches (from server-supplied bundle and/or local store), some valid some not... !!

Copy link

asurak commented May 30, 2020

Great! The chain with AAA works also on old systems with old openssl, so it has the higher level of compatibility, if needed.

Copy link

kawesam commented May 31, 2020

How do I delete this two files on ubuntu 16 to resolve the issue? Update the server to no longer include the above 2 expired certificates in the chain bundle.

Copy link

minaguib commented May 31, 2020

@kawesam I'm not sure about Ubuntu/16 specifics.

If you're running an HTTPS server and you think you're sending the expired intermediate/root in the chain, check with and if that's the case, it depends on the web server you're using, but it'll typically involve editing a PEM file and removing some certs from it.

If you're running a client on an Ubuntu 16 server, see if the instructions at the bottom of Andrew's blog post help

Copy link

kamilbednarz commented Jun 1, 2020

My band-aid for AWS Beanstalk, Amazon Linux (CentOS) & .ebextensions:

# On May 30, 2020, the AddTrust root certificate that is still used in some SSL cert authorization
# chains (e.g. our case: OpenSSL 1.0.x in Amazon Linux is not able to fall back
# from the expired resolution path to a valid one.
# Solution to this is to blacklist expired certificate, it won't be used for the cert validations.
# More details here:
    mode: "000755"
    owner: root
    group: root
    content: |
    command: "update-ca-trust enable"
    command: "update-ca-trust extract"

But for non-beanstalk servers: it's a matter of placing this cert in the blacklist directory & re-generating ca-trust new files.

Copy link

emmm-dee commented Jun 1, 2020

Well this made for an interesting start of the week :(

Copy link

ValZapod commented Jun 2, 2020

Copy link

minaguib commented Jun 2, 2020

@ValZapod Thanks. I noted COMODO RSA Certification Authority in the "expired certificates" list.

I'm thinking now of ways to better represent the variations in INVALID and VALID chain paths...

Copy link

ValZapod commented Jun 2, 2020 Fixed.
curl/curl#5496 Wontfix as it is upstreams problem (openssl and gnutls)
openssl/openssl#12006 Was already fixed some time ago... Original commit in my comment there.

Copy link

ValZapod commented Jun 2, 2020

These also expired some of them have the same public key, LOL (like all USERTrust RSA Certification Authority). Very strange. Is this normal? I thought they change it. Looks like this is all.

Copy link

ValZapod commented Jun 8, 2020

I will also add that this has the same private and public key as COMODO RSA Certification Authority but is valid until 2038. So it is not technically expired. Also it is root, not intermediate. See

And with the main cert even (!) it has the same public key and still not expired!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment