Help thread for DST Root CA X3 expiration (September 2021)

What is the FQDN?

1 Like

No, only Cloudflare but it's in development mode (ie: do not cache anything)
So why on this computer does not work and everywhere else it does?

1 Like

Fully Qualified Domain Name...

1 Like

Please only reply to your conversation.
There are several ongoing conversations here.

2 Likes

Is it the host of website? It is https://design.aishowhouse.com/.

1 Like

What should I do? This website is ready in my os(window10)

1 Like

The fullchain received from the servers as of right now (post DST Root expiration) is still:

    Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3
    Validity
        Not Before: Jan 20 19:14:03 2021 GMT
        Not After : Sep 30 18:14:03 2024 GMT
    Subject: C = US, O = Internet Security Research Group, CN = ISRG Root X1

Please remove this from the chains communicated to clients starting right now. The root CA certificate SHALL NOT be part of the chain communicated to SSL clients, and the alternative path in which the ISRG Root X1 was not the root CA certificate is no longer valid.

I’m seeing select connection errors with some OpenSSL 0.x clients that predate my patching the newer verification behaviour into them. “It’s complicated” is why I can’t easily change that right now.

Edit: I can confirm that manually removing that part from /etc/ssl/d*ca* and restarting all services fixes these clients.

Edit 2: it is possible to work around this in the hook script; I just changed mine to filter out the offending intermediate.

Edit 3: apparently, others also have trouble with the presence of the DST-signed X1 in the fullchain. Removing the DST from the local root store may or may not help, depending on the circumstances. Removing the DST-signed X1 from the server chain, however, will always help (within possibility, i.e. X1 has to be present in local root store).

1 Like

Yes. We will redirect " design.aishowhouse.com" to "design.aishowhouse[.]com/pub/saas/1349f870f17f468f98555fd518b332c7"

1 Like


Hi
I´m have the same problem on Windows 7 64bits Google Chrome Versión 94.0.4606.61 with all sites with SSL Letsencrypt (including letsencrypt.org)
In Firefox 92.0.1 works fine without problem. Windows 10 all browser fine too. Ubuntu 20.04 fine too

1 Like

I see a different certification path in my computer that is valid, why are they different?

How can I force that certificate path in the customer's computer?

1 Like

I have added an update to the first post of this thread.

3 Likes

On my Ubuntu 16.04.6 LTS machine, the solution to SSL trust issues was to remove the DST Root CA X3 certificate by running the following two commands:

sudo rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
sudo update-ca-certificates

On my Mac OS X 10.13.6 machine, cURL (and therefore Git) rely on the /etc/ssl/cert.pem file for root CA verification.

The solution was to remove the DST Root CA X3 certificate, which expired today, from the file:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
        Validity
            Not Before: Sep 30 21:12:19 2000 GMT
            Not After : Sep 30 14:01:15 2021 GMT
        Subject: O=Digital Signature Trust Co., CN=DST Root CA X3
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:df:af:e9:97:50:08:83:57:b4:cc:62:65:f6:90:
                    82:ec:c7:d3:2c:6b:30:ca:5b:ec:d9:c3:7d:c7:40:
                    c1:18:14:8b:e0:e8:33:76:49:2a:e3:3f:21:49:93:
                    ac:4e:0e:af:3e:48:cb:65:ee:fc:d3:21:0f:65:d2:
                    2a:d9:32:8f:8c:e5:f7:77:b0:12:7b:b5:95:c0:89:
                    a3:a9:ba:ed:73:2e:7a:0c:06:32:83:a2:7e:8a:14:
                    30:cd:11:a0:e1:2a:38:b9:79:0a:31:fd:50:bd:80:
                    65:df:b7:51:63:83:c8:e2:88:61:ea:4b:61:81:ec:
                    52:6b:b9:a2:e2:4b:1a:28:9f:48:a3:9e:0c:da:09:
                    8e:3e:17:2e:1e:dd:20:df:5b:c6:2a:8a:ab:2e:bd:
                    70:ad:c5:0b:1a:25:90:74:72:c5:7b:6a:ab:34:d6:
                    30:89:ff:e5:68:13:7b:54:0b:c8:d6:ae:ec:5a:9c:
                    92:1e:3d:64:b3:8c:c6:df:bf:c9:41:70:ec:16:72:
                    d5:26:ec:38:55:39:43:d0:fc:fd:18:5c:40:f1:97:
                    eb:d5:9a:9b:8d:1d:ba:da:25:b9:c6:d8:df:c1:15:
                    02:3a:ab:da:6e:f1:3e:2e:f5:5c:08:9c:3c:d6:83:
                    69:e4:10:9b:19:2a:b6:29:57:e3:e5:3d:9b:9f:f0:
                    02:5d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Subject Key Identifier: 
                C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10
    Signature Algorithm: sha1WithRSAEncryption
         a3:1a:2c:9b:17:00:5c:a9:1e:ee:28:66:37:3a:bf:83:c7:3f:
         4b:c3:09:a0:95:20:5d:e3:d9:59:44:d2:3e:0d:3e:bd:8a:4b:
         a0:74:1f:ce:10:82:9c:74:1a:1d:7e:98:1a:dd:cb:13:4b:b3:
         20:44:e4:91:e9:cc:fc:7d:a5:db:6a:e5:fe:e6:fd:e0:4e:dd:
         b7:00:3a:b5:70:49:af:f2:e5:eb:02:f1:d1:02:8b:19:cb:94:
         3a:5e:48:c4:18:1e:58:19:5f:1e:02:5a:f0:0c:f1:b1:ad:a9:
         dc:59:86:8b:6e:e9:91:f5:86:ca:fa:b9:66:33:aa:59:5b:ce:
         e2:a7:16:73:47:cb:2b:cc:99:b0:37:48:cf:e3:56:4b:f5:cf:
         0f:0c:72:32:87:c6:f0:44:bb:53:72:6d:43:f5:26:48:9a:52:
         67:b7:58:ab:fe:67:76:71:78:db:0d:a2:56:14:13:39:24:31:
         85:a2:a8:02:5a:30:47:e1:dd:50:07:bc:02:09:90:00:eb:64:
         63:60:9b:16:bc:88:c9:12:e6:d2:7d:91:8b:f9:3d:32:8d:65:
         b4:e9:7c:b1:57:76:ea:c5:b6:28:39:bf:15:65:1c:c8:f6:77:
         96:6a:0a:8d:77:0b:d8:91:0b:04:8e:07:db:29:b6:0a:ee:9d:
         82:35:35:10
-----BEGIN CERTIFICATE-----
MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow
PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD
Ew5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmTrE4O
rz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEq
OLl5CjH9UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9b
xiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw
7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD
aeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNV
HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQMA0GCSqG
SIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69
ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXr
AvHRAosZy5Q6XkjEGB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZz
R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5
JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL+T0yjWW06XyxV3bqxbYo
Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
-----END CERTIFICATE-----

After removing the entire code snippet above from the file and saving it, the error went away.

3 Likes

I think this is the right place to post this issue.

I'm having issues connecting over SSL to a variety of services/sites from APIs to Github.com, etc.

I ran openssl s_client -connect api.tzkt.io:443 to get the certificate chain and this is what I got:

Certificate chain
 0 s:/CN=api.mainnet.tzkt.io
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

I get certificate expired for this site:

depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT

But when I run openssl s_client -trusted_first -connect api.tzkt.io:443 I get no certificate error.

I'm on Mac OSX High Sierra 10.13.6. How can I go about fixing this issue?

1 Like

You need to remove the DST Root CA X3 root certificate from your trust store (the one used by OpenSSL). I'm not sure right now where that is for Mac OS X.

Edit: Another user mentioned the file on OS X is /etc/ssl/cert.pem

3 Likes

Nop. https://community.letsencrypt.org/ and letsencrypt.org, the same error in both. I´m writing here from Firefox. And have many clients reporting me to enter my site, and it´s the same case: google chrome win7

1 Like

Should I use the full chain cert as my certificate? It has two "-----BEGIN CERTIFICATE-----"

Yes, thank you! This has fixed it for cURL, but not for OpenSSL.

It's still a big help though as cURL now works!

I'm looking into where the trust store for OpenSSL on Mac is now.

2 Likes

@yr12dong and @jp1839
Your chain should appear as

---
Certificate chain
 0 s:/CN=<your domain here>
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
---
4 Likes

Which versions of those browsers are you running? Have you tried updating to the latest available?

1 Like

I'm having problems with Apples devices, claiming that this connection is not private. When analyzing the certificate by safari, it is loading the DST Root CA X3 path. On other devices, such as android and windows, it is accessing normally and when analyzing the path ta as ISRG Root X1. I have a windows server with IIS, how to solve it?

1 Like