Local Community

SSL Not Remaining Trusted

I’m running Windows 10 and Local (Lightning) v5.2.3+2248.

For all my sites the same issue is occurring. I go to the SSL tab in Local and click on the Trust link to the right of the Certificate. It successfully trusts with the checkmark and the graying out of the Trust link. I then go to another tab, say Overview, and then go back to the SSL tab, now the Trust link is again green and the Certificate is not trusted.

If I try to trust a few times in a row, then the Heads Up notification shows up above the tabs and it also contains a Trust link. If I try to trust from that link it tries to do trust but after clicking it nothing happens or changes.

The Heads-Up! message is: Your site is using HTTPS but the Local SSL certificate isn’t trusted.

Tried running Local as admin and that didn’t fix it.

Help appreciated!

1 Like

I did some further testing and when I try to trust when I’ve opened Local as a non-admin, it doesn’t seem to hold the trust. When I close Local and then re-open as an admin then the Trust still shows as green and not trusted, but somehow the lock works in Chrome and the SSL is now trusted. I can then close Local and re-open as non-admin and the https holds up, so the certs are being trusted, but it’s a bit of a glitchy process to get them to be trusted. I think this is actually a bug, but it’s difficult to reproduce.

One thing, I have Open SSL v1.1.0 L installed (was trying to get localhost certified for https) and I noticed that Local uses Open SSL v1.1.1 b. Could there be some kind of conflict?

1 Like

One final thing, the https works in Chrome, but not Firefox. In Firefox I get this error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT. Any way to get the green lock icon and https to be trusted in Firefox as well as Chrome?

1 Like

I have the same issue. I have to enable SSL every time I launch Local, then I get a heads up message but as long as I restart my browser all is being displayed correctly. It’s just super annoying. Tested on Chrome and Edge (Chromuim), admin / non-admin Local launch. It’s as if the information wasn’t saved for W10

1 Like

Interesting! For me the SSL does remain trusted in Chrome, it does not work in Firefox at all. I don’t have to close Chrome to get the SSL to work, once it’s trusted it remains trusted. Doesn’t matter if I close Local and re-open it, the SSL remains trusted in Chrome. But Local is showing that all the certs for my sites are NOT trusted, so there’s clearly an SSL bug in Local.

1 Like

So actually I tested it again, and you’re right it remains trusted. So it points to a conclusion that this is a UX bug.

  • When I open Local, next to my Certificate in SSL tab I see Green Link saying TRUST
  • If I click it, it says that my site is Trusted BUT 5 seconds after I get the Heads Up message
  • If I then restart Local, Green Link is back as if it was never pressed BUT site is being displayed fine. As long as I don’t press it I don’t get the Heads Up message :wink:
1 Like

I’m running Local v5.2.5 now, and I’m on my other work computer, also Windows 10 OS. Getting a slightly different SSL issue now. I imported a website and in the SSL panel I trusted my site, it created a certificate named gutenberg.local. I then imported another website and trusted it as well. Except this website now has the gutenberg.local SSL showing up in Chrome and Firefox, as if Local created a single SSL cert based off the first website I created, then used that same SSL for all additional websites. This clearly doesn’t work as the details are wrong and so browsers are saying the SSL is no good. Clearly there are some major issues with the new Local Lightning. It’s so much faster, which is great, but I’m seeing major issues with SSL certs, with importing and exporting websites because of MySQL v8+ and other issues as well. I love the speed, but I’m almost tempted to go back to the old version as it at least had most major bugs worked out.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Hey @Essexpress – you messaged me about this topic so I thought I would open it back up to allow for more discussion:

I wondered if this ever got sorted please? - Or did you find you could work around it and it didn’t cause problems provided you use chrome?

I’m new and having the exact same problem with Local 6.1.5+5536

Have you used Live link to demo any sites?

I don’t think we ever fixed this, mostly because we don’t have really good replication steps.

If you can record a screencast of what you’re seeing, as well as attache a copy of the Local log, that would be helpful in determining what exactly is going on. See this Community Forum post for instructions on how to access the Local log:

As for the question about using Live Links to demo sites – Yeah, we use it fairly often. Our marketing teams will often share works-in-progress before going to the trouble of deploying to something like staging or production!

Hi Ben
Thanks for coming back. Here’s a picture of the Local Manager showing the site I managed to get the extensions loaded.
I did send you a log earlier - following the guide - please let me know if you need something different.

I made a full find and replace http=>https on this site before doing anything else. I tried a ‘Really simple SSL’ plugin - but this made no change and now the cURL error is back.

I found the folder with the crt files for nginx - which also has some deleted sites so I will try deleting these to see what happens - I haven’t found the Apache equivalent.

All the best

Hey @Essexpress – Just to be sure, in newer versions of MacOS you’ll need to manually trust the cert for a site:

Can you give the instructions in the above help doc a try?

Hi Ben
Yes - I’d already found that - and I had already use ‘Better Search and Replace Pug-in’ to transfer to https:. I set up some sites making that the first step just to check.

I’m on Windows 10 - and I checked with certmgr.msc - the local Certificates are all there in ‘Trusted Root Certification Authorities’ and Windows shows status as OK even though they are named:
OU = Fake Organizational Unit
O = Super Fake Company, Fake.
L = Fake Locality
S = XX
C = XX

But the public key 2048 bit binary certificate is there.

Chrome and Edge can view the site - firefox says NO!
I did a live link with someone who had Edge, and that went OK - it’s an old friend so I could take the risk.

That all sounds like things are working correctly! Basically, Local is a development tool, so the SSL certs that are being generated are all “Self-signed.”

This is fine in the sense that it allows you to test things out on your own machine and have the connection to the WordPress site be secure. The certificate uses fake data because this is a dev machine and it doesn’t make sense to go to the effort of generating, registering and maintaining certificates for development environments.

For production environments, you’ll totally want to go to the effort of configuring and installing a SSL certificate so that the end-users have a secure connection to the production site.

As for why Firefox still has issues – that’s just the way that Firefox is wired. They have settings in place to be very “noisy” about self-signed certificates. That’s probably a good thing, especially when visiting live, production sites because you typically want to be more aware of certificates that aren’t from a trusted Certificate Authority. But again, since this is a cert for a development environment, going to the effort and expense to get a full blown certificate doesn’t make sense.

Thanks for coming back
So, is this part of the guidance incorrect? If it’s not ‘staying trusted’?

I don’t think that part of the doc is incorrect, but maybe I’m not understanding where exactly the issue is.

In the Local UI, if Local doesn’t keep the SSL certificate trusted, then that means that Local wasn’t able to correctly register the certificate with the operating system. This can be a result of a number of things, often times related to strict security settings or antivirus configuration. In any event, if this is happening, then you’ll need to zero in on the specific thing that is preventing Local from registering an SSL certificate.

If Local shows the certificate as trusted, but individual browsers aren’t accepting the certificate, there are a few things to note:

  • The WordPress database might not have the correct HTTPS url, so you’ll need to verify that you are using the correct protocol within the browser’s address bar. If you can access the site over HTTPS by manually updating the browser’s address bar, then you should be able to update the url within the WordPress database to use the HTTPS protocol so that you don’t have to manually update that url.

  • If the SSL cert has been registered, and the URL within the DB is correct, then you’ll need to investigate the specific error that the browser is reporting for that certificate. In the case of Firefox, they are very noisy about Self-signed certificates. If that’s the error you are seeing, then there is nothing that Local can do to “fix” that message – that’s just Firefox being strict and you’ll have to manually accept that certificate in order to access the site over HTTPS.

Does that help clarify things a bit?

Hi Ben

I’ve moved from my laptop to my desktop, and now, for whatever reason, Chrome is not accepting the certificate - even though it’s installed and Windows marks it “certificate OK”.

Is Chrome giving you a specific error for why it isn’t accepting the certificate? As a test, if you try and access the site in another browser, does that browser accept the certificate? If there are problems in the other browser, is the error message they show the same or different from Chrome’s error?