Multiple SSL issues in v6.4.3 on MacOS

Support
, ,
1

Issue Summary

Two different people at the same company having different SSL issues, due to latest 6.4.3 install on MacOS.

Troubleshooting Questions

  • Person #1:
    This person ended up auto upgrading to 6.4.3 (which as we found out, doesn’t work). While trying to debug all the issues we found the info here about the way to install it properly, and they did it. Fixing the general issues. However, ever since doing that they are stuck in SSL-heck. They keep being told by Chrome that the certificate is bad. Safari works fine. Doing the ‘thisisunsafe’ trick doesn’t work on Chrome either. They’ve accepted the certificate in keychain, and chrome, and it still doesn’t work.

This continues to not work even if they make a brand new local site and try to accept the cert there. They can access it via http, but not https.

  • Person #2 (me)
    I went ahead and downloaded the 6.4.3 install and did it to make sure I didn’t run into the issues that they were. However now I have a different (but still SSL) problem. I can talk to my local site fine. But when my code tries to access remote API servers, it fails with the error:
    “SSL certificate problem: unable to get local issuer certificate”

Replication

Unsure how for people to replicate.

System Details

  • Which version of Local is being used?
    6.4.3

  • What Operating System (OS) and OS version is being used?
    MacOS Monterey 12.5.1 (on both machines)

  • Attach the Local Log. See this Help Doc for instructions on how to do so:

I’ll work on getting a log from the other person

2

Update: Person #1 is on Monterey 12.6 … and attached is their log file:
local-logs (1).zip (32.7 KB)

3

Note/Update: I found this thread:

Which appeared to describe my own problem. However there’s a bit of a double-edged sword there. It talks about going into the /usr/local/etc directory and looking for the openssl directories. But I don’t have /usr/local/etc at all. And installing openSSL via brew didn’t change that.

4

Additional update on my problem. I have fixed it, but I’m confused as to what’s going on really.

So based upon that thread I mentioned. I had run:
var_dump(openssl_get_cert_locations());

And it showed me the following:

array(8) { ["default_cert_file"]=> string(35) "/usr/local/etc/openssl@1.1/cert.pem" ["default_cert_file_env"]=> string(13) "SSL_CERT_FILE" ["default_cert_dir"]=> string(32) "/usr/local/etc/openssl@1.1/certs" ["default_cert_dir_env"]=> string(12) "SSL_CERT_DIR" ["default_private_dir"]=> string(34) "/usr/local/etc/openssl@1.1/private" ["default_default_cert_area"]=> string(26) "/usr/local/etc/openssl@1.1" ["ini_cafile"]=> string(0) "" ["ini_capath"]=> string(0) "" }

ok, so it’s looking in /usr/local/etc/ for my certs. That’s cool. Except that I didn’t have that directory at all (no /etc/).

I made sure that openssl was installed:
brew install openssl

Then realized that that installed version 3 … so I tried to make sure that version 1.1 was installed:
brew install openssl@1.1

It already was installed. OK, OK. So I reinstalled it:
brew reinstall openssl@1.1

Right, so that didn’t really do anything … /usr/local/etc still didn’t exist.

I dug a bit more and realized that all those files existed on my machine as:
/opt/homebrew/etc/openssl@1.1
/opt/homebrew/etc/openssl@3.0

Hrmmm. So I went into /usr/local/etc and made a symlink for the openssl@1.1 folder.

And boom. My issues are solved. Which leads to going pourquoi??

6.4.1 didn’t have this issue. 6.4.3 does. Which implies that something about how the PHP version is compiled that comes with Local now is hardcoded/expecting the SSL certs to live in /usr/local/etc … when they may well not (and never did for me) on MacOS.

5

So some additional information that is interesting (to me at least):

On my issue

What’s interesting is that I went to work with the other person on their issue, and decided to make sure that their openssl directories were set up correctly as well even though they were seeing a different issue.

Turns out that their ‘brew’ is installing stuff in /usr/local/ … versus mine going to /opt/homebrew … So they didn’t have that issue.

In investigating this a bit more, it appears that this is because they have an Intel mac (bought nearly same time as mine), and mine is an M1. And straight from the homebrew page it states:

This script installs Homebrew to its preferred prefix (/usr/local for macOS Intel, /opt/homebrew for Apple Silicon and /home/linuxbrew/.linuxbrew for Linux) so that you don’t need sudo when you brew install .

So it would appear that this issue with the latest 6.4.3 with SSL certs (for outgoing access) that I had. Is only going to affect M1 macs?

On the other issue

Specifically the issue that they are getting when trying to access any SSL site locally is:
ERR_CONNECTION_RESET … There is no proxy, it’s just talking to the local server, etc. When it’s an SSL connection, that happens. So more help on that apprechiated

6

Hey @EliW - first off, thank you for such an amazing, detailed investigation!! This is super helpful for myself and for the engineering team. :slight_smile:

The engineering team met this morning and reviewed your posts along with some documentation from homebrew/Apple, and we created a ticket for making Local more gracefully handle this on Apple Silicon machines. As-is, yes, this will only affect the newer architecture, but Local should be able to detect where it needs to be looking for those to work appropriately. We’ll get that fixed up!

On the other SSL issue…
I see the single ECONNRESET in the user logs: {"thread":"main","class":"Updater","errno":-54,"code":"ECONNRESET","syscall":"read","level":"error","stack":"Error: read ECONNRESET\n at TLSWrap.onStreamRead (internal/stream_base_commons.js:209:20)","message":"read ECONNRESET","timestamp":"2022-10-11T19:42:10.158Z"}

But that appears related to the update issue upgrading to v6.4.3. Is this what you were referring to, or are you seeing a separate connection reset within Local after the update? Can you share a screenshot?

7

Hey @austinwendt … Thanks for responding. I’ve got good (and interesting) news on the ECONNRESET side of things.

So we’ve spent a lot of time looking into this for the other employee. Something that was really frustrating. And we realized a couple things:

  1. The problem started when they upgraded to 6.4.3
  2. Turns out in the ‘same day’ they upgraded to Monterary 12.6 (so we had some suspicions there)
  3. Weirdly Safari continued to work fine. But Chrome (and anything Chromium-based was a problem).

As we continue to debug, and install/wipe/re-install stuff. We finally ran into an error where it was complaining about not being able to bind the port. (443). ‘AH HA!’ … we looked and found that yes, there was a service running locally that was messing with that port.

And it turns out that it was … Parental Controls.

Yup. Somehow (with the Monterary 12.6 upgrade? shrug) Parental Controls got turned on for this employee’s laptop. And it appears that Safari goes ‘cool whatever’ when trying to connect to a local:443 … but Chrome basically under parental controls was stopping ALL access to anything port:443 locally. But not with any useful error message. (I assume that basically it’s assuming you are trying to use some local proxy to get around parental controls and so stopping you? Dunno, just speculating)

But turning parental controls off, fixed that.

\o/

1 Like
8

:laughing: While it is definitely frustrating, I’m glad you got it sorted!! Those darn Parental Controls.

We’ll dig in on the SSL filepath issue above, but let us know if there’s anything else we can do to help!

9

Hi @EliW - just following up on this thread. We believe the issue you described here should be resolved with the latest Local release, v6.5.2.

  • Person #2 (me)
    I went ahead and downloaded the 6.4.3 install and did it to make sure I didn’t run into the issues that they were. However now I have a different (but still SSL) problem. I can talk to my local site fine. But when my code tries to access remote API servers, it fails with the error:
    “SSL certificate problem: unable to get local issuer certificate”

In short, Local was expecting all users to have the SSL certificate installed at the same location; as we talked about, at least on an M1 machine, that filepath has changed. Rather than attempt to make Local account for any time this changes, Local will now rely on the CA that ships with WordPress to make API connections. If you get a chance to install the new version, I’d be curious if this solves your issue!

Edit - I forgot to note. You might need to swap the PHP version on your site and then swap it back (i.e., change it to PHP 8.1.9 and then immediately change it back, for example) to force Local to grab the new config file if for some reason it doesn’t automatically.

1 Like
10

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