First things first - I’m sorry users are still running into issues here! We understand that troubleshooting SSL issues can be frustrating.
Over the last few days, the Local team has tried to reproduce the issues in this thread; upgrading/downgrading Chrome, upgrading/downgrading OS versions, switching between macOS, Windows, and Linux machines… and we haven’t been able to get our machines into the same state, even on the same versions/combinations as those reporting the issue.
I don’t think this is a bug in Local - we haven’t made any changes to our SSL code - and I don’t want to just pass the buck and blame it on Chrome.
Here’s what we’re planning for next steps:
We’re going to prioritize moving Local to a single root certificate that all of a user’s sites will rely on; this should eliminate most SSL issues and means we’ll only have to trust Local **once.
In the meantime, if users run into this issues, the most common fix was closing Local, deleting the certs folder on the machine, and relaunching Local and regenerating certificates for the site. The theory is Chrome has an issue with the older certificates.
If you run into this in the meantime, here’s what we recommend:
Update to the latest Chrome (as of 11 Nov, that is 107.0.5304.107)
Close Local
Delete the certs folder (on Mac, ~/Library/Application Support/Local/run/router/nginix/certs. On Windows, %APPDATA%/Local/run/router/nginix/certs)
Open Local
Regenerate the certificates for your site(s)
On macOS, open Keychain and set your site to “Always Trust”
Come back to Local and open your site in the browser
Make sure you’re manually entering https in the address bar or hit Continue to {url} (unsafe) to bypass
If for some reason #8 doesn’t work for you, typing thisisunsafe into Chrome (really) and hitting Enter should let you bypass the warning.
If anyone is able to find consistent reproduction steps, we’ll jump back on this one ASAP. Thanks for sticking with us while we work on improving SSL in general!
I appreciate that you went through the trouble of trying to reproduce this issue and I can certainly understand it if you didn’t manage to do so. It seems to occur very randomly.
As I said in my initial post, I do believe that this is indeed a bug in Google Chrome, but nevertheless, I welcome the future changes you’ve suggested. Moving to a single root certificate seems like a step forward in terms of UX.
Sorry the fix you outlined above does not work for me. Everything I click “trust”, Local tells me it experienced a problem. Deleting the keys does not fix the issue for me in Chrome, Firefox, or Safari.
I’m also experiencing the issue in multiple browsers, including Chrome and Firefox, even after repeating the steps outlined by Austin (Windows). Firefox 106.0.5 is throwing this:
[domain] uses an invalid security certificate.
The certificate does not come from a trusted source.
@austinwendt Your steps did fix the issue! I would add to them after your step 3 to go to Keychain Access and search for existing certificates by typing in the local url and then delete any certificates that had been there. Even when I had gone to ~/Library/Application Support/Local/run/router/nginix/certs and deleted everything, there were still stragglers in Keychain Access and perhaps those were confusing the system when the new certs were generated? I had luck following your steps and after step 3 going to Keychain Access and manually searching for existing certificates and deleting those, too. Thank you!
MacOS Monterey 12.6
Chrome Version 107.0.5304.110 (Official Build) (arm64)
Local 6.4.3+6116
I have no /Local/ folder under /Library/Application Support/ so I can’t try deleting the certs folder as I don’t know where it is.
Deleting the cert in keychain and recreating doesn’t fix the issue.
SSL loads fine in Firefox, Safari and Brave.
EDIT: I was looking at the wrong /Library/Application Support/. Found the correct one and @austinwendt’s suggestion worked to allow opening sites in Chrome in unsafe mode (previously that option wasn’t available).
The only thing I noticed different was that when going into Keychain Access the cert was already trusted. This was on a site that I has previously trusted through Keychain Access, but had deleted the cert (@austinwendt’s step 3).
So I’m able to use Chrome now, but it does require unsafe mode.
EDIT (again): Turns out the cert that was already trusted in Keychain Access must have been the original. I’m not sure why it’s still showing up after deleting the folder. But I noticed Keychain Access refreshed after a bit and another cert with the same name was there and not trusted. After trusting the new cert the site now loads in Chrome normally (no longer in unsafe mode).
Update on the previous post I made. I noticed when going to Internet Properties → Content → Certificates → Trusted Root Certificate Authorities, there were multiple copies of Local’s certificate present! Same thing appears when I checked in certmgr.
Removing these duplicate certificates in certmgr, then following Austin’s steps to generate new certificates, caused me to get different error messages in both Chrome and Firefox. This one is bypassable normally in Chrome, without the thisisunsafe hack.
NET::ERR_CERT_AUTHORITY_INVALID
Issuer: The original certificate provided by the server is untrusted
Still not perfect, but thought I’d share. I’m assuming all that really happened here is the workaround Austin provided just duplicated another certificate on the system, instead of properly removing the old one.
Bug Report
Since I updated to the most recent version of Local, Google Chrome no longer trusts the majority of local websites. I’m not sure if this is an issue with Local or more specifically with Google Chrome (I couldn’t discover anything in their bug reports). With Microsoft Edge and Mozilla Firefox, it functions properly (which ironically is Chromium based).
Steps for replication:
Make a new website.
Utilize the Local UI to trust the website’s SSL certificate.
Change the home/site URL to https by logging into the WP admin.
the website with Google Chrome once more It’ll be noted and Environment Information:
Window 10
I also have the website Tripp Shrooms that have same issue. tell me how to solve.
