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,
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?
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":
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?
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.
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.
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
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.
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.
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).
So while buffalochip.com was fine, it was being redirected to www.buffalochip.comafter 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? 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).