Yes, you can simply remove the last cert ("DST Root CA X3") from the fullchain.pem file.
OR
Do that and also replace the "ISRG Root X1" cert with the self-signed version (so remove the last two and add one back in)
Self-signed: der, pem
2 Likes
Found this, propably too many cert renew requests?
1 Like
Same issue here - Mac OS X 10.11 El Capitan and getting lots of errors. I found discussions of it elsewhere and the workaround I found is to open Keychain app, look at System Roots
Open that certificate (double click on it - the one highlighted above) and towards the top there is "Trust" label with an arrow next to it. Click the arrow to expand it and then in the top box change the option to "Always Trust".
However, my assumption would be that this in theory may open up my/your system to some hypothetically bad things if someone figures out a way to exploit this 'always trust' approach.
Ideally I'd like to find some guidance on how to delete this cert and replace it with an updated one, but I suspect that this either (a) needs skills and understanding I may not have unless it IS explained like I am 5 or (b) can only be done by Apple (who, of course, just won't).
But I'll keep looking later - for now I need to get back to some real work.
1 Like
Hi @GeoL, welcome to the LE community forum 
"DST Root CA X3" as the name implies is a ROOT certificate and thus is/was "always trusted" already.
It became "untrusted" (to most systems) for no other reason than it simply expired.
Some systems don't even look at the expiry date of a trusted root (once a trusted root - always a trusted root).
So the questions are...
What exactly changed when you "always trusted" it?
Did anything improve?
What difference did it make?
Did Safari stop throwing certificate warnings?
[please tell us that something good will happen]
4 Likes
So, this solved the NET::ERR_CERT_DATE_INVALID problem, thank you!
...however, now older clients (i.e. Chrome 67 on Mac Mavericks, never gonna get an update) object to the R3 issuing authority!?
NET::ERR_CERT_AUTHORITY_INVALID
NET::ERR_CERT_AUTHORITY_INVALID
Subject: ogreets.com
Issuer: R3
Expires on: Dec 30, 2021
Current date: Oct 1, 2021
PEM encoded chain:
-----BEGIN CERTIFICATE-----
MIIFLDCCBBSgAwIBAgISBMiUPJAysi5bSu4cwndfIXZIMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTEwMDExMDE2MTdaFw0yMTEyMzAxMDE2MTZaMBYxFDASBgNVBAMT
C29ncmVldHMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtinL
WkpU/l0nJoLczWW+eHgcm1n1ZPYJBV/1TeH02w4pk/FlrStc2PY/Jz7MlBLUqCat
+tQyqZRjeCqpywI66z56v5F77gRs7frOhlSROx33JhAEd2zPS2mlOd7fG7ZPwW9D
GymLUiIPqV8YJKk+F5/rDNVkyN+CE3+giRbyE0VimFbgAPKj8MMT0RcMgnhHid0z
2aAK/s+fn1sDY5ygD+It48lUqnFcm0T+NlTEoyBPK2JwIDn611di+Yg9gPZaLJYT
0kXO1WHfTB+TeH2v7FFgFGarEjq6Z9Zqg37kNCNc1xmkN1Ru+sKTckflO8WaKPB4
BwD69dVh2M/syqMGMwIDAQABo4ICVjCCAlIwDgYDVR0PAQH/BAQDAgWgMB0GA1Ud
JQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQW
BBTxWYJquSsW2p6nbcBfMGWadMvwqTAfBgNVHSMEGDAWgBQULrMXt1hWy65QCUDm
H6+dixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9yMy5v
LmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iub3JnLzAn
BgNVHREEIDAeggtvZ3JlZXRzLmNvbYIPd3d3Lm9ncmVldHMuY29tMEwGA1UdIARF
MEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0dHA6
Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBAwYKKwYBBAHWeQIEAgSB9ASB8QDvAHUA
RJRlLrDuzq/EQAfYqP4owNrmgr7YyzG1P9MzlrW2gagAAAF8O5G1JgAABAMARjBE
AiBEFoBLe/fEs0UBsGTim9pI0fe/rp+3tjNxIcniobcsKQIgBrwW3h8BhA4xOw/F
GudM/HX7ByoneFIbZI0yXyEw7RUAdgD2XJQv0XcwIhRUGAgwlFaO400TGTO/3wwv
IAvMTvFk4wAAAXw7kbT5AAAEAwBHMEUCIFioeJlMX2Fglv04xDRkV0rI86AIbaNG
X/xHUpfswxNbAiEA0lDBozgdN/L2jzZ8EJPl9Gn3MY4Rbk6DMJE9nuMtyWUwDQYJ
KoZIhvcNAQELBQADggEBAC4rWu8dHHsvO2BKdntZ6Ki2rmSNZ1AVM33dhboOGVh/
0CINWRrEXvvEy16xdAkE2TUnxRaElRoQRC9D5vQWjaDwjw81G4ipoWWhxj/T5RPg
Nnsw/ARjkwCFmOvCMmz5kCmG1yMKWeWDBxWNkUd+uarozFNkPlYGFuaKeJMemc4S
U0y0gIObO2E0APRgeHVNS7DdshvwypAg4ziinGGQjuIqVSyAGSvYNLiHRjZ0dUBk
nSv6QwLlzk8B2gT2ZMw8Yjlq4G+KgSvvG8DoJJSy6oYvmrPnBRqTwAdGJffC8Fjl
ICPo1RfelNTCPTXapIc3Ys1+pG3dugNd24MXnhv8Zwg=
-----END CERTIFICATE-----
-----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-----
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMTUwNjA0MTEwNDM4
WhcNMzUwNjA0MTEwNDM4WjBPMQswCQYDVQQGEwJVUzEpMCcGA1UEChMgSW50ZXJu
ZXQgU2VjdXJpdHkgUmVzZWFyY2ggR3JvdXAxFTATBgNVBAMTDElTUkcgUm9vdCBY
MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAK3oJHP0FDfzm54rVygc
h77ct984kIxuPOZXoHj3dcKi/vVqbvYATyjb3miGbESTtrFj/RQSa78f0uoxmyF+
0TM8ukj13Xnfs7j/EvEhmkvBioZxaUpmZmyPfjxwv60pIgbz5MDmgK7iS4+3mX6U
A5/TR5d8mUgjU+g4rk8Kb4Mu0UlXjIB0ttov0DiNewNwIRt18jA8+o+u3dpjq+sW
T8KOEUt+zwvo/7V3LvSye0rgTBIlDHCNAymg4VMk7BPZ7hm/ELNKjD+Jo2FR3qyH
B5T0Y3HsLuJvW5iB4YlcNHlsdu87kGJ55tukmi8mxdAQ4Q7e2RCOFvu396j3x+UC
B5iPNgiV5+I3lg02dZ77DnKxHZu8A/lJBdiB3QW0KtZB6awBdpUKD9jf1b0SHzUv
KBds0pjBqAlkd25HN7rOrFleaJ1/ctaJxQZBKT5ZPt0m9STJEadao0xAH0ahmbWn
OlFuhjuefXKnEgV4We0+UXgVCwOPjdAvBbI+e0ocS3MFEvzG6uBQE3xDk3SzynTn
jh8BCNAw1FtxNrQHusEwMFxIt4I7mKZ9YIqioymCzLq9gwQbooMDQaHWBfEbwrbw
qHyGO0aoSCqI3Haadr8faqU9GY/rOPNk3sgrDQoo//fb4hVC1CLQJ13hef4Y53CI
rU7m2Ys6xt0nUW7/vGT1M0NPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV
HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR5tFnme7bl5AFzgAiIyBpY9umbbjANBgkq
hkiG9w0BAQsFAAOCAgEAVR9YqbyyqFDQDLHYGmkgJykIrGF1XIpu+ILlaS/V9lZL
ubhzEFnTIZd+50xx+7LSYK05qAvqFyFWhfFQDlnrzuBZ6brJFe+GnY+EgPbk6ZGQ
3BebYhtF8GaV0nxvwuo77x/Py9auJ/GpsMiu/X1+mvoiBOv/2X/qkSsisRcOj/KK
NFtY2PwByVS5uCbMiogziUwthDyC3+6WVwW6LLv3xLfHTjuCvjHIInNzktHCgKQ5
ORAzI4JMPJ+GslWYHb4phowim57iaztXOoJwTdwJx4nLCgdNbOhdjsnvzqvHu7Ur
TkXWStAmzOVyyghqpZXjFaH3pO3JLF+l+/+sKAIuvtd7u+Nxe5AW0wdeRlN8NwdC
jNPElpzVmbUq4JUagEiuTDkHzsxHpFKVK7q4+63SM1N95R1NbdWhscdCb+ZAJzVc
oyi3B43njTOQ5yOf+1CceWxG1bQVs5ZufpsMljq4Ui0/1lvh+wjChP4kqKOJ2qxq
4RgqsahDYVvTH9w7jXbyLeiNdd8XM2w9U/t7y0Ff/9yi0GE44Za4rF2LN9d11TPA
mRGunUHBcnWEvgJBQl9nJEiU0Zsnvgc/ubhPgXRR4Xq37Z0j4r7g1SgEEzwxA57d
emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
-----END CERTIFICATE-----
1 Like
Hello,
I have this website eatntrack.ro and a mobile app that communicates with it. No problem accessing it from a browser, but for some old Android devices, the app cannot communicate with the server and I get a "CERTIFICATE_VERIFY_FAILED: certificate has expired" message. I suspect it has something to do with the Root CA X3 expiration. Is it anything I can do? The server is nginx and this is what I get for the chain:
---
Certificate chain
0 s:/CN=eatntrack.ro
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
---
The result of openssl verify -partial_chain -CAfile fullchain.pem fullchain.pem is:
fullchain.pem: O = Digital Signature Trust Co., CN = DST Root CA X3
error 10 at 3 depth lookup:certificate has expired
1 Like
This did not work for me:
$ openssl verify -CAfile fullchain.pem fullchain.pem
CN = guardiandigital.com
error 20 at 0 depth lookup: unable to get local issuer certificate
error fullchain.pem: verification failed
The problem I'm trying to solve is macOS clients accessing the site and seeing the "cert expired" message when I can't reasonably communicate steps they can do individually.
1 Like
Well, so far, Brave Browser has stopped throwing up 'site not secure' warnings.
Using Discourse on another site, though, with Safari, now tells me my browser is too old to work there. It does load the comments page where the warning appears at the top, but some images do not load.
But then I only use Safari as a secondary browser (to check when things don't work on Brave, is a typical use).
Will do further checks and edit this post if I find out more. But basically, it has stopped the "don't go there - it's dangerous - here be privacy and security dragons" messages, and the pages I've checked on Brave so far just loaded. I do need to try and see why Discourse, specifically, objects to this version of Safari.
PS re the 'it was always trusted anyway' point, I think the point was it was set to 'System Defaults', which presumably checks the date and throws up if it doesn't like what it sees. Changing it to 'Always Trust" must stop it looking. (??)
1 Like
@gossamer
Try:
openssl verify -partial_chain -CAfile fullchain.pem fullchain.pem
2 Likes
Here are the apache virtual host entries for this cert:
SSLCertificateKeyFile /etc/letsencrypt/privkey.pem
SSLCertificateFile /etc/letsencrypt/cert.pem
SSLCertificateChainFile /etc/letsencrypt/fullchain.pem
I also tried to follow the steps related to deleting the last two entries in fullchain.pem and replacing them with two new certs, reloading apache, and I don't believe that worked either.
1 Like
It now reports:
$ openssl verify -partial_chain -CAfile fullchain.pem fullchain.pem
fullchain.pem: OK
Does that mean the problem is fixed?
1 Like
Please show the public file:
And what version of Apache are you running?
- that is very old coding style - deprecated around version 2.4.8
- the SSLCertificateChainFile should never be the
fullchain.pem- try usingchain.peminstead (if needed)
3 Likes
NO, It just means that I'm smarter than the openssl query and I can make it say: UNCLE "OK".
I don't really know what problem you even have, so how can I can't say if anything is fixed or not?
What problem do you have?
How can I help you?
2 Likes
This is apache 2.4.48.
If I change fullchain.pem to chain.pem, should I also then delete the last two certs and replace them with the https://letsencrypt.org/certs/isrgrootx1.pem version?
And so now I'm not using fullchain.pem at all. Should it otherwise be referenced in my apache config?
1 Like
Then you can't use three lines for certs.
Use only two:
SSLCertificateKeyFile /etc/letsencrypt/privkey.pem
SSLCertificateFile /etc/letsencrypt/fullchain.pem #change this line
SSLCertificateChainFile /etc/letsencrypt/fullchain.pem #delete this line
3 Likes
Hello rg305, and thanks for your kind support efforts.
I am not clear on one thing:
is there a fix for websites/apps using certbot to enable old non-updated unsupported devices and browsers to use LE certificates moving forward?
I get that x3 expired and x1 is the right one moving forward, but I don't understand how to serve a website for old devices and computers.
certbot and haproxy working great for 4 years until yesterday...
2 Likes
Hello!
I'm facing an SSL certificate error with a certificate issued by Let's Encrypt. In particular the chain is composed by the following certificates:
0 s:CN = [mydomain].westeurope.cloudapp.azure.com
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
The second one corresponds to the DST Root CA X3 (R3) certificate, expired a few days ago.
I'm no SSL expert, and I ensured I got the latest version of the machine I'm interrogating the API with (which is Ubuntu 20.04). Is there any way I can check whether it's a server-side problem, or a client's?
The full openssl command's result:
CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=2:unable to get issuer certificate
issuer= O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=0 CN = [mydomain].westeurope.cloudapp.azure.com
issuer= C = US, O = Let's Encrypt, CN = R3
verify return:1
---
Certificate chain
0 s:CN = [mydomain].westeurope.cloudapp.azure.com
i:C = US, O = Let's Encrypt, CN = R3
-----BEGIN CERTIFICATE-----
MIIF3DCCBMSgAwIBAgISAwAYbw7NYrr+fkoHrxvizKMVMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA3MjYwODEzMzBaFw0yMTEwMjQwODEzMjhaMDYxNDAyBgNVBAMT
K2JpZGV2b2FscHByb2Qud2VzdGV1cm9wZS5jbG91ZGFwcC5henVyZS5jb20wggGi
MA0GCSqGSIb3DQEBAQUAA4IBjwAwggGKAoIBgQCalU6WhB/cDBzgipv7HDOHnBwP
U14i3vSEr0d+w4XQAYZggcZQRYdr4GYe71JHDtcgieAnA+g8MGNQIBao1DNEoYta
vhKhjne2R61RBPrD7x1bB3/+nAAMvJZnp3Fj9KWHovu3caYf2kfm04i1B0I+exmW
vrABqLVQ4jMVUp9JmutFI/cPD5FkKFtBqbsDEm2Sl4mXXTr4qd6aJ8PbvvhSnwrr
jPFZucz+jQPPNAfewYWgbR0l89HMZbtBTP+OUi8hEDbPO9nuvPJxRhUyXb07Ib5d
Gg1HvDLLd7IpsJc1kAXx4RH6F6KzdgQNxSFdDFXosMoLAO4B/Lbn0RUXrBQWT5pQ
vKi+PyydCqa3CMPnA3r8+g7lVZ0X54YfyAFcFc97tm12Lhge7JvW+cWxu3ZJS0Dh
Wn7W+3i0FRc+/kkULMPB/SdEh2ES/4bM05X0g3ZbAPkH+6bZYHHenhtSHnfG+ma1
jbLAdspzQIT2etZzJH8mzyOQXaHWtgwvGz8RFi8CAwEAAaOCAmYwggJiMA4GA1Ud
DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0T
AQH/BAIwADAdBgNVHQ4EFgQUXW4Nle6TI4Q9r7OcD0aQnxb7eWswHwYDVR0jBBgw
FoAUFC6zF7dYVsuuUAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUF
BzABhhVodHRwOi8vcjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9y
My5pLmxlbmNyLm9yZy8wNgYDVR0RBC8wLYIrYmlkZXZvYWxwcHJvZC53ZXN0ZXVy
b3BlLmNsb3VkYXBwLmF6dXJlLmNvbTBMBgNVHSAERTBDMAgGBmeBDAECATA3Bgsr
BgEEAYLfEwEBATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0
Lm9yZzCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB2APZclC/RdzAiFFQYCDCUVo7j
TRMZM7/fDC8gC8xO8WTjAAABeuIXOOAAAAQDAEcwRQIgfqXw1ITjs0wNNZms/nMW
l66g1I+gZYnJQ3LeP4iwrHwCIQDjp3a3LIGpq/x5NXgSuEHmE/lFIBDdRIDSA2mp
cAdEDgB2AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEAKQaNsgiaN9kTAAABeuIXORcA
AAQDAEcwRQIgJKYV8+A6kv4bQMW/IcSYOVOchMBAkQDPJ1i8woLLTcUCIQDJTwR/
CAA1ych9bQCPPS+MNb7H27Z5pEEM4J2NfQ2upjANBgkqhkiG9w0BAQsFAAOCAQEA
qVfB89RdAupNtihc8JuwRMWc8ihPBD70Nt1KWb5Qypo/mAx44Zp5AXuELmRn+WsC
t4VLvLGaaq0mXmgwN+FY5l83RUYUtmzJtkQwTEFEXwNU+jwCEZ1DCO1hKIy49Iak
15S5txm0ytbx4ZjvQUcaA1Le9IvF480a1zJEC3M6wqh18G1Unrw5Yi3UaKNuZvsz
wT/fTXKlEE1K7cu3hsHkTsv0YleGNA6AJMdbi3jmJl03pEnqkkEIq30axUdPPyvw
XZH34wyF32ff5fE1jqPUvcQUSo7K5N0SxRBuX4w/6ZfTcazBzViv5hPt790srXck
+iknVHehRBD7hBjUZEfEcQ==
-----END CERTIFICATE-----
1 s:C = US, O = Let's Encrypt, CN = R3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
-----BEGIN CERTIFICATE-----
MIIEZTCCA02gAwIBAgIQQAF1BIMUpMghjISpDBbN3zANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTIwMTAwNzE5MjE0MFoXDTIxMDkyOTE5MjE0MFow
MjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxCzAJBgNVBAMT
AlIzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuwIVKMz2oJTTDxLs
jVWSw/iC8ZmmekKIp10mqrUrucVMsa+Oa/l1yKPXD0eUFFU1V4yeqKI5GfWCPEKp
Tm71O8Mu243AsFzzWTjn7c9p8FoLG77AlCQlh/o3cbMT5xys4Zvv2+Q7RVJFlqnB
U840yFLuta7tj95gcOKlVKu2bQ6XpUA0ayvTvGbrZjR8+muLj1cpmfgwF126cm/7
gcWt0oZYPRfH5wm78Sv3htzB2nFd1EbjzK0lwYi8YGd1ZrPxGPeiXOZT/zqItkel
/xMY6pgJdz+dU/nPAeX1pnAXFK9jpP+Zs5Od3FOnBv5IhR2haa4ldbsTzFID9e1R
oYvbFQIDAQABo4IBaDCCAWQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8E
BAMCAYYwSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5p
ZGVudHJ1c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTE
p7Gkeyxx+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEE
AYLfEwEBATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2Vu
Y3J5cHQub3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0
LmNvbS9EU1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYf
r52LFMLGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0B
AQsFAAOCAQEA2UzgyfWEiDcx27sT4rP8i2tiEmxYt0l+PAK3qB8oYevO4C5z70kH
ejWEHx2taPDY/laBL21/WKZuNTYQHHPD5b1tXgHXbnL7KqC401dk5VvCadTQsvd8
S8MXjohyc9z9/G2948kLjmE6Flh9dDYrVYA9x2O+hEPGOaEOa1eePynBgPayvUfL
qjBstzLhWVQLGAkXXmNs+5ZnPBxzDJOLxhF2JIbeQAcH5H0tZrUlo5ZYyOqA7s9p
O5b85o3AM/OJ+CktFBQtfvBhcJVd9wvlwPsk+uyOy2HI7mNxKKgsBTt375teA2Tw
UdHkhVNcsAKX1H7GNNLOEADksd86wuoXvg==
-----END CERTIFICATE-----
---
Server certificate
subject=CN = [mydomain].westeurope.cloudapp.azure.com
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-384, 384 bits
---
SSL handshake has read 3288 bytes and written 493 bytes
Verification error: unable to get issuer certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
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-GCM-SHA384
Session-ID: 141000006A84D6801C677B8A29C2739A786C23CC39DBD701D0429242D18EFE11
Session-ID-ctx:
Master-Key: 27A7363E3F1FDD02ECA81B2C6B00CDC1D7EBF92B9F031E03CABCCA0992E00755D90A2A99DCCE778B4C02A1A440BBD318
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1633087058
Timeout : 7200 (sec)
Verify return code: 2 (unable to get issuer certificate)
Extended master secret: yes
---
read:errno=104
Thank you very much.
2 Likes
I have an odd problem with an iPhone on iOS 14.
Since yesterday it keeps saying that it can't connect to a mail server and that the SSL Certificate is not trusted. The SSL Certificate has a certification path ISRG Root X1 - C=US,O=Let's Encrypt,CN=R3 - domain name. The certificate is valid from 29.8.2021 to 27.11.2021, so it should be perfectly fine, and the certification path is also not the problem (it seems).
But somehow that iPhone still complains and doesn't accept the connection. Is there a way to release a cache or something in the iPhone? Various other phones, even an older iPhone with iOS 12 have no issue to get new emails.
1 Like
Hello there , im facing the same problem that majority does.I get the not secure sign when using older browser and os. For example W7 and google chrome. Is there a true solution for this ?I have read the whole thread but not sure which solution works or not. I am novice at this but the problem is i cant tell all my clients to update their software so i have to do this server side.Please provide me a stepped solution if you can.
3 Likes
I can't forsee a fix to any systems that are no longer even maintained.
I can imagine some creative workarounds popping up [but even those will have a short lifespan].
Like: analog cell-phones
[one day they just stopped making/receiving calls]
2 Likes