Friday, September 24, 2021 [Tweets] [Favorites]

Some Web Sites Will Stop Working With El Capitan and Older

Scott Helme (Hacker News):

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.

Howard Oakley:

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.

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.

Howard Oakley:

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.

Howard Oakley:

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.

Howard Oakley:

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.

Howard Oakley:

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.

99 Comments

FYI, the Mac App Store CSS problem on 10.13 has been fixed for a month or two.

@Kirk Glad to hear it, thanks.

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.

@a

This seems to be working, thanks a lot! :)

@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`."

@a IT WORKED!!! So grateful!!!

@a Works nicely.
Thank you a lot my friend!!!!!

IM FUCKING SHAKING RIGHT NOW WHAT IN THE ACTUAL FUCK I CANT GO TO WIKIPEDIA A BUNCH OF OTHER SITES DONT WORK

thank uuuuuuuuuuuuuuu!!!!!!!!!!!!

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.

shakingmacuser

god bless @a, I had updated chrome, updated MACOS to the latest el capitan it would let me and finally did his fix

@a

You're a godsend, thank you so very much for this assistance!

@a - many, many thanks! Your solution worked perfectly.

funziona anche a me, dopo averlo modificato come attendibile. grazie mille per l'aiuto

@a it worked for me as well..! Kudos to you :)

Baron Bugatti

Thank you for the solution. I have been working on this for hours and your solution was an immediate fix. Well done. Cheers.

Old Unix Geek

Thanks @a !

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

Thank you, running an old iPad on 9.3.6 problem solved.
Very much appreciated. Legend!

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.

Omg thankyou thankyou thankyou!!!!!
Fixed all my issues !!!

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.

Thank you for this fix.

[…] 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!

Thank you thank you. Love my PowerMac tower.

@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.

@a Thank you so much for saving the life of my iMac (Early 2008)

@Alex

Thank You so much - You saved my day. Read somewhere that I could use firefox, but my El Capitan was too old.

Just want to add my big thanks to @a

MKV

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.

Rachel Zinman

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...

@Rachel Zinman: 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.

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:

https://community.letsencrypt.org/t/users-of-older-android-and-windows-7-not-able-to-access-website/161557/15

a.

[…] (via Scott Helme) […]

Peter Blackburn

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`

Thank you !

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!

Thanks a ton!!!!!!!!

Thank you so much - would love to buy you a pint (or two)! Immensely grateful for this - you've saved me so much hassle!

@a your solution worked perfectly for me. Thank you so much!

Steve Jobs Ghost

10.10.5 thanks you

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?

many thanks for the solution @a

@JJ:

> 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 your solution worked perfectly for me. Thank you so much!

@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

Funcionó, muchas gracias!!! Toda la tarde buscando una solución!!

Martin Davies

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

Yay, my old Macbook has new life!

That fixed it - Thanks so much! I had to use a different machine to download the certificate.

It worked! Thank you so much!

@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:

https://apple.stackexchange.com/questions/428460/how-to-update-my-root-certificates-on-an-older-version-of-macos-e-g-el-capitan

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.

Thank you, you've saved my macbook!

@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

I have tried all of these and no luck! anyone else having this much trouble?

@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

After fixing this was a real help, now I just need a new username and Keychain, I can read again..

Thank you, this worked.

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! :)

I LOVE YOU! Thank you! My computer is working again perfectly! THANK YOU!

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

@a, brilliant. A thousand thank yous.

Brilliant - thanks. Got my 2016 macbook air working again!

Thank you! Giving my 2011 mac air a chance to work a bit longer!!

@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.

great article and great comments.

Hmmm.. Nothing happens after I try to import Items into my Login.

@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!

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment