What should I do? This website is ready in my os(window10)
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.
4 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
5 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
---
6 Likes
Which versions of those browsers are you running? Have you tried updating to the latest available?
2 Likes
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
@wallace.wgr, what version of IOS and Safari?
As for IIS, you can try this [Fix] DST Root CA Expired - IOS and Android not working - IIS
2 Likes
Well I solved it! I had to install the certificate into that windows machine which had Windows Update off!
Launch MMC.exe, export the ISRG Root X1 in my computer, import it into the other. Hope someone finds this helpful
1 Like
Windows 7
Chrome VersiĆ³n 94.0.4606.61 (problem SSL)
Firefox 92.0.1 (works fine) (iĀ“m here in this site)
Windows 10
Chrome 94.0.4606.61 (works fine)
All browser say is up to date
1 Like
Some worked and some didn't. The last one that had a problem was the IPhone 11 version 13.2.
Yesterday none were accessing, a few hours ago, some older versions and 12 seems to have normalized.
1 Like
Hello,
We're having issues with old android phones (We're sure of android 6, not sure about 7), our application runs IIS 10, on a Windows Server 2019.
The requests to our server returns "Trust anchor for certification path not found.".
The domain is "https://dev.ojo.softniels.com.br/".
We use win-acme to generate our certificates.
So far we have:
- Updated WinAcme to the latest version;
- Rebooted the server multiple times;
- Re-set the certificate on the IIS binding (Someone mentioned on another topic that this solved for them);
- Removed expired certificates from the local computer;
We're really on the dark in terms of what to look for. SSL Labs report seems to be OK, but I don't have a lot of experience with this kind of issue.
Any leads on what we could try next?
2 Likes