DST Root CA X3: expired since 2021


we are having issues with the following URLs cdn03.quay.io and infogw.api.openshift.com as we have enforced a firewall control rule that doesn't allow us to connect. the reason is
DST Root CA X3 Self-signed
Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Valid until: Thu, 30 Sep 2021 14:01:15 UTC
Weak or insecure signature, but no impact on root certificate

Looking at the topics in this support log, i can see that you suggest "forcing" the new cert chain to be used. How can this be done? any ETA for you to remove the expired cert?

Welcome to the community @GiacPis

First, both those sites serve perfectly valid cert chains. In fact, the infogw uses the same chain as this forum website. The cdn03 serves a more complex chain that is managed by Cloudflare in that manner for ECDSA support. There are various sites that show the chain in use (one such site here).

Do you own those sites? Or are you just having problems connecting to them because your firewall cannot properly validate the chain?

There are many threads that discuss the various chains. But, the choice of chain is at the discretion of the site operator. They choose the ones that work best for their expected visitors. Here is one thread about this DST Root CA X3


Here are a few links worth reading through:

You can find more by searching this forum for DST Root CA X3.


By the sites operator, not as a user of the website. Your firewall shouldn't have any trouble regarding the expired certificate, as the intermediate before it, is also a trusted anchor (i.e. root certificate) in almost any root certificate store now.


As others said, the problems you experience are likely due to other issues.

Selecting the root certificate for the chain depends on the ACME client. For Certbot, the commandline flag is --preferred-chain. See User Guide — Certbot 2.1.1 documentation

There are no publicly announced plans to remove the expired DST Certificate or switch the default Certificate to ISRG Root X1 or ISRG Root X2. In the interest of ensuring widespread access to encrypted traffic, most Open Source and Proprietary products have coalesced around a feature set and default behaviors that support ignoring this expired Certificate in favor of "short circuit" logic that stops evaluating the full chain once it encounters a valid Trusted Root the expired DST had signed. Only legacy Android devices utilize the expired Root; the majority of newer devices/libraries/applications simply will not even look at the expired DST Root because they recognize the ISRG root in the chain as being trusted and have no further work to do.

While it is possible that you have an extremely sensitive system which requires a fully validated chain, it is highly improbable. Considering the URLs in question are for public facing RedHat products and services, locking those sites down to only supporting clients that trust the ISRG roots is most likely NOT a solution worth considering.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.