That chaining doesn't seem right.
It should look like the chain being used by this site:
---
Certificate chain
0 s:/CN=community.letsencrypt.org
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
---
Hi @matthkarl, welcome to the LE community forum 
Possibly.
You may need to ensure it has the latest root store.
I don't have an iPhone so I can't say how that's done.
Do they connect to the same email system as your iOS 14 (and on the same ports)?
No, sorry, I haven't found a fix yet..
If I find one, I'll let you know though.
hi @blestakos, welcome to the LE community forum
You mean one other than the one that has been going around for more than ten years - upgrade away from Win7.
Other than that one... I guess you could continue to beat it with a bigger hammer [there is always a BIGGER HAMMER - LOL].
@reg305
Thanks for your reply. Yes, they go to the same mail server on the same domain.
The strange thing is, that the phone that is not working, has the newer "Trust Store Version" than the older iPhone that is working. I found that Trust Store Version in the Settings - General - About - Certificate Trust Settings.
I also tried updating to the latest iOS, but that didn't solve the issue.
@matthkarl
Well that's likely that Apple has released a patch to remove the expired cert from their store.
So... the fix (for your phone) is likely found in the mailserver setting.
It may need to stop using the longer/expired cert chain.
Who controls the mailserver?
It is same like in our server. But still we are facing issues.
Hi guys,
We are running nginx (1.14.0) on ubuntu 18.0.4.
www.webonvr.net domain
SSL certificate is error is coming while trying to connect webpage from chrome.
Any different suggestion? Thanks.
I control the mailserver. It's a Mailenable server on Windows 2012 Server R2.
As far as I can tell, the certificate does use a fully valid chain from the Domain up to X1. I also just out of no other idea, re-booted the server to have any kind of cache released.
Hello, I cannot understand which the problem is. I am using an asp.net application (with kestrel) on ubuntu 18.04 (working until 29th September). On my server I requested a fresh new certificate using
sudo certbot certonly --webroot --preferred-chain "ISRG Root X1"
with success.
I converted it to pfx using
openssl pkcs12 -inkey /etc/letsencrypt/live/hub1.cet.cloud/privkey.pem -in /etc/letsencrypt/live/hub1.cet.cloud/fullchain.pem -export -out freecert.pfx -password pass:[mypassword]
and analyzing it with
openssl pkcs12 -info -in freecert.pfx
produced
MAC:sha1 Iteration 2048
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Bag Attributes
localKeyID: 78 D3 B7 FB 35 5A 6E 73 8B D3 0E BA 2F CE 8B 27 01 A6 C5 D6
subject=/CN=hub1.cet.cloud
issuer=/C=US/O=Let's Encrypt/CN=R3
-----BEGIN CERTIFICATE-----
MIIFIjCCBAqgAwIBAgISA6bJd9Q/QePvDBKsI+penHAdMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA5MzAxMDQwMzVaFw0yMTEyMjkxMDQwMzRaMBkxFzAVBgNVBAMT
Dmh1YjEuY2V0LmNsb3VkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
2QKa90ruzeJvuDpsz3xLGZecF8xIwOhF2WCgWpj1b0rk7m9eWHJ/CnyvL2bkPYgj
xwIJ1SnhoIhRoUg2acVmw7HeP8/2ixJ4w+B4SBcsfnHk+yF/W0PY11hSCyikDmoH
FAFygZPKjsW6pcvoYvkaH5TjkoKLoAatCELPgA8+bDGvbus4KwKFuqclvHxH4602
2m1IVgdUrm0Yod4bhVzJVjz8Mbn/q9E9lEUZAZNH5nDOdF9Xgjb1YdQJdNFwUfaH
hm01XFv1huYTb6IhhYXyOU8xUxuK4pKGSFIhVdmlnjVZwsWNzm01vgy5/F13mnGa
IwNiSlsHFKcF46dJ1YXPGwIDAQABo4ICSTCCAkUwDgYDVR0PAQH/BAQDAgWgMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1Ud
DgQWBBScx2SaR2DlHI8kNlJzXHTkSkIkVDAfBgNVHSMEGDAWgBQULrMXt1hWy65Q
CUDmH6+dixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9y
My5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iub3Jn
LzAZBgNVHREEEjAQgg5odWIxLmNldC5jbG91ZDBMBgNVHSAERTBDMAgGBmeBDAEC
ATA3BgsrBgEEAYLfEwEBATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNl
bmNyeXB0Lm9yZzCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB2AH0+8viP/4hVaCTC
wMqeUol5K8UOeAl/LmqXaJl+IvDXAAABfDaBmJgAAAQDAEcwRQIhAJY0gQ/vQEWR
1fwn+ML/RA1BKvqTtis7pVUnK/JMtVlZAiAGgtsPJ/IvB66eidubtJK5yHM9aIoo
CZsB3bLNUx0KxwB2AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEAKQaNsgiaN9kTAAAB
fDaBmUIAAAQDAEcwRQIhAP9nXqL7HtpVBYBSbcPb2kiWyDpGzJe1rSubYd/r/pHA
AiA0bI92IbJx4wW3P6lPrs/c1feK4P7qH2pDnZelCboz8zANBgkqhkiG9w0BAQsF
AAOCAQEApasjJEtVS+k/xon8uzzY2r9e3ogwKOShEX1y+O/8q8y2adaVNh6/R8rz
/A7Fja4EwnMfEBIlew6SzLWBKWoJ3oF2TXee2/E0Z6/gBC0imlBG/po1RwVrldck
Zh7TSAAlqjNZfPsz+CSuMXqZ4/D30lgLpB0nrqL1rNxJrhLphNSOzkOmNRF3xokM
dzCsOl5+9k2MXWQqAZSEXXKdt/qVgc2CVzD3Q5KODsPv8nNNsQcq0+Bj5VAdO3Nv
nrD5lTVs31Ykf4BXslw8vEma5SDxnhNXOoW7TJOtMLE+f2mdLa+6mNZazyBv8Uza
tGgku+XQSB2XAEH0xY6+2uEbGCxQxQ==
-----END CERTIFICATE-----
Certificate bag
Bag Attributes: <No Attributes>
subject=/C=US/O=Let's Encrypt/CN=R3
issuer=/C=US/O=Internet Security Research Group/CN=ISRG Root X1
-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----
Second certificate seems being https://letsencrypt.org/certs/lets-encrypt-r3.pem.
Now, after application restart, executing
openssl s_client -connect hub1.cet.cloud:443 -servername hub1.cet.cloud
from another PC, I obtain
CONNECTED(000001A4)
depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = hub1.cet.cloud
verify return:1
---
Certificate chain
0 s:CN = hub1.cet.cloud
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFIjCCBAqgAwIBAgISA6bJd9Q/QePvDBKsI+penHAdMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA5MzAxMDQwMzVaFw0yMTEyMjkxMDQwMzRaMBkxFzAVBgNVBAMT
Dmh1YjEuY2V0LmNsb3VkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
2QKa90ruzeJvuDpsz3xLGZecF8xIwOhF2WCgWpj1b0rk7m9eWHJ/CnyvL2bkPYgj
xwIJ1SnhoIhRoUg2acVmw7HeP8/2ixJ4w+B4SBcsfnHk+yF/W0PY11hSCyikDmoH
FAFygZPKjsW6pcvoYvkaH5TjkoKLoAatCELPgA8+bDGvbus4KwKFuqclvHxH4602
2m1IVgdUrm0Yod4bhVzJVjz8Mbn/q9E9lEUZAZNH5nDOdF9Xgjb1YdQJdNFwUfaH
hm01XFv1huYTb6IhhYXyOU8xUxuK4pKGSFIhVdmlnjVZwsWNzm01vgy5/F13mnGa
IwNiSlsHFKcF46dJ1YXPGwIDAQABo4ICSTCCAkUwDgYDVR0PAQH/BAQDAgWgMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1Ud
DgQWBBScx2SaR2DlHI8kNlJzXHTkSkIkVDAfBgNVHSMEGDAWgBQULrMXt1hWy65Q
CUDmH6+dixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9y
My5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iub3Jn
LzAZBgNVHREEEjAQgg5odWIxLmNldC5jbG91ZDBMBgNVHSAERTBDMAgGBmeBDAEC
ATA3BgsrBgEEAYLfEwEBATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNl
bmNyeXB0Lm9yZzCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB2AH0+8viP/4hVaCTC
wMqeUol5K8UOeAl/LmqXaJl+IvDXAAABfDaBmJgAAAQDAEcwRQIhAJY0gQ/vQEWR
1fwn+ML/RA1BKvqTtis7pVUnK/JMtVlZAiAGgtsPJ/IvB66eidubtJK5yHM9aIoo
CZsB3bLNUx0KxwB2AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEAKQaNsgiaN9kTAAAB
fDaBmUIAAAQDAEcwRQIhAP9nXqL7HtpVBYBSbcPb2kiWyDpGzJe1rSubYd/r/pHA
AiA0bI92IbJx4wW3P6lPrs/c1feK4P7qH2pDnZelCboz8zANBgkqhkiG9w0BAQsF
AAOCAQEApasjJEtVS+k/xon8uzzY2r9e3ogwKOShEX1y+O/8q8y2adaVNh6/R8rz
/A7Fja4EwnMfEBIlew6SzLWBKWoJ3oF2TXee2/E0Z6/gBC0imlBG/po1RwVrldck
Zh7TSAAlqjNZfPsz+CSuMXqZ4/D30lgLpB0nrqL1rNxJrhLphNSOzkOmNRF3xokM
dzCsOl5+9k2MXWQqAZSEXXKdt/qVgc2CVzD3Q5KODsPv8nNNsQcq0+Bj5VAdO3Nv
nrD5lTVs31Ykf4BXslw8vEma5SDxnhNXOoW7TJOtMLE+f2mdLa+6mNZazyBv8Uza
tGgku+XQSB2XAEH0xY6+2uEbGCxQxQ==
-----END CERTIFICATE-----
subject=CN = hub1.cet.cloud
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: X25519, 253 bits
---
SSL handshake has read 3091 bytes and written 409 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
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-AES256-GCM-SHA384
Session-ID: 8A03F2985E8C119F087B1AF324367801D3221EC832C6BC35B694B01C8957075C
Session-ID-ctx:
Master-Key: DB7B3BDEA5602CB686C8770523DAD9DD581A6F2F3C00785EE91B08F3FB3BD3E3BD5ECBCA1374AB37288CBAA5437CC688
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - c2 39 3c 31 a4 ed 6d 24-77 1e 94 1b da b5 18 db .9<1..m$w.......
0010 - c6 62 92 69 af 85 06 a9-09 ee 6f b2 0a 1d 7b ae .b.i......o...{.
0020 - 72 2b 05 d7 cb 03 bf 8a-b2 fa 55 c3 fe 9f da c5 r+........U.....
0030 - 9e ff da 4a 1c de e8 4d-df 98 f9 c7 85 71 8f d9 ...J...M.....q..
0040 - 96 16 23 ad 37 fd 40 2b-89 f3 58 6e d5 63 70 9c ..#.7.@+..Xn.cp.
0050 - 63 a8 32 73 14 32 ec d4-fb ea 9e 7a 61 9a ca a1 c.2s.2.....za...
0060 - ca 67 4c 02 1f a2 6f c3-e8 1b 0a 61 42 55 ab e4 .gL...o....aBU..
0070 - a0 68 e5 35 bd af 65 ee-74 88 be 9c 2d 9f 79 f1 .h.5..e.t...-.y.
0080 - 83 d0 6f 4b d2 0d 73 1f-1a e4 e7 a4 0c 91 b7 7f ..oK..s.........
0090 - d5 4a d9 66 84 ed f5 ee-be d2 83 a6 68 93 3e 3e .J.f........h.>>
00a0 - e4 55 5e 57 16 98 35 0c-25 7b af 1b ea 63 f8 9c .U^W..5.%{...c..
Start Time: 1633088075
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Extended master secret: yes
---
read:errno=0
I am not able to understand why chains are different, while my server certificate is the correct one. Any suggestion?
This is what worked for me (on Linux). Ie: I have two signatures in my fullchain.pem and I just deleted the second one However this is a temporary solution as next automatic renewal will create another fullchain.pen with two signatures (at least?).
How could this be avoided and to make the certbot to include only one signature in the fullchain.pem?
I'm assuming this is more of a workaround than a solution, but as I can't change the client's code, this is perhaps the only way to go?
How do I solve the problem?
Thanks
Hi, I know that everybody is with the same issue, but when I try to update my SSL certificate in WHM It gave me these error messages
ERRO Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL’s verification (0:10:CERT_HAS_EXPIRED).
AVISO Cpanel::Exception/(XID f38udb) The response to the HTTP “HEAD”
request from “https://acme-v02.api.letsencrypt.org/acme/new-nonce”
indicated an error (429, Too Many Requests): “”
How can I get around this, because I'm not able to send emails since yesterday.
Thanks Guys.
Checking from an Ubuntu machine to see what the mail server replies:
So it doesn't use the old chain, it should be fine, no?
openssl s_client -connect autodiscover.mtcom.ws:465 -servername autodiscover.mtcom.ws
CONNECTED(00000003)
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 = autodiscover.mtcom.ws
verify return:1
---
Certificate chain
0 s:CN = autodiscover.mtcom.ws
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
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFwDCCBKigAwIBAgISA7YQ2plE4glOnIGfClBO1OqhMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA4MjkwMDAxNTZaFw0yMTExMjcwMDAxNTVaMCAxHjAcBgNVBAMT
FWF1dG9kaXNjb3Zlci5tdGNvbS53czCCAaIwDQYJKoZIhvcNAQEBBQADggGPADCC
AYoCggGBAKtv9LFa7oRuCv4sAwGAHbbprCWoeQtW9BK0h+nG9x2VI3J/EL7oSBwx
NSFZSXbIOP4pwmyzlQJ3OJXpbSXklw+xMjo2Q3HYL0Q1Isq7Tzg3iodlRD6gC7/D
pl6zTAFtNFBpntOAgPab6p/0pCgOf9EZV1ZmgIOgE8WJnbaBYJQLnttvT8WRhd9W
V37e2jy7C0n2QU9Da1KlZ8/VonXYD33UfBQnwIoeNAi5R5Vo34A6N5xT6lcUhjrX
DcPsvj2RzUxY343CXlmSiJjDLqAZt3of87Im1ERJnBsNd94UQUICcZASPub9GeJ6
NJ4KCDXJbEmollWaZT2bA7wA3RpoAE2jdFjqqKrVduNtUgz3c7QnmO7dxGc3bHON
qQ59EpoUH/8lK1yc+ss4u6+6mGjvLe9Eb6YNdHYQq3JRzo+54DYOLQyzeH9l1qtg
+1VBWXTRhOs2GMpvDac03KJQX09pS1La307afM+n8Icdh+hUPpSWPaLfx0p7UoSv
a+qeLlUg+wIDAQABo4ICYDCCAlwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSCsuu5
B84G8kqItxwbJe2CEO9FZjAfBgNVHSMEGDAWgBQULrMXt1hWy65QCUDmH6+dixTC
xjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9yMy5vLmxlbmNy
Lm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iub3JnLzAvBgNVHREE
KDAmghVhdXRvZGlzY292ZXIubXRjb20ud3OCDW1haWwubXRjb20ud3MwTAYDVR0g
BEUwQzAIBgZngQwBAgEwNwYLKwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0
cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwggEFBgorBgEEAdZ5AgQCBIH2BIHzAPEA
dwBElGUusO7Or8RAB9io/ijA2uaCvtjLMbU/0zOWtbaBqAAAAXuPbWcPAAAEAwBI
MEYCIQCOuPSS8U+b4zrdpssp7X8hJAqpU6a7yzMs4DX653QE1QIhALYq6CScy9lp
9F2zVwV+Ue7+ba77AY5jnstwXZmXk26dAHYAfT7y+I//iFVoJMLAyp5SiXkrxQ54
CX8uapdomX4i8NcAAAF7j21nMgAABAMARzBFAiBH3KwPCCBhDy92kNSje9PmEns9
UywXDIL/LydlgMfyHgIhAOZ3MT39G/ruESsclRglNMdPbx5d9oDBjU6VjBeQiO1W
MA0GCSqGSIb3DQEBCwUAA4IBAQAaKfOhb84omVF9Ly4i9Rb7tQnlEkz0OhW3WttI
q5esPBUDsAzOpBi/0M4axovo/RaecC6D6Qu0cr9iL9z6n0LfY0reVHiaYaxi+R9Y
g29wa8PxYNDT7eAYBNTTIQ5bNG6YvI+oQ6dy/eulPmi1uGWBCC0mE9/eZDzEVvfD
1PpTfdXa8SHFuhEQMc5ym88cqYPEV9Z2UNf4I00ZQMBIFAhB9bPNjxkuDLOYksMO
zBxkNP/OyrLKVRnuXYkMvdqK62MdjpVEkXH4qPAC6E5ZY5q2NhfmNYYFv90YdLYH
5hICxfiT/wx4IAQdD6vb+Itc4yFfjjd8iTyuB/xpMV6Q5L0U
-----END CERTIFICATE-----
subject=CN = autodiscover.mtcom.ws
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3425 bytes and written 463 bytes
Verification: OK
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 3072 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 303F0000AB20BFED9D36D7D64595E42A180A721405A219BBA7A70D176094E808
Session-ID-ctx:
Master-Key: 3FDB4A2601AB23F1535CED8F5829F7B9B9824A69A0389647CC82062768A84B8275B7C625317C881ECF51C382D80E55DE
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1633094979
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
220 autodiscover.mtcom.ws ESMTP MailEnable Service, Version: 10.31--10.31 ready at 10/01/21 21:29:38
My certs have been updated with the X1 root and i still am having issues. Any firewall i've got thats doing ssl inspection is mad.
same issue here, according to their notes the X1 is valid, i get errors too..smh
There is a parameter to set it to use the alternate chain.
I thinks it implemented as:
--preferred-chain "ISRG Root X1"
[but don't quote me on that - I've yet to use it]
Hello @rg305 and thank you for all of your time and effort.
Since yesterday morning, my site (which uses Let's Encrypt for certificates) started showing a "Your connection is not private" message in certain instances and many clients stopped being able to access it. It did not have to do with older/newer devices as many new devices are experiencing this problem as well.
My site runs through nginx (nginx/1.14.0) on Ubuntu (18.04.5 LTS). I began by using an SSL checker and it reported that "This server's certificate chain is incomplete. Grade capped to B." even though the certification path showed server --> R3 --> ISRG Root X1. I went into the code in ubuntu and checked /usr/share/ca-certificates/ to remove mozilla/DST_Root_CA_X3.crt but it was already gone. I also went into /etc/ca-certificates.conf to comment out mozilla/DST_Root_CA_X3.crt but that was already taken care of as well. I ran sudo update-ca-certificates which did not change anything. I also rebooted the Ubuntu server and tried stopping and restarting nginx to no avail. It seems like everything should be working, yet it still doesn't let many users (not all) access the website.
I have been working to debug this problem since yesterday morning to no avail. I would really appreciate your help as we have many clients trying to access the site unsuccessfully.
Hi @abu1, welcome to the LE community forum
No problem, what is the FQDN?
Move away from using the long expired trust path to the shorter path.
It may impede older Android devices from reaching your site - so it's an executive decision that you will need to make.
Old Androids users or Chrome users?
Just got a new certificate via certbot / letsencrypt. Why is there still DST CA X3 the root cert?