Gotcha! It might be best if we check to see if OpenSSL is installed. Could you take a look in Control Panel<Programs and see if you have anything installed that includes ‘SSL’ in the name? Thank you for your patience!
This worked! Thanks
With today’s update of Chrome to version 107.0.5304.107 you can at least open the “unsafe” backend again. The function “Continue to xyz (unsafe)” is available again.
Worked!
I don’t have any SSL related apps installed on my machine.
With today’s update of Chrome to version 107.0.5304.107 you can at least open the “unsafe” backend again. The function “Continue to xyz (unsafe)” is available again.
I am able to confirm this so at least there’s a temporary stopgap for now.
I have the same issue with SSL in Chrome after upgrading to MacOS Ventura, nothing else was updated. Works fine in other browsers.
NET::ERR_CERT_INVALID
MacOS Ventura
Chrome Version 107.0.5304.110 (Official Build) (x86_64)
Local 6.5.1+6195
LibreSSL 3.3.6
The note from @abroes about the “Continue” button is not actually present for me in that version of Chrome so it’s still not working.
Same problem here. This JUST started today for some reason (no idea why as I haven’t updated anything lately). All sites in Chrome Windows give the NET::ERR_CERT_INVALID error.
*Windows 10 Pro 21H2 (19044.2251)
*Chrome Version: 107.0.5304.107 (Official Build) (64-bit)
*Local Version: 6.4.3+6116
*Error: NET::ERR_CERT_INVALID
Following this thread, I went into the /certs folder and deleted every key/pair. Restarted Local, and trusted a site, this proceeded to create certificates for every single site even though I only trusted the one (seemed weird). Didn’t fix my problem though, still same error.
I also have been noticing lately (and don’t remember this happening previously), is everytime I click Trust, I get a Windows Notification in the corner that says “Local is requesting administrative privelages to trust a certificate” no buttons to accept or anything, just the notice.
Got it! I’m glad that you were able to find a stopgap!
Hi all,
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 hitContinue 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!
Austin, first of all, thanks for addressing this.
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.
This issue is affecting usage on Firefox as well.
Austin,
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.
Thanks.
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.
Error code: MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY
Curiously, Brave and Edge let me through with absolutely no warnings at all.
@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!
Same issue.
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).
I enabled allow insecre localhost in chrome, paste this in address bar
chrome://flags/#allow-insecure-localhost
And click or select “Enabled”
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.
This worked for me! Thanks
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.
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.