Local does a pretty good job of scrubbing private info from the logs and the errors it produces, however there’s always the possibility that something private can come through. Because these are public forums, always review the screenshots you are sharing to make sure there isn’t private info like passwords being displayed.
Unchecking the read only on /etc/hosts - did not make a difference.
Even on new trusted default site - I get connection insecure (latest Chrome fro Win 10)
Moreover, in adminer: wp_options contain https for the website
No, no xampp (or other) installed
Please also note that out of ~15 sites, 5 has valid SSL, others (newer ones) do not.
I am sure its an integration issue, most likely not Local bug, but still, it prevents Local
from providing the so-good service …
I hope you have more ideas - I am here to cooperate & help
Best
Mulli
Hey @Nick-B Thanks for asking. In short: yes & no.
Yes, I can put “thisisunsafe” into chrome and somehow the domain (I do it my in my dev. env only) is in some Chrome’s white list.
However, this is ugly (and not safe), and all my new sites are not using SSL as they should
Which also limits my work (e.g. interfacing with app’s that require SSL).
So NO - I am still stuch & unable to create SSL’ed websites
Also an ESET user here who’s locked into it staying on for company reasons, and I do think there’s some conflict between ESET and Local’s generated certificates that’s causing issues, but I still haven’t been able to narrow it down any further. I tried deleting Local’s certs in certmgr, temporarily disabling ESET, then generating the new certs and it gave me different behavior but ultimately still did not resolve it completely. I recreated my dev environment on my personal machine and it didn’t experience the issues at all there, so I’m near-certain it’s ESET.
Independently (I think), if you check any website with a Let’s Encrypt cert (including sites hosted on Flywheel), ESET reports it as the parent of that cert, which has got to mean it’s scanning it and messing with it in some way, but I’m no ESET expert.
@mulli I use ESET NOD32 and do see a similar issue in Chrome. I do most development with Firefox, which isn’t impacted.
I just loaded Chrome and tried to open a .local site, and received the invalid cert message. I used the “disable protection” option from the NOD32 systray icon, restarted Chrome and tried the site again – same result. After re-enabling the protection, I then went into the NOD32 settings and disabled SSL filtering (per [KB3126] Disable SSL filtering in ESET Windows home products (14.x–16.x)), restarted Chrome, and the site came up as expected. I suspect that disabling protection with the systray option is not disabling SSL filtering.
I don’t see an obvious way to exclude *.local domains from SSL filtering. The “exclude communication from trusted domains” option on that settings page indicates an internal whitelist/allowlist – I don’t see an obvious way to add to that list.
I also tried exporting the Local cert and importing it – click edit on “List of known certificates” on that settings page – but the cert didn’t appear to fully import (possibly due to missing corresponding CA cert?).
You may want to ask some questions of ESET technical support to see if there are any options to exclude the .local domains, or consider the Local cert as valid (likely by a successful import).
@burt HUGE Thanks for your response. Recently I did the following:
removed (complete uninstall) ESET
recreated certificated (delete & generate) - on few domains (since some certificates are ok!)
tried generating new sites with fresh SSL certificate.
Test: 2,3 fail to generate valid SSL
I am not sure if ESET causes the issue. Since I can regenerate the problem w/o it.
I can only recall that at some point (~ nov, 2022) the problem began.
So i have the old domains with valid SSL cert. but all new domains without.
I can confirm that following the steps to disable the “Enable SSL/TLS protocol filtering” setting in Advanced Settings worked like a charm and let me right back in! Thank you much for this post, burt.
