If you are going to server old Android devices then you will need to serve that trusted path.
The one being served it NOT that one.
[there are three trust paths - that one is the worst of them]
If you are going to server old Android devices then you will need to serve that trusted path.
The cross-signed ISRG Root X1 does not need to be in Trusted Roots, only Intermediate. The DST Root should remain in Trusted Roots. It is also important to distinguish whether you made these changes in the Local Computer stores or the SYSTEM user's stores. Untrusting the self-signed ISRG Root X1 will do less damage if it is only untrusted by the SYSTEM user and not the whole computer. Here's an article I wrote on the specifics:
But you also still need to look for any remove any existing copies of the expired R3 certificate that likely still exist and are causing problems getting the new chains (either of them) to be served. You can either do that manually or using the script I linked earlier in the thread.
The need for system administrators to intervene to force the default chain in windows environment is frustrating. The default chain served by the ACME client via API really makes no difference if you are hosting a site with IIS, since it continues to serve only the alternative chain.
Until hours ago my Server with Windows Server was serving the long chain without requiring any intervention. But after he automatically obtained the ISRG Root X1 certificate via Windows Update, it went on to serve only the short chain.
When moving the self-signed certificate "ISRG Root X1" to "Untrusted Certificates" will not cause the ACME client to be unable to establish SSL connection to the Let's Encrypt API during the renewal or issuance of a new certificate?
The Let's Encrypt API uses the self-signed ISRG Root X1 certified short chain.
It is frustrating, especially when it requires this sort of hacky solution. I feel you. But it's the double-edged sword of using an OS that tries to help you out with low level stuff like this. You've never even had to think about certificate chains until now because Windows just handled it. But now that you do, you realize you don't have the level of control you'd like. Arguably, you've still been better off than the Linux folks who have unknowingly been serving no chain for years causing issues with who knows how many clients.
You are correct that the API currently serves the short chain (which makes sense because there aren't a lot of ACME clients running on old versions of Android). But in my very limited testing on a single instance of Windows Server 2019, untrusting the self-signed ISRG Root X1 cert on the SYSTEM user does not fully break LE validation for the SYSTEM user. It only breaks validation against sites using the long chain (such as the main Let's Encrypt website). Here's a test I ran on my server that is currently serving the long chain using my method following a reboot:
I've launched PowerShell as the SYSTEM user and attempt to connect to both the Prod API endpoint and the main Let's Encrypt website. The API endpoint works, while the website throws an SSL error.
And like I mentioned in the article I wrote, it doesn't break any validation for other users on the same system because they all see the self-signed
ISRG Root X1 as trusted. So even if on some other combination of OS/patch level it does break LE validation entirely for the SYSTEM user, you can just change your renewal task to run as a different user.
Excellent work. Thank you so much for the clarifications.
Thanks a ton! @rmbolger
It helped a lot, the issue has been resolved and working perfectly on older devices.
Let's Encrypt community is very supportive and thanks a lot to experts like you who are working hard day and night to support this community.
You can follow the below steps, I've tried to make it simple.
Note: These changes I've made on Windows Server 2012 R2.
Do not remove the DST Root CA X3 certificate (Expired on 30/09/2021) from Trusted Root Certification Authorities.
ISRG Root X1 certification self-signed and cross-signed both should not be in Trusted Root Certification Authorities.
ISRG Root X1 certification self-signed (Expires on 04/06/2035) should be in Untrusted Certificates.
ISRG Root X1 certification cross-signed (Expires on 30/09/2024) should be in Intermediate Certification Authorities.
Remove old R3 certificate from Intermediate Certification Authorities.
Add current R3 certificate (Expires on 15/09/2025) to Intermediate Certification Authorities.
After completing the above steps server reboot is mandatory to reflect the changes.
That's all! Your issue is resolved 100%
You can use Namechep SSL Checker to verify the chain being served.
We've resolved the issue for this website
Our clients are happy after this solution.
Have a great day! Again thanks to @rmbolger and the Let's Encrypt community.
Glad I was able to help. Cheers!
I asked my users that have this issue to test your website, and it does not work at all. They still have an issue with their certificates. They have windows 7 if it can help you.
Edit: I think that what misled you was maybe believing that opensea.io works for users with windows 7, but it's not so. All the users I communicate with still have an invalid certificate for opensea included. It bothers me deeply because in the last few years I've written a lot of scripts that rely on Let's Encrypt among others. But if you want to keep your site usable by all your previous users, i.e., like 2 days ago, you have no choice but to use another CA I think.
I notice that there is an error on the site: ACME CA Comparison - Posh-ACME zeroSSL does not offer free wildcards (I think). In fact LE was the only one to offer them and that's why it's a huge problem for me.
A post was split to a new topic: Ubuntu Android problem
This solution could be useful for those who can't search for their own certificates on their own servers, well I can't really imagine how it's possible to not know how to use a search tool by file extension but let's move on.
On the other hand this solution is simply impossible for the client side. Only a very small minority of people will find this script, and even fewer will be able to use it.
Not to mention that cloudflare still delivers the expired DST Root CA X3 for at least 25% of their users (for the free version) if I understand correctly.
I still have a lot of users with old devices, one could imagine that the most dedicated would click on the scary red message to use the website. But as soon as your application is a bit more complex and uses subdomains with XHR requests or uses WebRTC or WebSocket, it completely destroys your application for these users.
We are talking about 100m to 200m users in the world who still have windows 7? It touches a public obviously less rich by the way. It's pretty sad that Let's Encrypt doesn't care about them anymore (I hope I'm wrong).
I still have hope to find a workaround server side (only), but after a day of intense research I personally had to resign myself to use a paid CA to generate my wildcard certificates.
Thanks for your reactivity though.
Cloudflare has their own CA from digicert (but probably in name only, probablly still managed by digicert people), not impacted by this. you actually need business+ tier to use your on certificate
Edit: As I said it depends, I don't know how % you have to get a LE certs, but I would say 25%?
You need to pay if you want the possibility to change the CA tho.
Our testing team cross-checked with many clients on older devices and Windows 7 systems as well. And it works completely fine.
I must be mistaken about the nature of the problem and this topic. Maybe we are not talking about the same problem then. I'm talking about certificate validation. Here are the reports I got from my side.
I'm still actively looking for a backend only solution since I still have a few sites that have this problem.
Maybe it works in your specific case, I'm not sure, but as long need to do an XHR request to some subdomain/other page of your website it will break if the certificate is not valid.
Yes they do. But only via ACME, not their normal website interface. Their pricing page seems to be deliberately confusing so they can trick people into paying for certs. Take a look at this page instead. Here's the important part:
By using ZeroSSL's ACME feature, you will be able to generate an unlimited amount of 90-day SSL certificates at no charge, also supporting multi-domain certificates and wildcards. Each certificate you create will be stored in your ZeroSSL account.
My solution is only intended to help Windows server administrators configure their systems to serve the old Android compatible default chain instead of the more modern short chain. It definitely is not intended for client use and will break more than it fixes on clients.
I'm not sure what you mean by searching by file extension though. Windows certificate stores don't live on the filesystem. They're in the registry stored as binary blobs named after their thumbprint.
The vast majority of normal users running Windows 7 should be upgraded to Windows 10 by now. It has been a free upgrade practically since release in 2015. Upgrading is still free last I checked and just about any hardware that is capable of running 7 is also capable of running 10. Windows 11 is about to be released and yet Microsoft has committed to supporting Windows 10 until at least 2025.
That said, I'm not sure why you think Let's Encrypt has made a choice not to support Windows 7 users. Nothing that has happened in the past few days has been a choice. It's all part of the inevitability of web based encryption relying on a system of certificates that have expirations which can't be modified by anyone. Windows 7 is still perfectly capable of working with sites using Let's Encrypt certificates. I literally just spent an hour building a Windows 7 SP1 machine from scratch using a DVD image. I'm not even done patching it yet and I can already visit the Let's Encrypt website and API without any certificate warnings using IE 11.
You know what's interesting though? When I try to visit your site in IE 11 on that Windows 7 machine, this is what I see.
No certificate warnings, but a scary pop up demanding I change my web browser to something more modern. How can you cast aspersions about leaving old things behind when your own website does exactly that?
I understand you're frustrated and don't really understand what's going on. But maybe try being a little more compassionate and less passive-aggressive when asking for support from a community of mostly volunteers and a company that is providing services to the entire world for free. Everyone is doing their best.
Great message! Thank you and it is very enlightening. And wow this ZeroSSL thing could save my life then, and I was fooled by their pricing message ahah!
Indeed for the windows server administrator, the storage of the certs seems to be painful. Hah fool me, you nailed me.
I actually understand now that everything is planned in advance. And that there is no turning back. In the end the only solution is to find the last certificates supported by the largest number if I understand correctly? When I read all the messages I see many people with the hope to be able to solve their problem with Let's Encrypt (a bit like the OP currently) to solve this problem when in fact if I understand correctly it is impossible.
I can imagine that being able to postpone the deadline for a few years seems to be a residual artifact of your opinion (I'm just assuming), but for many others it is terrible.
I trust you if you tell me that the users of windows 7 are a very small number. Even if I am forced to note that I have had hundreds of messages from these users while the user base that uses my services is not so big. It's not an option for me to ask them to upgrade their system.
I bow to your answer! On the other hand, the IE11 comparison is still crude , and besides, it's not even my website, it's the OP's one. Although to reassure the OP I'm pretty sure that most websites are unusable with IE11 nowadays.
Again, thanks for your enlightening message and I'll look into ZeroSSL, it's honestly the answer I was looking for. Cheers!
Thank you very much @parth.patel! I had huge problems with older devices (Android 4.x) but after applying these steps, it seems to work
Just wanted to let you know, that I finally ended up in changing root authority to ZeroSSL.
While the solution made my application run on older devices, Certify The Web application couldn't auto renew certificates. Additionally, some users couldn't consume my APIs.
Using Certify The Web, switching to ZeroSSL was extremely easy. Now everything runs smooth again.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.