Mine appears as:
Certificate chain
0 s:/CN=<my 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
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.e. there is a third entry, pointing to the old DST Root CA X3 it seems. Is this problematic?
I'm not sure, but it might have to do with this:
Yes, you'll want the following chain instead.
---
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
---
(i.e. just remove the cross-signed ISRG Root X1 from the chain), I suspect that your client(s) will begin to trust your server again.
You can make that change manually by editing the chain file used by your webserver. You can make the change permanently by editing the configuration of your ACME client to request the alternate chain.
sudo certbot certonly --nginx -d ${DOMAIN} --dry-run --preferred-chain="ISRG Root X1"
Your server looks like it's serving only the shortest chain, self-signed ISRG Root X1 certified. It seems that old devices can work, it is necessary that your server meets the longest chain with the ISRG Root X1 certificate signed by DST Root CA X3 (even if expired).
Do you have the expired DST Root CA X3 certificate in the Windows Server store?
Here's an example of an SSL Labs result that serves the longest chain:
Hello!
I am using certificates generated with certbot for a relay server and I cannot connect from Gsuite: the message I get is that the certificate is expired.
I tried to delete the DST Root CA X3 cert from the server and I tried to issue another certificate after doing that but I still get the same message.
The OS is CentOS, I tried to patch it with the openssl patch for this change but still no luck.
When I run a Reciver test (because the relay should recieve the email and the send it to another server) on //email/testTo: - I get this trace:
[015.477] Connection converted to SSL
SSLVersion in use: TLSv1_2
Cipher in use: ECDHE-RSA-AES256-GCM-SHA384
Perfect Forward Secrecy: yes
Certificate #1 of 3 (sent by MX):
Cert signed by: #2
Cert VALIDATION ERROR(S): certificate has expired
So email is encrypted but the recipient domain is not verified
Cert Hostname VERIFIED (hobbiton.stampymail.com.es = hobbiton.stampymail.com.es | DNS:hobbiton.stampymail.com.es)
Not Valid Before: Sep 30 16:34:52 2021 GMT
Not Valid After: Dec 29 16:34:51 2021 GMT
subject= /CN=hobbiton.stampymail.com.es
issuer= /C=US/O=Let's Encrypt/CN=R3
Certificate #2 of 3 (sent by MX): EXPIRED
Cert signed by: #3
Cert VALIDATION ERROR(S): certificate has expired
So email is encrypted but the recipient domain is not verified
Not Valid Before: Oct 7 19:21:40 2020 GMT
Not Valid After: Sep 29 19:21:40 2021 GMT
subject= /C=US/O=Let's Encrypt/CN=R3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
Certificate #3 of 3 (added from CA Root Store): EXPIRED
Cert signed by: #3
Cert VALIDATION ERROR(S): certificate has expired
So email is encrypted but the recipient domain is not verified
Not Valid Before: Sep 30 21:12:19 2000 GMT
Not Valid After: Sep 30 14:01:15 2021 GMT
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
Any idea of what can I do?
Thnak you very much!
Hello LE helpers,
I'm encountering an issue with our cert on Safari devices, the connection is shown as insecure, and appears to be using the expired DST Root. I tried renewing, and the issue persists. Host: video.cbs58.com We're using apache 2.2.34.
I deleted every expired certificate from DST Root CA X3. I shall try to install them again, so we have the full chain. You don't happen to have a resource where I can download it?
Here you can get all the certificates: Chain of Trust - Let's Encrypt
i think we need to wait ...
Do you think it settles on its own?
This is very odd. I requested a new certificate today and applied it to my apache web server.
When I goto the site I get the new certificate (verified thumbprint and serial) and it has the correct ISGR chain.
However I have a client that when they navigate to the site they also get the new certificate however its certificate chain is of the DST Root CA X3 chain.
I'm struggling to determine if this is a server issue or client issue. I cannot reproduce the issue on any of my devices, and this is isolated to one client.
Use OpenSSL or SSL Labs to show you exactly what chain is being served.
Then you will know if it is a server or client problem.
We're dealing with some of the same issues that most people are, but I'm struggling to find solid instructions on how to resolve what I'm seeing.
My webserver is a Windows server running MAMP, I'm mainly using MAMP for the PHP support and because I was grandfathered into this from a previous administrator. That's all unnecessary info (I think).
This is an internal use only kind of site, but we allow access from home, so we had to open it up to the web. I'm not 100% sure of my own security, so I don't want to share the URL if I can get around it.
On my server I'm running the "Certify the Web" application. I have the Preferred Chain set to "ISRG Root X1", for the most part the other settings are default, very few changes were made.
I am running a Powershell Script after each renewal that takes the cert, key, and csr.pem files and uses openssl to output .key, .cert, and .csr files that MAMP needs to actually use what Certify the Web is generating. It then restarts the MAMP services and then wonder of wonders, my site keeps working after each renewal.
Until this morning that has worked flawlessly. Even this morning, on windows computers running Chrome or Brave, my site is working just fine.
Edge is telling me that my site has no certificate at all, which is no big loss, my internal users all use Chrome anyway.
I have users that have been assigned iPod Touches for Shop Floor tasks, they need to be able to access this site. They can't. It seems that either Safari or Apple itself (because I have a similar issue on my MacBook) isn't making use of the Full Chain of the Certificate. It's still going to DST Root CA X3 as the Root instead of ISRG Root X1.
When I view the Cert through Certify the Web or through a Chrome Browser on Windows I can see the full chain going back to the ISRG Root X1 like it should.
What can I do to make my Apple Devices play nice?
Any help would be hugely appreciated.
Thanks
Dennis
Thanks, checking out ssl labs now.
I'm running a webserver with debian
|Description:|Debian GNU/Linux 9.13 (stretch)|
|Release:|9.13|
|Codename:|stretch|
Some of our customer are having issues because of the cert (expiring in 12 days)
openssl s_client -connect www.prenotauncampo.it:443 -servername www.prenotauncampo.it
CONNECTED(00000005)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = prenotauncampo.it
verify return:1
---
Certificate chain
0 s:CN = prenotauncampo.it
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
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFcjCCBFqgAwIBAgISA6+5LbGHTQNdC3pfKDLwqAuFMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA3MTQxMzM4MDVaFw0yMTEwMTIxMzM4MDRaMBwxGjAYBgNVBAMT
EXByZW5vdGF1bmNhbXBvLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAtgnExMTjYwJpYAm3Mk9zoCM0UQzH7IkXNz5xcVYNN5vj63xhpQyRs+RQRVsv
l4K6vYx7nBHr8hooCUDF3ILfY2ePA44w1iu3oie5y5JHCJKKA1K0t/y2JOiBXsUu
s/20Mh4dHnd12UMBUvzf0CEUaELLugzhFcEZKLIiEOimKAH1GH4aHHqgVBTvu4T8
HD3zeP4at/VL+qXUtXKXaVURV/MTx1PBB2vKMgn5WgEVLrGgjPBTemJQqvNgQGFM
sorWTf5C6QhTITq2agIPUqZmpmPi0OgKuNYnAcDlxvOh+a9XXOocTAd+T2PAwkNi
H5eHPZk3/hIPPkEe0YXICWXPtQIDAQABo4ICljCCApIwDgYDVR0PAQH/BAQDAgWg
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0G
A1UdDgQWBBRXB/rqyJCHhP/ZHN83lfD+6Ry8LTAfBgNVHSMEGDAWgBQULrMXt1hW
y65QCUDmH6+dixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6
Ly9yMy5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iu
b3JnLzBnBgNVHREEYDBeghcqLmFwaS5wcmVub3RhdW5jYW1wby5pdIITKi5wcmVu
b3RhdW5jYW1wby5pdIIbKi5zdGFnaW5nLnByZW5vdGF1bmNhbXBvLml0ghFwcmVu
b3RhdW5jYW1wby5pdDBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEB
ATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQMG
CisGAQQB1nkCBAIEgfQEgfEA7wB2AJQgvB6O1Y1siHMfgosiLA3R2k1ebE+UPWHb
Ti9YTaLCAAABeqV0EasAAAQDAEcwRQIgSMHVDTv8VX4pKluZXV3whNCLW3n5/tgL
95zO/9CIyeYCIQDggokfErRnhjF79uNXUl6Wk2BRY8qa2EDgmuUlaTSxPgB1AH0+
8viP/4hVaCTCwMqeUol5K8UOeAl/LmqXaJl+IvDXAAABeqV0EdAAAAQDAEYwRAIg
efsSP+CJj17wxb+VA4+jZXT+1QC4z04vSDb0osQKMBsCIEOxgh3sW2gLlXUGocAH
M35HObqM5jpOvn5V2ZgbLP8aMA0GCSqGSIb3DQEBCwUAA4IBAQALV+BNpCIDKjMO
H+zOarJrsiG3PDZzCbZKN3GQyi0nNy9sOBSi0j4wVxHRpo8lF4wo0Qb0ZAZdeGZj
c/D6JCmmfimJGE42eOoAAsiVNjdlU4rs9TGyXA/5G4Bx90CRGHsP+2JDm9QlfXgw
DMosJeQZPs7w11zt2Bq5r8KyAegfh1x9BCYWxa+rZgtEHBVKE72TVmgRjy42rsYJ
Ykv+pdbQ5zzOApBn+Qd4XOTL7wWj6bPMfAVotbpT62LBMm7aZFNNDVcjErRWzahM
EkZd8QBSJxfhBoYPjuhKWGyxHl001Xkn8+gCXVMFoTCRYm02mSrWgv91tyAY5+T2
qIPFmq2C
-----END CERTIFICATE-----
subject=CN = prenotauncampo.it
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 4637 bytes and written 481 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 2AAC7D64CC87C77A9A4C300439C0C7DEC764B515F709FC3291F5948A87E7E2D5
Session-ID-ctx:
Master-Key: 3440A57EFB6DD7E27EEA66D8EAF83141C2B46E388AC31CB63B84F1234BE02C3D62D9BD6158BC1AB0020E4CF70D2F2A7F
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1633025704
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
can i do something on the server side? all checkers are telling me that's all fine
using this site: SSL Server Test (Powered by Qualys SSL Labs)
It shows that it serving the expected new chain up to the ISRG certificate. What would cause a client (a windows 10 machine on IE/Chrome/Edge/Firefox) to still be thinking the certificate is from the old expired chain?
Stale/cached information...
The trusted root store is out of date...
It's a Thursday...
It's the last day of the month...
Is there some way of getting an X1 cert back? We've lost access to hundreds of remote clients that are using lets encrypt. All stopped communicating but will reboot in 8hrs.
If there is s way to get X1 back, even for a day or two, we could send a new firmware update to all of our customers devices.
Travel back in time...
[fool them by setting their clocks back]
i don't undestand for fix we need to wait ?
or we nee to edit on our webserver ?
@ajeje989
What problem are you having?