SSL Shows Not Valid In Safari and some version of Chrome on Mac computers

I have two computers both being a Mac that say the SSL Certificate are "Not Valid". We have set the date and time. Changed the wireless network, cleared the cash, Updated the browsers. The Mac OS is version 10.15.7 What can I do to resolve this issue or is the help somewhere that can help me with it,

Thanks

My domain is: buffalochip.com

I ran this command:

It produced this output:

My web server is (include version):AWS Amazon web services

The operating system my web server runs on is (include version): Windwos

My hosting provider, if applicable, is: Network solutions

I can login to a root shell on my machine (yes or no, or I don't know):I dont know

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

2 Likes

Hi @Mikek,

The macOS version on both of the computers displaying the error is 10.15.7? And the error appears when accessing https://buffalochip.com/ in a browser from those computers?

3 Likes

Welcome to the Let's Encrypt Community, Mike :slightly_smiling_face:

Based on what I'm seeing here:

https://www.ssllabs.com/ssltest/analyze.html?d=buffalochip.com

there are several concerns with the TLS/SSL configuration of buffalochip.com. Other than the items listed glaringly at the top, I noticed that buffalochip.com is serving the "short/alternate chain":

  1. buffalochip.com leaf certificate
  2. R3 signed by ISRG Root X1

rather than the "long/default chain":

  1. buffalochip.com leaf certificate
  2. R3 signed by ISRG Root X1
  3. ISRG Root X1 signed by DST Root CA X3
4 Likes

Is there someone that can help me get it set up correctly?

2 Likes

@griffin that shouldn't cause an error with a macOS 10.15.7 client, though, because that client should accept the short chain (Certificate Compatibility - Let's Encrypt).

3 Likes

I fully agree @schoen. I don't see any imminent reason for the invalid certificate error.

4 Likes

It looks like MS IIS is the webserver for buffalochip.com. You would need to modify the TLS/SSL protocols being used:

4 Likes

The buffalochip.com Short Name is redirected to www.buffalochip.com in my Chrome & Edge and the ISRG Root X1 appears valid in the short/alternate chain .Would that explain the error from the 10.15.7 on Chrome & Safari? How does a novice repair the "items listed glaringly at the top" or find an expert to do so?

2 Likes

Welcome to the Let's Encrypt Community, Brett :slightly_smiling_face:

The link I provided in my previous post should help clear up the insecure TLS versions and cipher suites being used. It's not extremely complicated or lengthy to do (less than an hour), but understandably that depends on the familiarity and comfort of those making the changes.

As far as the chain is concerned, there's nothing per se wrong with using the short chain. It's just recommended to use the long chain for maximum compatibility with certain older Android devices. @schoen was on the right track with his questions here as there seems to be no imminent reason for the systems in question to be considering the certificate to be invalid. I was simply pointing out several factors that could greatly improve the TLS/SSL functionality of the website.

4 Likes

Hi @BrettP, I didn't understand whether you are connected to the site @Mikek is asking about (and/or to @Mikek himself).

Although the SSL Labs report indicates some things that would be good to fix for general security purposes, none of them appear to be things that should cause an actual error or warning message in Safari or Chrome on macOS 10.15.7. So, I'm still not sure how to explain the original error report. It would be helpful to see a screenshot of the associated error message.

3 Likes

IMG_0293

1 Like

1 Like

I would if this might help out here. It entails obtaining the LE isrg root x1 cert from
https://letsencrypt.org/certs/isrgrootx1.pem.txt
Here's the link to the instructions for MAC OS El Capitan.


Also, the site is using tls1.0, tls1.1 and tls1.2. Safari may be refusing connection because of tls1.0.

Additionally, I found that BuffaloChip.com is getting a new LE cert once every 2 weeks and has been as far back as Oct 2019 where the search ended. Ouch!

The last precert from LE had expired back on 28 Sep 2020 and had 1 entry - www.buffalochip.com. The next precert comes from GoDaddy and is good for 1 year:
2971601804
precert //certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2 2021-10-02 06:14:03 2022-11-03 06:14:03 buffalochip.com, www.buffalochip.com - 2 entries
And the last LE cert issued:
2956380077
leaf cert CN=R3, O=Let's Encrypt, C=US 2021-09-28 21:18:49 2021-12-27 21:18:48 buffalochip.com, www.buffalochip.com - 2 entries

4 Likes

Forced renewals?
75 day threshold?

Either way, what a waste of certs!

4 Likes

The issue with https://www.buffalochip.com/ is that it's serving the expired R3, but https://buffalochip.com is fine. The server needs a reboot (or IIS bindings updated). Email them to tell them to do it.

[Edit: I've tweeted them the thread]

5 Likes

@Mikek guessing you work for BuffaloChip :slight_smile:

Your web server needs a reboot: if you're using Certify The Web ideally also make sure you have the latest version installed and set your renewal interval to 30 days or higher. If you are using win-acme just try a reboot.

4 Likes

Or lower?
75 is already (a lot) higher than 30 - LOL
It counts backwards FROM the expiry date.

4 Likes

I was referring to the UI if they happen to use Certify The Web, which can do either N days since last renewal or N days before expiry, defaulting to days since last renewal. Certify The Web historically had a high renewal frequency in older versions but now defaults to every 30 days (max 60). It will limit how close you can set the renewal to actual expiry because lots of folks struggle to resolve renewal issues early on (what do you mean I can't close port 80, I have 20 domains on one cert and 1 is failing validation etc).

4 Likes

Wow, I think I failed to check the difference carefully and then assumed it was a problem with SSL Labs.

Thank you for looking more closely in this case!

5 Likes

Nice catch, @webprofusion!

So while buffalochip.com was fine, it was being redirected to www.buffalochip.com after the DNS check (on the apex) which resulted in another DNS check (on the www) that was returning the expired R3 cert? So the redirect should have taken place before the DNS check happens? :thinking: Failing to reboot missed the updated rewrite rule and thus failed to serve the correct root cert. One for the MAC book. (no pun intended). :slightly_smiling_face:

5 Likes