puma-dev: macOS Sierra no longer trusts the puma-dev certificate
Hi,
After upgrading to Sierra, Safari and Chrome show an SSL error when trying to access sites served by puma-dev over https. Uninstalling and reinstalling puma-dev did not have any effect. Furthermore it appears that uninstalling does not remove the io.puma.dev directory and reinstalling does not prompt you to trust the certificate again.
I manually deleted ~/Application Support/io.puma.dev
and reinstalled which did prompt me to trust the certificate again, but still had invalid certificate errrors.
Thanks for puma-dev!
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 14
- Comments: 44 (14 by maintainers)
Commits related to this issue
- Allow TrustCert() to use the right keychain on Sierra This commit adds conditional logic to determine which keychain file `security` should add puma-dev’s certificate to. On OS X, the keychain file w... — committed to attilagyorffy/puma-dev by attilagyorffy 8 years ago
- Update root CA install for High Sierra * https://openradar.appspot.com/29271915 * https://github.com/puma/puma-dev/issues/84#issuecomment-341501499 — committed to basecamp/powprox by jeremy 7 years ago
I fixed this issue by opening Keychain Access and moving the
Puma-dev CA
certificate into theSystem
column under keychains then restarting my browser.Thanks! The original version from @attilagyorffy didn’t quite work for me, but this one did:
I was also running into an issue with trusting the puma-dev certificate authority in Firefox. Even though I had marked the certificate as “Always Trust” in Keychain Access, it seems like Firefox isn’t respecting those settings. Here’s how I manually added puma-dev as a trusted certificate authority. First, I symlinked the
cert.pem
file so that I could access it from the Finder file chooser dialog:Next, I navigated to the “Privacy and Security” Preferences screen in Firefox. Scroll down to the bottom and click the “View Certificates” button. On the “Authorities” tab, click the “Import…” button. Select the
puma-dev.pem
file that you just symlinked. This will open a dialog with checkboxes to check in order to trust the CA.@ecielam I suspect your Ruby installation is probably using the OpenSSL library from Homebrew, not the one that came with your system and has the keychain hooks. This means that you are going to need to make your OpenSSL aware of the puma-dev certificates.
To do this, you need to invoke the two commands:
@evanphx I wonder, should we improve puma-dev by invoking these commands these during install? (given that the openssl install is in place of course)
I had some issues where puma-dev wasn’t working in HTTPS even though a cert appeared in Keychain as Trusted, and I even uninstalled and reinstalled and ran
-setup
and-install
again, and nothing worked for HTTPS until I ran this:security add-trusted-cert -k login.keychain-db ~/Library/Application\ Support/io.puma.dev/cert.pem
Then everything started worked.
For those wondering about Firefox, I believe Firefox uses its own certificate store, not the system’s store.
I ran into this problem today after doing a full puma-dev reinstall:
I also changed the domain from
.dev
to.wip
, after reading @koenpunt’s comment. The CA was marked as trusted but I still had a warning of an insecure certificate when opening my URL with Safari. I’m running High Sierra 10.13.3.I think a step-by-step guide on the proper way to manage these errors should appear on the README of the project. I feel a little intimated by this task as I’m by no mean an expert in certificates stuff and I’m not sure I took the right actions after reading this pretty verbose and work-in-progressy thread.
Firefox controls its own CA store. You’ll need to import your puma-dev CA manually (from
~/Library/Application Support/io.puma.dev/cert.pem
) or configure Firefox to use the macOS trust store. See https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox.Just updated to latest Chrome (Version 63.0.3239.84) on High Sierra and ran into the same issue. Again.
Suggested solution from @joshmanders works
But there is one more step required. Right-click on the Cert once it’s in the Keychain, and go to Get Info. When there change the certificate to be trusted, like in this screenshot
You can just alway trust the whole cert for everything if you want, but I wouldn’t recommend it. Just SSL should be enough
I’m not sure how important it is to have this resolved in FF, if none of us developers use it for development as it’s only an issue in development. If we still need it to work there, your solution to treat it as an exception is a very good one.
I am also getting an SSL issue with Ruby HTTP libraries, while Chrome is now fine after the keychain manipulation.
I’m happy to help, @attilagyorffy. (I’m visiting family for the next couple of days, so I’ll be less responsive than usual.)
On my computer, I get the following:
I copied the keychain from my old MacBook Pro, which is why the middle entry is there. But I don’t think that matters. Here is the output of the command you use in your code:
I tried just including that directly, and it failed. But when I used the filename only (login.keychain-db) it worked.
It seems the reason the
security login-keychain
command isn’t working is because of the quotes I’m getting in the output.They can be removed with a little bit of a longer command.
and then adding it back to a one-liner
that worked for me @joshmanders
@attilagyorffy @danrabinowitz I completely uninstalled puma-dev and re-installed the latest released version, and I still got that Chrome warning.
Running
security add-trusted-cert -k login.keychain-db ~/Library/Application\ Support/io.puma.dev/cert.pem
manually fixed it. I see that puma-dev run a similar command: https://github.com/puma/puma-dev/blob/085e195645a53b028489f93c7d08d608a93df598/dev/ssl_darwin.go#L41But I’m still getting that big red warning in Chrome.
On my side, removing the
-d
switch and runningsecurity add-trusted-cert -k login.keychain-db ~/Library/Application\ Support/io.puma.dev/cert.pem
fixed the SSL error in Chrome (-r trustRoot
is already the default)I’m unsure if
-d
is suppose to add the certificate to the system keychain, but in my case it didn’t. Also, I noticed that without the-d
switch, it’s writtenThis certificate is marked as trusted for this account
and with it it’s writtenThis certificate is marked as trusted for all users
. That’s the only difference I saw when I clickedGet Info
on the certificate.EDIT Found a Radar explaining the issue: https://openradar.appspot.com/29271915
So I think we should either use the solution I found (drop the
-d
switch) or advice people to switch the Trust in the GUI in Sierra/High Sierra. Both worked on my side.I just want to mention the Chrome error code
NET::ERR_CERT_AUTHORITY_INVALID
andYour connection is not private
to make this issue more searchable.The Keychain Access approached solved my issue on Chrome and Safari. Thanks.
Firefox is still having issue, showing
Your connection is not secure
SEC_ERROR_UNKNOWN_ISSUER
though.