so there's nothing I can do server side to have those older clients be able to connect? it's simply up to the client to update their trust store if they are able?
If those older clients do not trust the
ISRG Root X1 cert, the only thing you can do server side is change to a different Certificate Authority that they do trust. Personally, I would try switching to the shorter chain first and seeing how those clients respond. But again, that will definitely break old Android devices.
For those looking for a fix with NodeJS 8, i've opened an issue on the github, but probably not going to do anything.
In the post i've writen the fix, but you gonna have to build your own version of Node unless they fix it.
I can Confirm a fix that worked on both a 10.9.5 & 10.11.6 Mac OS users. Simply set the DST Root CA X3 to "Always Trust" on several Mac's I manage in an office and home's this fix work for 4 websites that previously had issues with this CERT ERR.
Directions for fix:
- Open ~/Applications/Utilities/Keychain Access.app
- From View menu select "Show Expired Certificates"
- On the Left Sidebar pick System Root
- In search bar top-right type DST
- Double-click "DST Root CA X3"
- In pop-up, turn down "Trust" arrow and set "When using this certificate" to "Always Trust"
- Close the pop-up and put in an Administrator user/password info.
- Close all open Browsers & Keychain you should be good to go after that.
This expiry of DST Root caused me to really look at and understand my own setup And thank you all for helping each other here!
I had two issues:
- I had to remove the DST Root from my system store on the server because
openssl s_clientkept failing my tests.
- The existing
fullchain.pemfiles still had the DST Root CA X3 certificate in them which caused my webserver to continue to send it, causing failures on some clients. The solution was to force a renewal of the certificate.
I'm not using the
apache installer and authenticator, but instead use the
webroot athenticator as I found it better when using a mix of services:
# certbot --webroot --dry-run -w /var/www/domains/wiki.tnonline.net/htdocs -d wiki.tnonline.net -v certonly Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Certificate not yet due for renewal You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry. (ref: /etc/letsencrypt/renewal/wiki.tnonline.net.conf) What would you like to do? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: Keep the existing certificate for now 2: Renew & replace the certificate (may be subject to CA rate limits) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel):
I found that
certtool from the GnuTLS package is better to look at the full chain than with
certtool -i --infile /etc/letsencrypt/live/wiki.tnonline.net/fullchain.pem |less
14 posts were merged into an existing topic: Ubuntu Android problem
This is causing lftp to fail.
Certificate: C=US,O=Internet Security Research Group,CN=ISRG Root X1
Issued by: O=Digital Signature Trust Co.,CN=DST Root CA X3
ERROR: Certificate verification: Not trusted
Thanks! This fixed my problem.
Is this solution permanent? Do you know if it might break in the future?
Can i set auto renew using this approach?
So are you saying that just simply creating a new cert fixed the problem?
Yes. Because the fullchain.pem had the expired cert in it.
Didn't work for me, with lftp.
That's the approach I tried, but on my Xubuntu NextCloud server system the certificates are held in a core18 snap file. Trying to remove them results in an error as you cannot remove components of a live snap file, the snap file itself must be rebuilt without them. So I tried that using unsquashfs and mksquashfs but then the snap file wasn't recognised.
None of my NextCloud clients can connect; they all get a certificate error.
So I'm still looking for a solution.
Actually I did. Start with this article: DST Root CA X3 Expiration (September 2021) - Let's Encrypt
You must not be getting Windows updates (as is the case with me) for it to break. Otherwise an update would have already downloaded the ISRG Root X1 root cert. Chrome, strangely, uses Windows's root certificates, while Firefox manages its own. So FF works no problem. Here is what I did: In FF go to: about:preferences#privacy and scroll to Certificates. Click View and then find ISRG Root X1 root cert. Export it, it will be saved to, say, your Desktop. Then just import it to your Trusted Root Certificate Authorities store in Windows (it's easy, just google it quick). Worked like a charm for me.
Gonna try the update and if not the FF method.
It worked! I exported it from another PC that had it and imported it on the problematic PC.
Important confusion is not to double click, but to use the IMPORT function.
Precisely. I double clicked first also.
I had some trouble using Python 3.9 on Windows 10
The standard way (up to 2021-09-30) was:
Python 3.9.5 (tags/v3.9.5:0a7dcbd, May 3 2021, 17:27:52) [MSC v.1928 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib3 >>> http = urllib3.PoolManager() >>> ret = http.request("GET", "https://community.letsencrypt.org")
which now produced the exception
Traceback (most recent call last): File "C:\dev\git\playground-python\env\lib\site-packages\urllib3\connectionpool.py", line 699, in urlopen httplib_response = self._make_request( File "C:\dev\git\playground-python\env\lib\site-packages\urllib3\connectionpool.py", line 382, in _make_request self._validate_conn(conn) File "C:\dev\git\playground-python\env\lib\site-packages\urllib3\connectionpool.py", line 1010, in _validate_conn conn.connect() File "C:\dev\git\playground-python\env\lib\site-packages\urllib3\connection.py", line 411, in connect self.sock = ssl_wrap_socket( File "C:\dev\git\playground-python\env\lib\site-packages\urllib3\util\ssl_.py", line 449, in ssl_wrap_socket ssl_sock = _ssl_wrap_socket_impl( File "C:\dev\git\playground-python\env\lib\site-packages\urllib3\util\ssl_.py", line 493, in _ssl_wrap_socket_impl return ssl_context.wrap_socket(sock, server_hostname=server_hostname) File "C:\dev\Python\Python39\lib\ssl.py", line 500, in wrap_socket return self.sslsocket_class._create( File "C:\dev\Python\Python39\lib\ssl.py", line 1040, in _create self.do_handshake() File "C:\dev\Python\Python39\lib\ssl.py", line 1309, in do_handshake self._sslobj.do_handshake() ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1129)
Note: On Ubuntu 20.04 the above snippet still works out of the box, it was just Windows that caused trouble.
For Windows using certifi solved my problem.
>>> import certifi >>> import urllib3 >>> http = urllib3.PoolManager(cert_reqs="CERT_REQUIRED", ca_certs=certifi.where()) >>> ret = http.request("GET", "https://community.letsencrypt.org") >>> ret.status 200
Hi @mpapenbr, welcome to the LE community forum
[and thank you for bringing the information of that problem and your solution to it into this forum]
Thank you so much everyone.
Using snap to run a newer version of certbot, and telling it to use --preferred-chain "ISRG Root X1" worked like a charm. Now my phone is back to happily running DOT through Stunnel.
The preferred chain option was automatically added to /etc/letsencrypt/renewal/MyServer.conf as:
preferred_chain = ISRG Root X1
So on next renewal it will not break the chain.
So then what did you do after getting rid of ca x3, recreate the certificate?