Renewed SSL Certificate, 'connection is not private' error message now showing for most users

[cmax]

Hi there,

We recently renewed our SSL Certificate through 123reg.com - using Let's Encrypt. Our certificate is now valid.

Problem - Every day we are now having users issues where they cannot access our site, receiving error messages stating that the connection is not private. This is a temperamental issue, happening on Safari, Chrome and other browsers. Sometimes users can get on, and sometimes they can't. It is an irregular issue.

Our site has an e-commerce element, which means this issue is costing us money.

We have ran checks through SSL Labs and the check confirmed our SSL Certificate is valid and working.

Please can anyone advise what the problem might be? We are at a real brick wall with it.

The site is - https://jab-box.com

Thank you in advance.
C

[petercooperjr]

For what it's worth, your site looks fine to me. It looks to be sending an unexpired certificate and the full chain that it should be. Can you reproduce the problem yourself, or is it just some of your users that are reporting problems? Is it possible to get any screenshots of what errors and certificate they're receiving?

[danb35]

If 123reg.com is your web host, that's really who you should be contacting for support. The SSLLabs test indicates that your site works only with browsers that support SNI, but that would be any modern browser, so that shouldn't be a problem. And unfortunately, "connection is not private" gives little indication of what's going on--if any of the affected users can send a screen shot of what happens when they click "Advanced", that would give a better indication of the real problem.

The only issue SSLLabs is finding is that you're serving the root certificate in addition to the intermediate and leaf certs, which isn't optimal, but shouldn't be causing any errors.

[petercooperjr]

@danb35

The only issue SSLLabs is finding is that you're serving the root certificate in addition to the intermediate and leaf certs, which isn't optimal, but shouldn't be causing any errors.

That's not what I'm seeing; I see the chain ending with the typical ISRG Root X1 signed by DST Root CA X3.

$ openssl s_client -connect www.jab-box.com:443 </dev/null
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = jab-box.com
verify return:1
---
Certificate chain
 0 s:CN = jab-box.com
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: May  2 08:46:35 2022 GMT; NotAfter: Jul 31 08:46:34 2022 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT
---

And SSLLabs looked the same to me. Are you seeing something different?

[danb35]

@petercooperjr

That's not what I'm seeing; I see the chain ending with the typical ISRG Root X1 signed by DST Root CA X3.

Yes--and it's serving ISRG Root X1. It shouldn't be doing that. The roots should already be in the system trust store, not served by the website.

[cmax]

Hi Peter, many thanks for your help on this. I can't reproduce the problem myself, and I have always been able to get on with no issues. It is a case of some users (although we get it every day), that can't get on. The attached image is the message 90% of them have when trying to access the site. Many thanks! Connor

[petercooperjr]

If you could get someone to click that Advanced button and get a screenshot of the actual certificate they're receiving, that would be helpful.

[cmax]

Hi Peter & Dan,

Thanks both for your help. I will get the next user who has an issue to click 'advance' and will send you the screenshot.

Thank you,

Connor

[petercooperjr]

Just to be clear, I'm not sure how one looks at the certificate most easily in mobile browsers; it may be that there are some clicks needed after that Advanced button. We're looking for something like this (which is what I see, showing a valid normal cert):

Are people only having trouble from mobile? Or also from desktops?

[MikeMcQ]

@danb35

Yes--and it's serving ISRG Root X1. It shouldn't be doing that.

jab-box server sends the same chain as letsencrypt.org. Looks normal to me.

[cmax]

Okay thanks Peter, I will relay this to the user. People are having trouble from both mobile and desktop, at different (albeit random) intervals.

I found this on the web on Nortons site, which specifically notes a change that Let's Encrypt made at the end of last year, possibly affecting older devices. Do you think this could be the issue?

Article link - How to fix a “Your connection is not private” error | NortonLifeLock

Article paragraph:

What is the “Your connection is not private” error?

A “your connection is not private” error means your browser cannot verify whether a website is safe to visit. Your browser issues this warning message to prevent you from visiting the site, because visiting an unsafe or unsecure site may put your personal information at risk.

Your browser verifies a site's security certificate to confirm the site will protect your privacy while visiting it. If a certificate is not up to standard, this means your personal data might not be encrypted and therefore susceptible to online threats. In short, a "your connection is not private" error means just that: Your connection is not private, and the error isn't something to ignore.

The “Your connection is not private” error made headlines in September 2021, thanks to the scheduled expiration of the digital certificates issued by Let’s Encrypt.

Let's Encrypt is one of the biggest issuers of the HTTPS certificates that encrypt or scramble the connections between your smartphones, laptops and other devices and the Internet. These certificates and the encryption they provide ensure that snoops can't steal your data as you search the web.

Thanks to these certificates, cybercriminals can't read your log-in information when you connect to your online bank, snatch your passwords when you sign into your online credit card portal or snoop on emails between you and your healthcare providers.

In late September, though, Let's Encrypt saw its root certificate expire. Those relying on older devices to connect to the Internet, then, might have seen an increase in the number of "Your connection is not private" errors as they searched the web.

The root certificate that Let's Encrypt uses — known as the IdentTrust DST Root CA X3 — was scheduled to expire on September 30, which it did. Because of this, computers, devices, and browsers after this date no longer trust the certificates that had been issued by Let's Encrypt. Tech experts say this wouldn’t cause problems for most consumers. But they did say that devices running older software, such as older model smartphones, are most likely to see more “Your connection is not private” errors because of the Let’s Encrypt certificate expiration.

[petercooperjr]

Your site is sending the "long" chain, which has the highest compatibility (and, for instance, is the same chain as this very forum uses).

You can see the list of expected-to-work platforms on this documentation page:

Certificate Compatibility - Let's Encrypt

But unless you have a lot of users that run really old systems (like Android before 2.3.6, or non-SP3 Windows XP), then it's likely not the issue you're seeing.

[rg305]

[cmax]

What exactly does this mean?

Thank you in advance,
Connor

[rg305]

That depends entirely on what you mean by "this".
Otherwise, the literal meaning of "this" is:

[petercooperjr]

I think what @rg305 is trying to say is that some people may be behind firewalls which are intentionally blocking your site, as those firewalls think that your site is hosting some sort of malware. If that is in fact the case, then really this is HTTPS working as intended, where attempts to intercept your site are being blocked. I'm not personally familiar with these firewalls to understand what they might be detecting or why, though.