Some Web Sites Will Stop Working With El Capitan and Older
On 30th September 2021, the root certificate that Let’s Encrypt are currently using, the IdentTrust DST Root CA X3 certificate, will expire. You may or may not need to do anything about this Root CA expiring, but I’m betting a few things will probably break on that day so here’s what you need to know!
[…]
In normal circumstances this event, a root CA expiring, wouldn’t even be worth talking about because the transition from an old root certificate to a new root certificate is completely transparent. The reason we’re having a problem at all is because clients don’t get updated regularly and if the client doesn’t get updated, then the new root CA that replaces the old, expiring root CA is not downloaded onto the device.
[…]
In the last year alone, Let’s Encrypt have grown their market share quite a lot and as a CA becomes larger, it’s certificates enable more of the Web to operate and as a result, when something like this comes along they have the potential to cause more problems. This is nothing to do with what Let’s Encrypt have done, or have not done, this still comes down to the same underlying problem that devices out in the ecosystem aren’t being updated as they should be.
[…]
Because old Android devices don’t check the expiration date of a root certificate when they use it, Let’s Encrypt may be able to continue to chain down to the expired root certificate without any problem on those older devices.
If you’re still running El Capitan, or any version of Mac OS X prior to 10.12.1, then you’re about to run into problems with some popular security certificates.
macOS 10.11 was only superceded five years ago, and some older hardware can’t run 10.12. On the iOS side, an iPhone 4S can’t update to iOS 10. I get that Apple doesn’t want to provide security bug fixes that far back, but how hard would it be to have a mechanism for updating the root certificates? (Then again, even the Mac App Store no longer works properly on macOS 10.13 due to a bad CSS URL.)
Let’s Encrypt is quite popular now, and there are other certificates issued using the same root. Lots of sites will break, and users won’t know what to do.
This blog and the C-Command forum use Let’s Encrypt, and they are set to redirect HTTP to HTTPS. I haven’t decided how to handle this yet. So far, it seems like the only options are to accept the breakage or to buy a certificate from another provider.
The main C-Command site (which my apps use for automatic software updates) uses a different certificate that should continue to work. One of the mirror download sites does use Let’s Encrypt; if you get an error due do that you could try again until you get the non–Let’s Encrypt mirror.
Previously:
Update (2021-10-04): Commenter “a” and Stefan Reitshamer have posted instructions for how to download a new root certificate so that certificates from Let’s Encrypt and others can still be trusted on macOS 10.11.
A few days ago I warned that those still using older versions of Mac OS X are likely to have problems making secure HTTPS connections with many websites, because of a security certificate due to expire on 30 September. Unfortunately, it has turned out that this isn’t confined to older Mac OS X, and can even affect Monterey betas. And there’s more than one certificate which has now expired.
[…]
Although this is a Let’s Encrypt certificate chain, the first of the certificates to expire wasn’t its DST Root CA X3 which we were warned about, which remained valid at the time that this happened to me. The first certificate to expire was the intermediate R3, which expired on 29 September, a day earlier.
[…]
So how come two different Macs connecting to the same site get such different chains of trust?
The answer I suspect lies in the caching of certificate checks. Both my iMac and iPhone have connected to this site previously, and rather than performing a full certificate check every time, macOS is just using old results, which still refer to the old intermediate and Root certificates. My M1 Mac mini had never connected to that site, so had to perform a fresh check on the chain of trust, which then traced back to the current chain with its replaced intermediate and Root certificates.
In the rest of this article, I’ll focus on the use of security certificates for one of their most common purposes, in establishing a secure connection to a remote server using the HTTPS protocol, using Transport Layer Security (TLS), which long ago was known as the Secure Sockets Layer (SSL) and is still occasionally referred to incorrectly as being SSL.
Since the first of those security certificates expired on 29 September, there’s been a steady stream of comments from ordinary users, those operating small websites, developers, and system administrators, documenting far more extensive consequences than any of us had anticipated.
[…]
When your browser blocks or warns you about a site you want to visit, don’t just blunder on assuming that you’re right. You might be, but you have at least to wonder what’s wrong, and whether that’s a warning in itself. Check the site’s certificates and think through the implications of any error messages. If the identity on the leaf certificate doesn’t match the site you’re trying to connect to, be extremely wary, as that’s a common ploy of impersonators.
To understand why current versions of Safari appear to be having problems connecting to some sites, particularly those affected by the recent Let’s Encrypt certificate changes, I’ve been exploring what’s recorded in the Unified log. This article casts more light on the checks which Safari runs, and how they can fail.
See also: Reddit.
Previously:
Update (2021-10-08): See also: Reddit, Let’s Encrypt.
Update (2021-11-12): Howard Oakley:
Many users are continuing to report problems trying to connect to some websites, which reportedly have broken certificates. This comes a month after the fiasco with the Let’s Encrypt root certificate, and affects some other root certificate authorities, including IdenTrust. This article explains how you can deal with these and similar problems in both current and older versions of macOS.
135 Comments RSS · Twitter
FYI, the Mac App Store CSS problem on 10.13 has been fixed for a month or two.
You can export all root certificates from a modern iteration of macOS and import them into the Keychain on the older OS X And everything will work again. Good luck!
@Nobody Yeah, that’s fine for more technical users who have older Macs, but it doesn’t help if you have a site that you want the general public to be able to access.
You can export all root certificates from a modern iteration of macOS and import them into the Keychain on the older OS X And everything will work again. Good luck!
Would be nice if someone posted that data somewhere for those not running a "modern" iteration of macOS, and the appropriate instructions.
Would be even better if websites that care could detect that the client will run into this issue and redirect them to a site that shows how they could download and import the new root certs into their Keychain.
Would that be possible, I mean the detection? I.e, is that info provided in the http headers?
@Thomas That would be great, but I don’t think the server will even receive the HTTP header if a secure connection can’t be made.
@Nobody, @Old Unix Geek
So, guys, really, what do we do now? I'm on macOs 10.11 aka El Capitan and literally half of the Internet is broken now :(
Any advises please?
@Old Unix Geek
@Alex
tl;dr:
(A little more information about how I arrived here *after* the instructions)
--------------------------------------------
1. Download this Root Certificate:
--------------------------------------------
NAME:
"ISRG Root X1"
(✅ Self-signed, ❌ NOT Cross-signed)
URL:
https://letsencrypt.org/certs/isrgrootx1.der
--------------------------------------------
2. Verify that the fingerprints match:
--------------------------------------------
So you know that the Root Certificate I've linked to is in fact the one that LE provides and Apple has certified/trusted.
This is for *your* safety since you *shouldn't* trust me.
FINGERPRINT (SHA-1):
CABD2A79A1076A31F21D253635CB039D4329A5E8
SOURCE:
https://letsencrypt.org/certificates/ (Active > ISRG Root X1 > Self-signed > der)
https://crt.sh/?id=9314791
WHAT APPLE SHIPS 10.12.1+:
https://support.apple.com/en-us/HT207189
- Search for: "ISRG Root X1"
You should see that the fingerprints match between and .
--------------------------------------------
4. Install the certificate:
--------------------------------------------
- Via "Keychain Access.app"
- `File > Import Items...`
You can install it into either the `login` or `system` keychain. But not `System Roots` (which is where it *would* be, if we were on 10.12.1+)
- login = Current user only
- system = All users
--------------------------------------------
5. Manually "Trust" that certificate:
--------------------------------------------
- Find it ("ISRG Root X1") in the list and double click on it.
- Open the "▶ Trust" area.
- Set: `When using this certificate:` to `Always Trust`
- Close the window, which will ask you to verify with your login password.
🏁 Done!
Websites, via Safari, should immediately start working again if you reload. Chrome is a little crankier, so either load previously opened URLs in *new* tabs, or just restart Chrome. I didn't test in Firefox.
This should fix sites that use Let's Encrypt Certificates. Which it probably where you'll run into this issue the most.
---
I saw this post a few days ago, but didn't know how much it would effect me (OS 10.11 El Capitan). In any case, I couldn't really do anything about it at the time, because it would be tricky to test if it actually *fixed* anything before the expiration (since nothing would be broken yet). And I didn't want to mess around with changing the system clock, etc.
But I just ran into this today (Expiration Day 🎉)... While *trying* to read THIS site 😂
I did a bunch of additional research and ended up figuring out this relatively simple fix (especially for people that read a site like this :-) that *seems* to work well. I'm not a super expert in root certificates, in that I'm fairly well versed, but I don't do this everyday. So apologies if I've gotten something wrong. I'd be glad to learn a better way or a mistake I made.
Scott Helme's Twitter feed (author of the post linked above) is keeping track of a bunch of big sites that are affected as well.
https://twitter.com/Scott_Helme
I hope this helps.
(@Michael Tsai: Thank you for the fantastic site!)
a.
@Alex
> This seems to be working, thanks a lot! :)
👍🏻 That's great! Thanks for the verifying.
---
The domains I listed, in this line of my original post, were eaten (because I surrounded them with angle brackets).
It should read:
> "You should see that the fingerprints match between `letsencrypt.org` and `support.apple.com`."
IM FUCKING SHAKING RIGHT NOW WHAT IN THE ACTUAL FUCK I CANT GO TO WIKIPEDIA A BUNCH OF OTHER SITES DONT WORK
Can anyone help? I've read this issues affects PCs running Windows XP (Service Pack 2) or earlier. Yet I'm running Windows 7 Ultimate on my laptop and yet I'm running into the same issue on various websites when using Chrome (no problems with Firefox). Thank you
@N, @JesMed
Cool! I'm so glad it helped.
I just checked eclecticlight.co and it looks like a few other people arrived at the same procedure:
https://eclecticlight.co/2021/09/21/el-capitan-and-older-mac-os-x-are-about-to-have-a-security-certificate-problem/#comments
Howard Oakley also mentioned that he plans on publishing an article on Friday (Oct 1, 2021) with more explanations and details.
god bless @a, I had updated chrome, updated MACOS to the latest el capitan it would let me and finally did his fix
Thank you for the solution. I have been working on this for hours and your solution was an immediate fix. Well done. Cheers.
Worked for me for Google Chrome using OSX El Capitan 10.11.6. Thank you so much.
Hopefully not too many people trying to access my website will have older MAC OS versions where this problem occurs. I think I may move away from Let's Encrypt just in case.
Wow. I'm a computer idiot, and it worked for me too. I sure hope this i didn't just turn my computer over to Russian demons or anything like that. Thanks! (i think)
THANK YOU!!!!!!!!!
I searched fix for long time...Thank god there is wise people here who can fix those Apple-idiots errors-
@a
A godsend! Clear and detailed instructions, they worked beautifully. Instant success! Wikipedia.org is alive again on my ancient Mac.
-NM
Very helpful news note and discussion. One workaround for 10.11.x users I found on a Chrome discussion board: Open the "Keychain Access" app and choose "system / all items" on left and search or scroll until you find the certificate "DST Root CA X3," which (in my case) is shown as expired. Double-click it and hit the little triangle by "Trust." Choose "Always trust" from the "When using this cert..." line (which will also change all the settings below to match). Close that pane and input your user password when requested. Restart Chrome. It instantly fixed the problem, though I have no idea why this cert expired in the first place or why it still works though expired. Any risks with this approach?
OMG!
I am so dumb with computers but was able to do this! THANK YOU
It Worked!!!
was driving me nuts!
You are the best
This worked perfectly. Thanks a ton for this! using El Capitan on old mac couldn't figure out why major sites (i.e. Wikipedia, Quora) were suddenly locked out via Chrome's security messages
Found this via a reddit post on NET::ERR_CERT_DATE_INVALID error.
This works thank you this has been doing my head in for days what I did was use a PC and got the file onto a pen drive and followed it to the letter
Thank you. Found this page while searching for a way around the issue and this fix works for me too.
Adding the Root Certificate (isrgrootx1.der) seemed to fix the browser issue. I'm having connection issues with Apple Mail also. Same SSL issue. Is there a fix for that issue at the moment?
THANK YOU SO MUCH 'A' for such clear and easy instructions.
My vintage iMac and I are friends again :)
Cheers
What a nice response!
I was surprised myself when it worked. You always hope to be able to find such a targeted fix in the face of possibly having to do something much more drastic (ie: Upgrade the OS). Averting a "kill a fly with nuke" situation.
But so often it doesn't go that way. So I'm as glad as everyone else here :-)
Plus, as far as I understand, it's perfectly secure*, in that it's just adding the already approved and in-use certificate to your system. It doesn't require reducing permissions or (mis)training yourself to ignore warnings that may or may not be related.
(*Famous last words)
---
@Aliyah:
Can anyone help? [...] Yet I'm running Windows 7 Ultimate on my laptop and yet I'm running into the same issue on various websites when using Chrome (no problems with Firefox).
I'm sorry I don't know enough about Windows. The general concept should hold (installing and trusting the "ISRG Root X1" Root Certificate), but I'm not sure how in your case.
I think the reason Firefox is ok, is because they started including Root Certificates, as part of the FF install, in May 2021:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
Chrome is going to start doing this as well, but I don't think there's an ETA yet:
https://www.chromium.org/Home/chromium-security/root-ca-policy
@steve:
Hopefully not too many people trying to access my website will have older MAC OS versions where this problem occurs. I think I may move away from Let's Encrypt just in case.
Agreed.
I'm a little concerned about this as well. I was considering turning various server side `Force HTTPS` methods (ex: .htaccess) OFF. Giving people who are affected a way to bypass this. At least, on the sites with content that don't need `https`.
This is one of the arguments that people were (are?) making when Google started to heavily pressure site admins to switch all sites to `https` (regardless of need). Hence leading to the rise and proliferation of free Let's Encrypt certificates, which lands us all here ;-)
- https://www.w3.org/DesignIssues/Security-NotTheS.html
- https://0xnf.github.io/posts/security/arguments-against-https/
- https://security.stackexchange.com/questions/54120/is-google-overreaching-by-forcing-me-to-use-tls
(I'm including these links for context and information. I can see the arguments on both sides.)
@markv:
I sure hope this i didn't just turn my computer over to Russian demons or anything like that. Thanks! (i think)
I don't think you should have anything to worry about** other than remembering that this happened (and how to fix it), in the event that you re-install 10.11 and find 1/2 of the Internet broken again 😂
The cert that you're installing and trusting is the same one you'd get if you installed 10.12.1+.
(**Anyone else more knowledgeable: Please correct me if I'm wrong.)
@Tom:
One workaround for 10.11.x users I found on a Chrome discussion board: Open the "Keychain Access" app and choose "system / all items" on left and search or scroll until you find the certificate "DST Root CA X3," which (in my case) is shown as expired. Double-click it and hit the little triangle by "Trust." Choose "Always trust" from the "When using this cert..." line (which will also change all the settings below to match). Close that pane and input your user password when requested. Restart Chrome. It instantly fixed the problem, though I have no idea why this cert expired in the first place or why it still works though expired. Any risks with this approach?
A few things:
I think I tried this before I came to the procedure above (more on that in a second.
When the cert is created, the expiration date is baked in. From what I understand, one of the reasons is to limit the time window of an attack, in the event that the cert is. Imagine a system that has no update mechanism (or it's broken), hard to update, not actively monitored, etc. In this case, that compromised root certificate will open the door to attacks, that will to continue until that system is taken offline. IOW: It's a fail-safe.
I'm not sure why you were seeing it "still works though expired". It's possibly a cert caching issue, as Howard Oakley has been documenting here: https://eclecticlight.co/2021/10/01/why-wont-safari-open-that-web-page/ . Or maybe you're referring to it starting to work after you trusted "DST Root CA X3"? Which brings me to your final question:
Any risks with this approach? I'd say: Yes, a little. Since you're Trusting an expired certificate. Manually trusting an invalid certificate is probably a bad idea, because attackers will know that people (like us) will resort to a workaround like this, in order to keep our older systems working. So in the future, they'll likely setup fake sites (at least), which reference that certificate. And because YOU have granted the exception, you'll be under the FALSE assumption that the security of the site is assured. I'll leave the rest of this attack (and others) to your imagination.
@Steve:
Thank you, running an old iPad on 9.3.6 problem solved.
I'm curious, how were you able to load and trust a Root Certificate on an iOS device? Is it Jailbroken?
Searches the Internet...
TIL:
You can manually install Root Certificates on iOS devices:
https://support.apple.com/en-us/HT204477
http://kb.mit.edu/confluence/display/mitcontrib/Installing+Root+and+Personal+Certificates+on+iOS
But these instructions call for iOS 10+. I didn't find instructions on iOS 9.x and lower.
@Chuck:
[...] I'm having connection issues with Apple Mail also. Same SSL issue. Is there a fix for that issue at the moment?
Funny you should mention this.
I starting hunting this down before I checked my email in the morning. After I applied the fix, a bunch of emails came in. So it affected my email too. But my email was also fixed by it. So I didn't think too much of it.
I use a relatively small managed email service. The hosting company was aware of this issue before the expiration and took steps (week/months ago) to mitigate it. I believe it had something to do with with adjusted the way their LE certificates were regenerated for their mail servers (IMAP, POP, SMTP). I haven't looked into the exact details.
But, assuming you're in a similar situation (ie: Using a managed email provider for your domains, and not something like Gmail, Fastmail, or some other huge email provider, which is not affected by this), I might suggest contacting them to see if they can update their LE certificates on the servers you connect to (ex: mail.HOSTINGCOMPANY.com) when downloading your mail.
---
Thanks again!
a.
Web browsers seem willing to use an "Always Trust" ISRG Root X1 certificate imported into Keychain, but I'm still seeing connection errors in other apps, unfortunately.
[…] reported on Michael Tsai’s excellent site and elsewhere, if you’re on an older version of Mac OS X, you’ll encounter SSL errors […]
@a Thank you so much! You are a God send my dear friend, don't know what i would've done without your help. Thank you times infinity!
@a
Thank you very much for the clear, detailed, friendly recipe. It worked perfectly for me, and now Wikipedia and other sites are accessible via Chrome on an old Mac running El Capitan.
@Alex
Thank You so much - You saved my day. Read somewhere that I could use firefox, but my El Capitan was too old.
Bless your heart, @a. This has been driving me insane. I'm usually too intimidated to try to figure out my own computer problems, but I couldn't handle this any longer! Your instructions were clear and it solved the problem instantly.
Dear @a ,
Your suggestion worked like a charm. Thank you so much for posting!
On a side note: I did indeed trust you, contrary to your instructions -- lol.
I just didn't understand how to do this verification below that you recommended -- although I would like to learn:
"--------------------------------------------
2. Verify that the fingerprints match:
--------------------------------------------
So you know that the Root Certificate I've linked to is in fact the one that LE provides and Apple has certified/trusted.
This is for *your* safety since you *shouldn't* trust me.
FINGERPRINT (SHA-1):
CABD2A79A1076A31F21D253635CB039D4329A5E8
SOURCE:
https://letsencrypt.org/certificates/ (Active > ISRG Root X1 > Self-signed > der)
https://crt.sh/?id=9314791
WHAT APPLE SHIPS 10.12.1+:
https://support.apple.com/en-us/HT207189
- Search for: "ISRG Root X1"
You should see that the fingerprints match between and ."
@A thank you so much for posting those instructions. They worked beautifully after searching on google for over an hour for help before I finally stumbled upon your solution that solved everything!!!
@ed Web browsers seem willing to use an "Always Trust" ISRG Root X1 certificate imported into Keychain, but I'm still seeing connection errors in other apps, unfortunately.
What other apps?
The first thought that comes to mind, is that those apps are trying to make an `https` connection to a server that does not use Let's Encrypt (which is now rooted via "ISRG Root X1"), but does use the now expired "IdentTrust DST Root CA X3" Root Certificate.
---
@nam On a side note: I did indeed trust you, contrary to your instructions -- lol.
Ha! With security stuff like this, you're supposed to trust the math, not the person. Which is why I wrote that. But thank you.
@nam I just didn't understand how to do this verification below that you recommended -- although I would like to learn
The last, and maybe most important, part of that instruction (#2 Verify that the fingerprints match) was mangled, because I formatted it incorrectly. I posted the corrected version, just below, but I'll elaborate a little here:
The procedure requires downloading that ISRG Root X1 certificate and installing it. But I wanted to make it clear that you should double check that the certificate you download, from the links I included, is the same as the one Apple has also verified and is what is included in OS versions 10.12.1 and above.
To do this, you manually go to the two different servers and confirm that the fingerprint (`CA BD 2A 79 A1...`) matches between them both (Let's Encrypt and Apple):
Source (Let's Encrypt):
https://letsencrypt.org/certificates/ (Active > ISRG Root X1 > Self-signed > der)
Client (Apple):
https://support.apple.com/en-us/HT207189
That match is what lets you know that you're about to download and install a trusted certificate. And not just taking my word for it :-)
---
a.
Thank you so much! This worked perfectly I was going absolutely insane. On the chat with my webhost for hours, with them LYING to me saying they knew it was an issue with chrome and SSL and it would be resolved in a few hours...but days later still not.
@a i love you bro,i am far from being a a tech or programmer.. this issue left me useless for 48 hours. Thanks to you it all fixed...
In fairness to them, they may have issues (or thought they did) with their Let's Encrypt configuration. Or they were roughly correct, that there's an issue with Chrome and SSL, but don't understand the finer intricacies of older versions of Mac OS and Root Certificates ;-)
(With that written: Web Hosting support is notoriously [insert negative adjective]. Not all, but many.)
---
Just to be clear, if you're referring to website(s) that you own/administer, this procedure will only fix your local machine. Those sites are still going to be seen as insecure by anyone that doesn't have the "ISRG Root X1" Root Certificate installed.
I'm still looking into possible server side fixes.
This looks promising, but I haven't been able to test it yet:
a.
Downloaded to iPhone as computer can’t access that site. Can’t find it in iPhone. Where has it been stored?
@Peter Blackburn Downloaded to iPhone as computer can’t access that site. Can’t find it in iPhone. Where has it been stored?
Probably in the "Files" app.
But if you want to download it directly to your desktop/laptop, you should be able to get the `.pem` file from here:
https://crt.sh/?id=9314791
(crt.sh uses a different root certificate, so it should be accessible via that ~10.11 machine.)
- Find the link in the left column of the table, 8th row ("Certificate"):
- `Download Certificate: PEM`
Well done, you are a king!
Blessed are the human beings who help others to pass through the mysteries of Internet.
Much love, much light
Great help! Much appreciated! Am very happy to see my 10+ IMac with ElCapitan working properly again!
It works a charm on my El Capitan 10.11.6. Thanks Michael Tsai for starting the thread and Thanks "a" for the solution to my headaches.
I'm so grateful for this fix - thank You!! I'm kinda forced to stick with El Capitan because I'm running CS5 on both my Macs and by all accounts, CS5 doesn't run well on anything newer than El Capitan - can't afford the huge chunk of change needed to get Creative Cloud. When I started noticing the browser issues I thought I'd have to relent - I'm so thankful I found your fix! As an aside, two of the websites I couldn't access yesterday were two of the art supplies companies I deal with - It's sad to think that they might lose business from people who are experiencing the browser issues on older Macs. I'll share this with anyone I can - thank you again!
Thank you so much - would love to buy you a pint (or two)! Immensely grateful for this - you've saved me so much hassle!
Thanks for this work around!
Question:
Once the root certificate is installed on an older mac, what is the difference between selecting Always Trust and Use System Defaults for the trust setting? Why select Always Trust instead of Use System Defaults?
> Once the root certificate is installed on an older mac, what is the difference between selecting Always Trust and Use System Defaults for the trust setting? Why select Always Trust instead of Use System Defaults?
Since you (and not the OS) installed a root certificate, the System Default
will be to not trust it. Which makes sense for security reasons. But will also not fix the problem.
You can even try it (I did :-). You'll see that you run into the same certificate warnings. Because the system will see that "ISRG Root X1" is not (yet) trusted (and has no reason to trust it), so it continues to go "up the chain" all the way to the now expired: "IdentTrust DST Root CA X3".
IOW:
Setting the Trust
value of "ISRG Root X1" to System Default
will behave as if you didn't install that certificate at all. So setting it to Always Trust
is required.
But it's safe (as far as I know, and no one else has said otherwise).
You can think of it like this: If you were using an OS that included "ISRG Root X1" as part of its installation (ie: 10.12.1+), it would be System Defaults
technically but Always Trust
effectively.
a.
@a
Thanks for your explanation. I am clearly in over my head. I am stuck on an old mac that I'm unable to update which became a glorified typewriter when Let's Encrypt updated their root certificate.
In the category of a little bit of knowledge is a dangerous thing, in my desperation to regain internet access, I imported all the root certificates from a new mac to my old one, thinking if the certificates are valid on the new machine, they should be valid on the old one.
It worked great, and I can use the internet again. However, the new certificates in the System folder have Trust settings of Always Trust selected for all options. Many imported certificates now in the System folder turned out to have a duplicate certificate in the System Root folder. Now both the new and old certificates have Custom Settings of Always Trust for all options that I can't change in Keychain.
My basic instinct is to never trust anything. The original Use System Defaults trust settings set all options to "no value specified." Now, the trust option values on all certificates, new and old, are set to Always Trust.
Are you saying that when the system installs a certificate, the System Default of "no value specified" translates as "Always Trust?"
So, when I install a certificate, the System Default trust setting defaults to "never trust?" I then have to manually change the certificate to "Always Trust" to validate it; otherwise, the system uses a default setting of "never trust" for the certificate?
When I imported the certificates, all the certificates imported as "Always Trust", which is the correct setting for the system to recognize a user installed certificate as valid because the system default value for certificates I installed would be "never trust?" (And I can stop panicking now?) Thanks!
JJ
Thank you so much @a. You are a genius. I was going stark raving mad trying to follow a lot of other "solutions" that didn't work.
@ "a" thousand thanks for your great problem solving and rescue of my only 5 years old Macbook (have El Capitan 10.11)! And thanks also to @Michael Tsai for the great site that allowed me to solve my problem in the first place! And at this point also again a big thank you to a good friend who found this site and helped me with the technical implementation! Many greetings from Munic, Germany, Elsa
@JJ (October 9, 2021 4:21 AM)
(Sorry for the delayed reply. You may have figured all of this (or something else) out by now :-)
You mentioned a bunch of things. I appreciate how much you attempted and how careful you were to observe the outcomes. Even though, in this case, it might have come back to bite you, we've all been there.
I think I understand what you tried and your questions. I'll see if I can add anything that might help :-)
---
> My basic instinct is to never trust anything.
👍🏻 Smart :-)
> Are you saying that when the system installs a certificate, the System Default of "no value specified" translates as "Always Trust?"
No.
First:
"No value specified" is only for those protocol specific settings (ex: SSL, S/MIME, EAP, etc.). Those should stay as no value specified
unless you need something different. (I'll write more about this below.)
Second:
Your focus should be the When using this certificate:
"master" setting (at the top of the "Trust" group.)
Third:
I was referring to the specific case of a user installing a trusted root cert. I included that comparison, between user vs. system installed, as a way to comment on the safety of using Always Allow
in this case.
> So, when I install a certificate, the System Default trust setting defaults to "never trust?" I then have to manually change the certificate to "Always Trust" to validate it; otherwise, the system uses a default setting of "never trust" for the certificate?
For me, when I install "ISRG Root X1" it starts as Use system defaults
. I then manually change it to Always trust
, which sets all of the protocol specific settings (below "When using this certificate") to Always trust
as well. Which seems to be why you asked the questions you did.
It sounds like, when you imported all of the certificates, and set them to Always Allow
, it changed all of the protocol specific settings to that as well. And when you compared those to the System Roots
equivalents, you saw a bunch of no value specified
trust settings. And now you don't know what to think :-)
But maybe I have that wrong.
Hopefully I've written something that has made things more clear. But maybe not.
> I imported all the root certificates from a new mac to my old one, thinking if the certificates are valid on the new machine, they should be valid on the old one.
I also found those "pull in all of the certificates from a newer mac or some website" procedures:
Is this roughly what you tried?
From what I can tell, even though this seems to work (others have reported that it does) the method above is much simpler and likely fewer potential side effects. One of which (a bunch of duplicates) you've run into :-)
It sounds like you've imported bunch of certificates into your `system` Keychain. Which just means those certs will apply to ALL users on the machine and not just the user you're currently logged in as.
And now you have duplicates because they also exist in the non-user-modifiable System Root
group.
Two ways of reverting all of this come to mind:
1. Remove duplicates and re-establish the correct/expected cert "Trust" settings
2. Restore your Keychain items from a backup
I haven't tried either of these, but they're what I would probably try.
Let me know if you need more details on how to accomplish one or both of those.
A few quick things that might help you get started:
You found that:
> The original Use System Defaults trust settings set all options to "no value specified."
I see that too. If it were me, I'd just set all of the certificates back to that. (But I haven't done that independently.)
Leaving them as "Always Trust" is ok and not ok.
- "Ok": In that they are valid certificates.
- "Not Ok": In that they will expire, and once that happens, you won't be warned that they are no longer valid/expired. Which opens a security hole. See what I wrote here in my reply to @Tom for more thoughts about that.
So really: Not ok ;-)
As far as having duplicates (between `System Roots` and `system" and/or `login` groups), I'm not sure how much that matters to the system. I'd think having incorrect permissions (or different permissions for each occurrence of the certs) would be more of an issue than duplicates. But I'm sure sure about that.
re: Restoring from backups
The login
and system
keychain files live here:
- login = ~/Library/Keychains/login.keychain
- system = /Library/Keychains/System.keychain
If you restore the `login` keychain, this file might be important to restore along with it (but I'm not sure since I haven't tried it. But based on the Modification Dates
, it looks like they change at the same time):
- login = ~/Library/Keychains/metadata.keychain
I'm not sure if you're going to run into issues with swapping out these files while your logged in or booted from this Mac.
If you want to be super safe:
- Backup the current/most recent/active version of those files (ex: On your Desktop)
- Boot from a clone
- Do the swap
- Restart and see if it worked
- If NOT, repeat but move the version of those file, from the first step, back into place.
One finally big gotcha:
I'm not sure if any of the above Restore from a backup procedures will also restore the Trust
settings to the way they should be. Those are probably maintained in a different preference file. I'll stop here, because beyond this, I'm just making semi-educated guesses.
So, manually adjusting the Trust
settings (in Keychain Access.app) is probably the way to go.
I hope this helps and I haven't made things less clear.
If you get stuck, maybe we can find a way to discuss this elsewhere, so we don't clog up this comments section.
a.
@a Thank you so much!! I have spent days with several people try to troubleshoot the issue with no luck until I found your fix.
@a thank you so much for your helpful description of what to do.
I did not understand all of the nuance, but the descriptions were clear enough that I could follow them and my non-working half of the internet is working again.
One other observation during this time that surprised me, and I still don't understnad how the following could be related: I received a ton more inappropriate spam through google mail during this period than before. Now my certificates are updated, my spam level has returned to normal.
It has also surprised me that until I found your helpful instructions, I was searching for a couple of weeks with no luck. I hope that more users of El Capitan etc are able to find this.
Many thanks,
Keith
@a.
Thank you for your detailed reply! I am guilty of using the script from the link you cited. I might have used your procedure instead had this site not been blocked from my viewing by its use of the updated Let's Encrypt certificate.:D
I have not made much progress in cleaning up the problem I created with my keychain as I unexpectedly find myself caring for a three-year-old for the next three weeks.
> If you get stuck, maybe we can find a way to discuss this elsewhere, so we don't clog up this comments section.
I agree. I would greatly appreciate being in contact since I will now need to work on this project in fits and starts and will undoubtedly have questions arise when I do. How do we do this?
Thanks,
JJ
I have an iMac running El Capitan, purchased in 2013, and was having the same problem... Apple's Mac store said my OS X was up to date. So, I went to this page, https://support.apple.com/en-us/HT211683, and clicked on the link (using Safari) at the bottom of the page to download the macOS High Sierra 10.13 installer. Once I installed the new OS X, which took about an hor, problem solved. I am back to being able to access any website with any browser.
Thank you so very much!!! Amazing!! I could activate SoundsSpot Nevo audio plugin for Logic with this on El Capitan!! Thank you so much for your help! :)
Also I could activate SoundSpot Nevo audio plugin for Logic on El Capitan with this fix!!! Websites are working again! Love it! Love you!!
It worked !!! THANK YOU!!! I've been frustrated for days and then hours looking for a solution and yours was 100% spot on!
Hi, thank you so much for your help, its very appreciated
I have a question, my work server site doesn't seem to work, for what I thought was the same reason, as my browser was alerting me that my connection was not secure.
The thing is, I trusted the certificate and it still doesn't seem to work, any idea about what I should do?
Thanks again
@JJ
Sorry again for the delay.
> I agree. I would greatly appreciate being in contact [...] How do we do this?
How about this?
- Send an email to Michael (via the address he provides on this site).
- You'll verify that you're the @JJ here by sending it *from* the same email address you used when posting your comments here. Since only Michael knows what that is, that'll prove you're the same @JJ.
- He'll forward it on to me and I'll contact you via that address.
a.
@a, Thank you SO much!! I've been trying to find a fix for WEEKS!! It worked immediately after I restarted Chrome. Thanks again. Cheers!
Hi,
I get an error when trying to import any certificate. An error occurred. Unable to import “ISRG Root X1”.
Error: 100013
Somebody knows a solution for this?
Hey Guys
I need help big time. I'm not computer literate as the rest of you are. I'm getting the same stupid error message regardless which browser I'm using. I get this error message on some site, or if I try to open a link.
Here's the message NET:: ERR_CERT_DATE_INVALID. I don't use Safari.
I contacted Apple they never heard of this error. But of course, their standard solution "Oh you need to upgrade from El Capitan, at least to Mojave since in can work with 32/64 bit. I have no intentions to upgrade. I'm very dumb when it comes to get under the hood.
I need some suggestions. I contacted some tech service, they sounded very surprised about this error. Only one told me that he read something about the Certificate expiring in late Sept.
@celine (October 18, 2021 3:38 PM)
> I have a question, my work server site doesn't seem to work, for what I thought was the same reason, as my browser was alerting me that my connection was not secure.
>
> The thing is, I trusted the certificate and it still doesn't seem to work, any idea about what I should do?
We'll need a few more details to be able to help :-)
i.e.:
- Does the work server's browser show these messages?
- Or do you mean that you added the certificate on the *server*, but you *client* computer's browser still shows the warning?
- Did you follow the *same* procedure on both (or more) machines?
----------------------------------------
@Sam (October 26, 2021 7:49 AM)
> I get an error when trying to import any certificate. An error occurred. Unable to import “ISRG Root X1”.
>
> Error: 100013
>
> Somebody knows a solution for this?
A quick search turned up a few results.
This one seemed to have some good information (but I don't know about following the their procedure):
http://www.aikidokatech.com/?p=42
tl;dr:
It might have something to do with *which* keychain you tried to install into.
System Roots
vs System
vs login
vs X509Anchors
This might also be worth a trying if your comfortable with using the command line:
https://stackoverflow.com/a/9083862/886672
----------------------------------------
@Larry (October 27, 2021 11:29 PM)
> I need help big time. I'm not computer literate as the rest of you are. I'm getting the same stupid error message regardless which browser I'm using. I get this error message on some site, or if I try to open a link.
>
> Here's the message NET:: ERR_CERT_DATE_INVALID. I don't use Safari.
I've received this error occasionally, even before the "IdentTrust DST Root CA X3 certificate" expired. It seems to be a similar issue (a root certificate expiring), but I can't be sure. It might or might not be fixed by the procedure above.
> I contacted Apple they never heard of this error. But of course, their standard solution "Oh you need to upgrade from El Capitan, at least to Mojave since in can work with 32/64 bit."
macOS Sierra (10.12.1) (the major version release *just* after El Capitan 10.11) should be all you need to upgrade to (not Mojave 10.14, which you probably can't even upgrade to) in order to automatically get the "ISRG Root X1". It's not surprising that Apple Support doesn't know this very specific case and the minimal upgrade required.
However the procedure I posted above is meant to avoid even having to do that OS upgrade :-) Have you tried that?
Speaking of...
> I have no intentions to upgrade.
Smart :-)
Hopefully this helps.
---
Side note:
While looking into this, I found another root certificate that expired on May 20, 2020:
Sectigo AddTrust External CA Root Expiring May 30, 2020
It might also be causing a similar problem for the sites that rely on it. But it's probably far fewer sites, since we didn't hear much about this one.
So for anyone else/future reference, here's some information about that:
https://sectigo.com/knowledge-base/detail/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020/kA03l00000117LT
Thank you thank you @a, I've been switching on and off safari on almost every website to "proceed anyways" and couldnt find a clear answer.
THANKYOU!! so much Stefan Reitshamer for the very clear and easy to follow instructions - instantly fixed our issues which we hadn't been able to work out before. :)
> Wilson (November 9, 2021 1:14 AM)
> Thank you thank you @a, I've been switching on and off safari on almost every website to "proceed anyways" and couldnt find a clear answer.
Did you also select Always Trust
from the security sheet that Safari presents?
Because if so, that will allow you to view the site, but it opens a security hole, since that grants blanket trust to that domain. So if its certificate changes to something malicious, you won't receive a warning. ex: If an attacker replaced their valid certificate with a bogus one.
> RussCW (November 9, 2021 4:38 AM)
> I'm on El Capitan 10.11.2 and this didn't work for me unfortunately! I can't see what I done wrong!
If you post some more details (i.e.: Error messages, what you tried, etc.) maybe I or someone else could try to help :-)
When I check the certificate I downloaded from the link above, the fingerprint doesn't seem to match the Apple fingerprint shown at that second link.
However, the link on the certificate I downloaded is SHA-1 and the fingerprint Apple shows is SHA-256.
Is there a way to verify that these are the same? I haven't installed it yet, due to the question about the certificate fingerprints.
Thank you!
M.J. Rice (November 13, 2021 12:11 PM)
> When I check the certificate I downloaded from the link above, the fingerprint doesn't seem to match the Apple fingerprint shown at that second link.
>
> However, the link on the certificate I downloaded is SHA-1 and the fingerprint Apple shows is SHA-256.
>
> Is there a way to verify that these are the same? I haven't installed it yet, due to the question about the certificate fingerprints.
>
> Thank you!
Good point + bonus points for double checking!
You're right. In my original post, I only included the SHA-1
fingerprint, even though the SHA-256
fingerprint is the one listed at Apple.com.
I should have used the SHA-256
fingerprint instead. Sorry about that and thanks for pointing it out.
----------------------------------------
ISRG Root X1:
----------------------------------------
Serial Number:
82:10:cf:b0:d2:40:e3:59:44:63:e0:bb:63:82:8b:00
SHA-1:
CABD2A79A1076A31F21D253635CB039D4329A5E8
SHA-256:
96BCEC06264976F37460779ACF28C5A7CFE8A3C0AAE11A8FFCEE05C0BDDF08C6
Validity:
Not After : Jun 4 11:04:38 2035 GMT
Via:
https://crt.sh/?id=9314791
(Via: https://letsencrypt.org/certificates/ )
---
You can check that information against what Apple lists here:
https://support.apple.com/en-us/HT207189
"Find..." (via command-f
):
ISRG Root X1
I hope this helps.
a.
Am stuck running El Capitan as I use Creative Suite CS6 (don't get me started on the new CS subscription model) so really appreciate this updated certificate. Thanks so much.
I'm still very frustrated. I don't have the confidence to try to change the Certificate date.....I'm afraid that I might make things worse. I talked to several repair shops, some Apple Authorized they didn't sound too confident.
Again, they went to the same route as Apple, UPGRADE, UPGRADE! I have tons of 32bits apps running, including Office, and many others. If I upgrade it would be extremely expensive, not to mention complicated.
Even after upgrading to Mohave (which supports 32bits apps) some are having difficulty to use Office period. Am I overacting here? I don't have a clue what to do
Could anybody out here help me please. I don't have a clue, nor the confident to try to this on my own. I contated several techs, including Authorized Apple shops. They don't have a clue.
Upgrading the OS would be devastating to me. I have lots of 32 bits apps running at this time. I hope I could get some response/help from someone. Thanks
@Anonymous (November 23, 2021 6:11 PM)
@Geo (November 23, 2021 6:24 PM)
(It reads like you might be the same person. Apologies if not.)
In my original post (September 30, 2021 3:51 PM) I kept the details short. So here's a more explicit step-by-step version for anyone that needs it.
I promise it's not that hard. "You can do eeet!" :-)
And if you trust the feedback from everyone else here (and other sites), it's safe.
(The instructions are assuming you're on El Capitan 10.11.x. But it should be pretty similar in earlier Mac OS versions.)
---
- Download this file: https://letsencrypt.org/certs/isrgrootx1.der
- Double click on it.
- It should open the application:
Keychain Manager
and present you with a window titled:Add Certificates
- Find the
Keychain:
option at the bottom right (just above theCancel
andAdd
buttons). - Select
System
from the dropdown. - Click the
Add
button. - Now find that certificate by entering "ISRG" in the search box at the top right of the main window. All of the other certificates will probably disappear and it'll likely be the only one left. Don't worry, all of the other certificates are still there.
- Double click on
ISRG Root X1
- In the window that pops up, click the arrow to the left of
Trust
- Find the
When using this certificate:
option (it's the first one under "Trust"). - Change the dropdown from
Use System Defaults
toAlways Trust
(Note: You should see that all of the other options below automatically change toAlways Trust
as well.) - Close that window titled
ISRG Root X1
- Enter your password when prompted and click
Update Settings
🏁 Done
Sites that were previously broken (because of this issue) should work now.
(If you're using Chrome, you may have to restart it for this to take effect.)
As others have pointed out (and if you don't want to do any of the steps above), you might have some luck with using Firefox (instead of Safari and Chrome) since it maintains its own Root Certificate Store.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/
But I haven't tested this and it won't help if some other app tries to connect to a server that relies on this certificate.
---
I hope this helps.
a.
ps. I'm just now realizing I mis-numbered the steps in my original post. I skipped right from "2" -> "4". Whoops 😂. Sorry.
i was days away from buying a new IMac simply to resolve this. have a 2011 running El Capitan and just found this fix. it worked perfectly. for those of us who dont believe in throwing away perfectly fine hardware for what is a simple solution, i thank you wholeheartedly. shame on apple.
couple years ago i got tricked into attempting to install new iOS on this machine and it was rendered dead by the upgrade. was able to bring it to my local independent apple guy and he was able to reformat and reinstall El Capitan so it was back up and running.
as they approach a 3TT market cap, is it really necessary for them to render old hardware obsolete. the planet can't take much more of this
thanks again. truly heros.
DOWNLOADING INSTALLING AND SETTING THE NEW SECURITY CERTIFICATE FOR GOOGLE CHROME ON EL CAPITAN
This worked 100% on my 2008 Mac Pro Tower running El Capitan, which is extremely fast and reliable for its age, but I cannot install Sierra on it.
Instructions
Go to
https://letsencrypt.org/certificates/
Find the newest of this file link (first on the page)…
“Signed by ISRG Root X1: der, pem, txt”
Click on pem to download the correct one.
(I have my browser set to always download to the Desktop so I can quickly find the stuff I just downloaded, and I put it where it goes later).
Open Keychain Utility in the Applications > Utilities folder
Enter your password every time asked.
Click System (upper left)
Drag the new Security Certificate from the Desktop into the Security page in the open Keychain Window.
Double click on the new Security Certificate.
Click the little arrow next to “Trust” at the top to expand it.
Choose “Always Trust” in the menu next to
“When using this certificate:”
You can choose “Always Trust” because it literally just came from the website of the company that creates the Trusted Certificates.
HOW TO DOWNLOAD, INSTALL, AND SET THE NEW SECURITY CERTIFICATE FOR GOOGLE CHROME & SAFARI ON EL CAPITAN
This worked 100% on my 2008 Mac Pro Tower running El Capitan (extremely fast and reliable for its age, but cannot install Sierra on it).
INSTRUCTIONS
Go to
https://letsencrypt.org/certificates/
Root Certificates
Active
ISRG Root X1
Find the newest of this file link (first on the page)…
“Signed by ISRG Root X1: der, pem, txt”
Click on pem to download the correct one.
(I have my browser set to always download to the Desktop so I can quickly find the stuff I just downloaded, and I put it where it goes later).
Open Keychain Utility in the Applications > Utilities folder
Enter your password every time asked.
Click System (upper left).
Drag the new Security Certificate from the Desktop into the Security page in the open Keychain Window.
Double click on the new Security Certificate.
Click the little arrow next to “Trust” at the top to expand it.
Choose “Always Trust” in the menu next to “When using this certificate:”
You can choose “Always Trust” because it literally just came from the website of the company that creates the Trusted Certificates.
Thank you so much, instructions were clear and was able to fix the certificates issue from past few months on my 2010 Macbook on El Captain!!
@a This fix is amazing!! I can't believe I was even able to do it, but the instructions are not that hard to follow. Running an early 2009 (!) 17" MacBook Pro in which I swapped out the original hard drive for a SSD and swapped the optical drive for a larger HD. Happy again with my "new" computer. Happy New Year!
I have been trying to fix my computer since Wednesday. After 3 text chats with Apple tech support, many overnight downloads, moving music to external hard-drive to free up space to download the suggested Big Sur (which would supposedly solve the problem), and having to Reinstall El Capitan from a backup before I did all the cleaning up of my iTunes and transferring of music (which still exists on the external HD, but now also still exists on my computer). So much DID NOT WORK, so I turned to google and found you.
I. DID. THIS. amazing. Gaaaahhh! It worked.
It worked and I can't believe it was "so simple." It looks very complicated and I really had to concentrate, but, I cannot believe myself. Sorry, Apple Tech Support. You were "there for me," but @a fixed my problem in 15 minutes. Marry me.
Thank you for the info as my mac with EL CAPITAN now works like new.
Have had my iMac for over 10 years and as it is not now supported by Apple any more have been looking for a solution to this problem for some time.
It now works on the internet via most browsers.
@a Thank you for this, my EL Capitan 10.11.6 Mac was only sort of working for the last few months, very annoying and I had no access to my email on the Mac at all.
I used to be a programmer/systems analyst in Ireland a million years ago (c. 1979 - 1988) It was great fun then, nobody really knew what we were doing including us some of the time. We managed by figuring it out, trial and error and referring to the manuals.
By the way we used 2 digits for the Year the reason being that data storage was very expensive. I remember questioning vaguely if that would cause problems down the road, eg working out current age from date of birth that sort of thing,|} come 2000. I was told that the programmes we were writing would be long gone by then. Funnily enough I had a nice part time gig in 1999 fixing code I had written back in the day, lucrative but not as much fun. If only I had been paid by each time the code was run.
Its great to know people like you are figuring fixes out and sharing with the rest of us, thanks again.
Thanks for this fix. Google should pay you.
It looked really complicated but was not. I downloaded the certificate. Opened keychain. The cert. was there but not trusted. Manually trusted. Looks like it has worked. Direct site access and autofill are back!
Thank you.
Thank you to Brandon and Phebe who directed me to here.
@a
THANK YOU SO MUCH! This has been driving me crazy for months and was only getting worse with more pages affected. This is the only fix that actually worked. Very grateful!
THANK YOU !!!!!!1 I WAS DESPERATE NOR COULD DOWNLAOD OTHER THAN EL CAPITAN, BUT NOW THAT BAD SCRIPT DOESN'T APPEAR ANYMORE !
oh my god. I couldn't find a solution to this issue but somehow came across this. what a relief. everything seems to be working fine! THANK YOU
I implemented the fix on my late 2009 iMac. Websites now work in Chrome (yay), but still not in Safari.