Well! I have very serious issues with connecting from iOS devices (ver 14 and 15) to adobe connect servers. I have tried many ways and yet no sucess. As we we are providing online education medium, an urgent answer is a huge help.
Looking forward to hearing from you.
1 Like
Hi @sherrikalak,
ISRG Root X1 has been supported since iOS 10 and so in principle these devices should still be able to interoperate with sites using Let's Encrypt certificates. An error in connecting would probably mean that the intermediate certificate sent by the server is incorrect. (For example, it could have hardcoded an expired intermediate certificate, or fail to send any intermediate certificate at all.)
Could you give an example of a domain name that you're having problems connecting to? Alternatively, you could test with https://ssllabs.com/ and look for any errors in the "Chain issues" section, which would likely provide a useful diagnosis.
4 Likes
Hi @sherrikalak welcome to the LE community forum 
That is key to understanding the problem.
2 Likes
A bit off topic but...
It's unfortunate that IdenTrust didn't consider the issues they would cause when they issued their root certificate on September 30, 2000.
That aside, this is a good thing for web PKI. Many root certificates were issued in the early 2000s, this type of expiry is going to happen much more frequently.
Because of this unavoidable event, Let's Encrypt is shaking things up a bit and seeing what bolts fall out. We can learn from this event so future root expiration are handled more gracefully.
EDIT: I do not appreciate my posts being edited without my knowledge. Please see the original quoted context here Help thread for DST Root CA X3 expiration (September 2021) - #1208
3 Likes
Thanks Schoen! Your tip about ssllabs.com saved me! I directed the admins to repair the chain and it seems it worked!
5 Likes
The reissue problem with acme.sh drove me nuts.
According to https://github.com/acmesh-official/acme.sh/wiki/Preferred-Chain the default is still 'DST Root CA X3'.
But even when I force reissued with --preferred-chain "ISRG Root X1" or Le_PreferredChain='ISRG Root X1' I got the fullchain with the now expired 'DST Root CA X3' in the chain
Certificate chain
0 s:/CN=domain.tld
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
Somebody said that they had to re-issue the certificate. Since force didn't work. I tried to delete and issue again only to learn that acme.sh now uses zerossl by default.
https://community.letsencrypt.org/t/the-acme-sh-will-change-default-ca-to-zerossl-on-august-1st-2021/144052
Came across the switch to continue using letsencrypt
acme.sh --issue --domain 'domain.tld' --dns dns_pdns --debug --server letsencrypt
Trying to switch back with this is still unconfirmed since I had to give up because of the rate limits.
I really would have appreciated LE raising those limits during such vital changes.
For now I had to switch to zerossl to keep everything running
And I still don't know if it will be fine next time since I can only continue my tests next week.
1 Like
did you upgrade to the verison:
acme.sh --upgrade
3 Likes
Yes, I did that after the first trying to just re-issuing it. I mean the certificate chain get's generated by the API from letsencrypt, they would know what goes into the chain, right 
With the upgraded version I tried to delete (rename the conf file) the certificate and reissue it. This came up with a certificate from zerossl. This might be fine for many. I didn't want to research this switch right now and wanted back into the letsencrypt ecosystem.
1 Like
acme.sh --set-default-ca --server letsencrypt
4 Likes
Yes, I hope this is going to be it. Can't try it right now for this domain, because of rate limiting.
1 Like
Hi! Newbie in this forum. Kindda need some help which I think is related to this topic. Our users keep on seeing Connection not private.
We're experiencing this also with our learning management systems. Good thing that it's not happening in the majority of our users. We've tried some troubleshooting which only worked on a couple of users.
Those troubleshooting are Clear Cache and Cookies, uninstall and reinstall their main browser, double checking if the time & calendar of their desktop is sync, made sure that their browsers are up to date.
I know this isn't much related to the clients OS but those users of our system that affected by it are the ones using windows 7 with a bit old PC, and a handful of windows 10 with updated PCs.
But we still have many users which uses windows 7 with old PCs which didn't encounter this connection not private issue.
1 Like
The fact that there is still the expired X3 certificate in the full chain causes .NET / Mono / Xamarin classes like WebClient, HttpWebRequest and others to fail.
An attached ServerCertificateValidationCallback receives sslPolicyErrors=RemoteCertificateChainErrors as a parameter with 4 certificates in the "chain" parameter (my own, the intermediate, the ISRG Root X1 and the expired DST Root CA X3).
Microsoft's example code on RemoteCertificateValidationCallback Delegate (System.Net.Security) | Microsoft Docs shows to just check for sslPolicyErrors.
There is no way for my application (and probably .NET/Mono/Xamarin) to know which of the certificates in the chain are trusted root certificates and when it MUST early-exit before it fails on expired roots.
Our server APIs are currently not accessible from mobile Android/Xamarin clients due to this and I have no idea how to fix this other than moving to a different CA without expired roots in the chain.
1 Like
3 posts were merged into an existing topic: I have IdenTrust 1 and my Mac OSX is still screwed
7 posts were split to a new topic: Long chain gives warnings in Qualys SSL Server Test
So, that is showing only path #1. That may indeed work for us as we have a ver specific list of browser versions we support for out sites. How do I change my certs to only use/serve the good chain? And if need be, how to switch back?
1 Like
Is anyone running FreeIPA with letsencrypt certs? I've been using them for both the web and LDAP servers, and could always install a new cert with ipa-server-certinstall . Now however I get this error message and cannot install the new certificates
CA certificate CN=DST Root CA X3,O=Digital Signature Trust Co. in /etc/letsencrypt/live/XXX/cert.pem, /etc/letsencrypt/live/XXX/privkey.pem is not valid: certutil: certificate is invalid: The certificate issuer's certificate has expired. Check your system date and time.
The ipa-server-certinstall command failed.
1 Like
You need to specify "ISRG Root X1" as your preferred chain when generating certificates. The exact process for doing so will depend on what software you're using.
As for switching back, if you stop specifying a preferred chain then you'll go back to generating certs with the default chain.
1 Like
I work on a macbook (Catalina 10.15.7) and develop a webapp on my local machine. I use the mailtrap.io email testing service to check outgoing emails. I haven't changed anything, but a few days ago the mailtrap service gives back the below error message:
ErrorException stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Illuminate\Foundation\Bootstrap\HandleExceptions::handleError vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/StreamBuffer.php:94
Mailtrap advises the following:
Regarding SSL error while trying to send emails to Mailtrap: You are not alone. Please update your OpenSSL version You might hear about the global issue with Letsencrypt certificates: its old root certificate expired on Sep 30. Mostly it impacted clients who use OpenSSL versions prior 1.1.0. The most common solution is to update your OpenSSL. If you can’t do that read the recipe for v.1.0.2 from OpenSSL.
My first approach was to remove the expired certificate and install the some new ones. I removed the DST Root CA X3 section from /etc/ssl/cert.pem file and removed all DST Root CA X3 instances using the Keychain Access app. Then I installed the ISRG Root X1 and ISRG Root X2 using the Keychain Access app setting them to always trust. Unfortunately I still get the same error message after rebooting.
The secong approach would be update OpenSSL on my machine. The "openssl version" command tells me that I have LibreSSL 2.8.3 on my machine, so I assume this is what I need to update. Checking the libreSSL release notes it seems that there already a fix for this problem. But I'm a little concerned that I mess-up my mac with this procedure.
Am I on the right track? Should I update LibreSSL to the latest version? How do I do that? Are there any side-effects? Are there any better solutions to this problem?
Any advice would be highly appreciated!
Thanks! W.
1 Like
2 posts were split to a new topic: Expired R3 chain
I have not yet been able to figure out how to issue that command successfully. Using certbot on Ubuntu with Nginx. Tried
sudo certbot --preferred-chain "ISRG Root X1"
2 Likes