Connection Errors on Apple Devices

Hi, I'm a normal user and don't run any websites. But since the expiration, I'm unable to access any sites using Chrome and get a " Your connection is not private" error for virtually every site I try to access. Any idea how I can resolve this issue? I use a Mac laptop, OSX El Capitan, 10.11.6.

Any guidance appreciated -- thanks!

Have you tried restarting your device?

Any ideas why this would be affecting Apple Devices more than other devices? Chrome on Macbooks has the right Cert Chain, but Chrome on iPhone does not. Safari on any Apple Device does not show the right chain.

This is Apple

Yeah...
Apple is as Apple does.

2 Likes

I saw that this got split off the main conversation, any ideas other than it just being Apple?

Based on official documentation, ISRG Root X1 is only included in macOS >= 10.12.1.

Your device appears to be older than that, so it doesn't trust ISRG Root X1. This is causing the errors you're now seeing.

Maybe it's possible to update your device, this could help. Otherwise, I'm not sure if it's possible to manually install root certificates on your device - you could check that.

The root you need to install (if possible) is ISRG Root X1 (der, pem, txt).

5 Likes

When all of this came up this morning I got to the point where an update was suggested. I've upgraded a single iOS Device to 14.8 and I've updated my MacOS to 11.6 on a single MacBook. This didn't resolve the issue on either device.

Sorry for splitting the main conversation, I had missed the original post. Looks like others are facing the same issue. Is it possible to just delete this expired certificate?

Among the many sites that don't work, one example is "watch.nba.com". Here's the error:

Your connection is not private

Attackers might be trying to steal your information from watch.nba.com (for example, passwords, messages, or credit cards). Learn more

NET::ERR_CERT_DATE_INVALID

To get Chrome’s highest level of security, turn on enhanced protection

I was able to get my MacBook to work with the site by clearing the site data in Chrome and in Safari after reissuing the Cert.

Trying the same thing on an iOS device hasn't worked so far. Not sure what else to try.

Until this morning, all the Apple devices I tried had a problem. A few hours ago, some returned to work, but I still have some problems

Thanks! I'll give this a try. How do you reissue the Cert? Is there a link with instructions by chance?

I wish...what Certification Application are you using. I'm using Certify the Web on a Windows Server.

I have a fix for my issue.

It turns out that what I needed was already included in my PFX file that I get from Certify the Web. I'm using an Apache Web Server, the server includes an optional Certificate File that can be included in the SSL Settings called the Certificate Chain File.

I created the chain file from the PFX using this command:
.\openssl.exe pkcs12 -in mycert.pfx -cacerts -nokeys -passin pass: -out chainfile.crt

Then I added that chainfile.crt file to the Apache Interface and restarted the web server. That instantly fixed the issue on all Apple devices and even the Edge browser on my windows computer.

I really hope this helps someone else out. I'm happy to share this info in other places and I'll probably be copy and pasting this guy to several threads on several different sites .

Good luck everyone!

2 Likes

openssl.exe pkcs12 -in mycert.pfx -cacerts -nokeys -passin pass: -out chainfile.crt

this command gives me an invalid CRT...

@wallace.wgr
I think that command is specifically meant for servers (and only when using Certify_the_Web and Apache).

So...
Are you using a server?
If so, with which ACME client? and Web server?

2 Likes

The reason seems to be that mac OpenSSL is built with LibreSSL, which cares about the expired-root in ways that upstream OpenSSL doesn’t.

3 Likes

Interesting. Searching quickly on Google I found this problem open on GitHub from LibreSSL. Maybe there's a connection? The scenario reported in the problem is the same, unable to validate an alternative chain after the expiration of the root certificate.

3 Likes

I wonder if Apple would be willing to ship an OS update that changes this behavior. It would be great for site operators not to have to choose between losing compatibility with (some versions of) macOS and losing compatibility with (some versions of) Android.

3 Likes

I wonder how intentional this divergence from OpenSSL is. There’s an argument to make that the verification logic should verify the very chain I give it, and nothing else.

It was news to me today that it’s apparently OK for TLS clients to validate against an expired root. If that’s the case then I wonder why roots have expiry dates at all.

2 Likes