April 15, 2026, 7:51pm 1

Domain is www.i2u2.org. Apache 2.4 on Ubuntu 24.04, and I have full SSH access to the server. Certbot 5.5.0.

We have LE certificates on our webservers, and have for some time with few problems. Recently, some users using Safari reported a "This connection is not private" error when trying to use the site. I can confirm four instances of Safari giving this error, including one on iPadOS 18.7.7 that was updated within the last month.

We are serving the full chain of certificates up to the ISRG Root X1 cert. Checking the details on one Safari error shows that the current correct cert is recognized, with correct 'NotBefore' and 'NotAfter' dates, and "Let's Encrypt" is labeled with "Not Trusted" below it.

SSL Labs gives us an "A" overall rating, so I don't think it's a configuration problem. Nothing about the configuration changed recently. The only thing that changed about our DNS recently was that I raised the TTL on the domain from 10 minutes to 1 day a couple of weeks ago.

It seems much like Safari pushed a new update with new root certs that don't trust Let's Encrypt. If that were true, though, I think there would be more info about that on the internet than I'm finding. There are a few similar questions on these forums, but all are older and don't have clear enough resolutions for me to apply.

How can I troubleshoot this?

Do you get the same error here?

1 Like

Realistically, you need a device exhibiting the problem so you can actually look at the error messages in detail that Safari is presenting and understand why it thinks there's a problem.

3 Likes

Could it be they are using your domain without the www prefix?

Because your cert only includes the www subdomain so will fail without it. It is not technically wrong to omit the registered domain from a website server cert but it is commonly done.

curl -i https://i2u2.org/ 

curl: (60) SSL: no alternative certificate subject name matches target hostname 'i2u2.org'
More details here: https://curl.se/docs/sslcerts.html

3 Likes

I don't have an iOS 18.x device handy at the moment, so I can't give you screenshots. But there should be some form of "Show Details" link on the "This Connection Is Not Private" error. From there, there might be a "view the certificate" link that should theoretically give you a better idea of what the actual error is.

Definitely double check the SAN values compared to the URL being used as @MikeMcQ suggested.

3 Likes

Have you confirmed a URL with www is being used? Do that from the screen that says "This Connection is Not Private" and just touch the domain name in the address box.

If it shows https://i2u2.org then you need to be using https://www.i2u2.org because your cert only has the www subdomain in it.

I walked through that just now on an iPad. It can easily be missed as Safari usually shows the simple form for the domain in the address box. That is why you must touch it to see the actual URL.

Some browsers automatically try various combinations of http and https and maybe Safari recently changed its preferences. I don't know. But, you should check this domain name as it would exactly explain your symptom and also explain why we don't see millions of failures reported

2 Likes

Chrome and Firefox will, upon encountering a certificate domain mismatch error, check if the domain would match the certificate after removing or adding www. and load the replacement URL if so.

As far as I can tell, there's no such code inside WebKit. Opening the non-www URL in a WebKit browser results in a certificate error, while Chrome/Firefox automatically tries the www variant (you can still see the failed request in the dev tools though).

Chromium: common_name_mismatch_handler.cc:117
Firefox: nsDocShell.cpp:6045

3 Likes

You can often debug mobile/ipad safari more easily by connecting your desktop safari dev tools to the mobile safari instance (with the device connected via USB). Debug Websites on iPhone Safari in 2026 | BrowserStack

I can't remember if you need xcode configured for the device as debug or not.

3 Likes

There's a good chance that's it. I do see different behavior between the two on the iPad. I can't explain why the problem is just now showing up, though, since I haven't changed anything lately.

I'll re-issue the cert to cover both forms of the URL later today and report back.

1 Like