macOS Sierra no longer trusts the puma-dev certificate

[benubois]

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!

[levriero]

I encountered the same issue, I also tried uninstalling and regenerating the certificates but still had errors.

A dirty workaround is to open the url with Safari, then selecting Always trust this certificate in the pop up window. Subsequent requests to that url will work as expected.

[navied]

@gbonfant I tried that same method, but I found that it eventually goes back to not trusting it again.

[joshmanders]

I fixed this issue by opening Keychain Access and moving the Puma-dev CA certificate into the System column under keychains then restarting my browser.

[rwilcox]

@joshmanders good find! This trick worked for me: went from having to bypass the security once every 5 minutes to not being asked at all (granted, it's only been an hour, but...)

[joshmanders]

It only worked for an hour for you? I've been going fine since doing it few hours ago.

[rwilcox]

I mean it was working, and stayed working for at least an hour, but then I had to stop coding...

[koenpunt]

The Keychain on macOS has been renamed, which could be the cause of this problem.

[attilagyorffy]

Currently puma-dev uses a hardcoded login.keychain file to add the certificate however the login keychain file in macOS has been renamed as @koenpunt points out.

I think we should try to use the security tool to identify the right file during the setup. In the meanwhile you can use the following command:

security add-trusted-cert -k $(security login-keychain) ~/Library/Application\ Support/io.puma.dev/cert.pem

I'll try to find the time and submit a patch, assuming @evanphx agrees with my approach.

[attilagyorffy]

I did create a patch that checks for the existence of the new keychain path and uses that if it's present. See #95, perhaps when @evanphx will have time to review it, it may get merged in.

[danrabinowitz]

Thanks! The original version from @attilagyorffy didn't quite work for me, but this one did:

security add-trusted-cert -k login.keychain-db ~/Library/Application\ Support/io.puma.dev/cert.pem

[attilagyorffy]

@danrabinowitz can i ask what did you get after having run my command mentioned above?

[danrabinowitz]

Sure. :-)

~ $ security add-trusted-cert -k $(security login-keychain) ~/Library/Application\ Support/io.puma.dev/cert.pem
SecCertificateAddToKeychain: The specified keychain could not be found.
1:~ $ security login-keychain
    "/Users/danrabinowitz/Library/Keychains/login.keychain-db"

I decided to try (based only on a guess) using just the filename without the full path, and it worked.

[attilagyorffy]

@danrabinowitz This is just a bare guess but your login keychain might be screwed. You see, the security command should list the login keychain where puma's cert should go. If you do not seem to have one, perhaps try to list the keychains your system is using:

$ security list-keychains

in my case, I'm getting the following:

    "/Users/attila/Library/Keychains/login.keychain-db"
    "/Library/Keychains/System.keychain"

I also wonder whether you would be willing to give me a little more help with cases like yours so that I could make the PR more robust, or at least improve it to provide better output to help people.

@evanphx What are your thoughts?

[danrabinowitz]

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:

$ security list-keychains
    "/Users/danrabinowitz/Library/Keychains/login.keychain-db"
    "/Users/danrabinowitz/Library/Keychains/old-mbp-login.keychain-db"
    "/Library/Keychains/System.keychain"

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:

$ security login-keychain
    "/Users/danrabinowitz/Library/Keychains/login.keychain-db"

I tried just including that directly, and it failed. But when I used the filename only (login.keychain-db) it worked.

[olivierlacan]

Any chance the version with this patch could be released @evanphx? We ended up building the latest dev version in hopes of solving this issue.

[lulalala]

I just want to mention the Chrome error code NET::ERR_CERT_AUTHORITY_INVALID and Your 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.

[ecielam]

I am also getting an SSL issue with Ruby HTTP libraries, while Chrome is now fine after the keychain manipulation.

[attilagyorffy]

@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:

$ cp ~/Library/Application\ Support/io.puma.dev/cert.pem /usr/local/etc/openssl/certs/io.puma.dev.pem
$ /usr/local/opt/openssl/bin/c_rehash

@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)

[allaire]

@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:

puma-dev/dev/ssl_darwin.go

Line 41 in 085e195

fmt.Sprintf(`security add-trusted-cert -d -r trustRoot -k '%s' '%s'`,

But I'm still getting that big red warning in Chrome.

On my side, removing the -d switch and running security 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 written This certificate is marked as trusted for this account and with it it's written This certificate is marked as trusted for all users. That's the only difference I saw when I clicked Get 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.

[koenpunt]

I believe the problem is also because of domain security policies, and that the .dev domain is configured to have HTST enabled by default, because the domain extension is owned by google

[allaire]

@koenpunt I'm using the .dev domain extension as well and we've been using puma-dev without https for a while, we just switched today to https in dev 😄

[attilagyorffy]

Thanks for the heads up, @allaire. If I remember correctly (the PR was done a long time ago) the -d switch was necessary on macOS prior to High Sierra. (I may be mistaken, though and I cannot verify anymore - I've upgraded).

The -d switch is supposed to add the cert to all users (as in adding it to the root cert store) as you pointed out. I don't know why this wouldn't work for you.

[allaire]

@attilagyorffy I don't think I'm an exception, and it looks like it's broken on High Sierra according to the Radar (my Macbook was clean install couple weeks ago).

Can you try on your side to completely uninstall puma-dev, uninstall certificates and re-install and see if you still get the chrome error?

[attilagyorffy]

@allaire Sure thing. I'll find some time to do today and report back.

[konung]

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

I fixed this issue by opening Keychain Access and moving the Puma-dev CA certificate into the System column under keychains then restarting my browser.

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

[attilagyorffy]

@allaire I've removed the puma-dev certificate from the keychain and uninstalled puma-dev from Homebrew. I've also removed the ~/Library/Application\ Support/io.puma.dev directory to ensure nothing was left. Then having reisntalled puma-dev from homebrew, I've done the setup and install commands:

❯ sudo puma-dev -setup
Password:
* Configuring /etc/resolver to be owned by attila

/private/etc/resolver 
❯ ll /etc/resolver/

/private/etc/resolver 
❯ puma-dev -install
* Adding certification to login keychain as trusted
! There is probably a dialog open that requires you to authenticate
* Certificates setup, ready for https operations!
* Use '/usr/local/Cellar/puma-dev/0.11/bin/puma-dev' as the location of puma-dev
* Installed puma-dev on ports: http 80, https 443

/private/etc/resolver 6s 

Everything seems fine on my side , Chrome (62.0.3202.94) won't complain about the certificates. I'm running High Sierra 10.13.2 (17C89). I've found is that the certificate in keychain seems to be Always Trusted by default (this is a screenshot without having to manually modify the certificates in keychain):

[kriskhaira]

I had issues similar to the ones mentioned in this issue. After trying out the solutions including @joshmanders' one about moving/copying the certificate to the System keychain in Keychain Access, it got resolved in Chrome, Safari and Opera.

However, I'm still having this problem in Firefox Quantum 57.0.1 (64-bit) on macOS—and the error is similar to the one faced by @lulalala. Anyone know how to solve this? It seems like Firefox is being suspicious of certain "SSL issuers" like Puma-dev CA. This is the full error:

sample.dev uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported. Error code: SEC_ERROR_UNKNOWN_ISSUER

I'm thinking of using the Advanced > Add Exception feature in the error page but it would be great if someone could point me to a better direction.

[balinterdi]

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.

[attilagyorffy]

@flaki you may have a better understanding of FF than I do. Do you happen to know what's causing FF to be 'picky' about self-signed certificates despite them being trusted in the system keychain?

[flaki]

Not sure. Let's Encrypt won't work for your usecase?

…

---- On Thu, 21 Dec 2017 15:10:47 +0100 notifications@github.com wrote ---- @flaki you may have a better understanding of FF than I do. Do you happen to know what's causing FF to be 'picky' about self-signed certificates despite them being trusted in the system keychain? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[aarongray]

If you can't get puma-dev to work, https://github.com/rchampourlier/tunnelss is a good alternative.

[dirtyhenry]

I ran into this problem today after doing a full puma-dev reinstall:

• Remove certificates from keychain and file system
• Uninstall via homebrew

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.

[andrewhavens]

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:

cd ~ && ln -s ~/Library/Application\ Support/io.puma.dev/cert.pem puma-dev.pem

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.

[chrishough]

that worked for me @joshmanders

[shanepinnell]

For those wondering about Firefox, I believe Firefox uses its own certificate store, not the system's store.

[joallard]

Thinking out loud about the security here, does trusting the CA mean that anyone can sign a certificate for any website and my system will trust it? Are there limitations to the cert? I'm not that well versed in the cert science here.

[okzea]

@andrewhavens' solution didn't work using symlink but copy paste worked :
sudo cp ~/Library/Application\ Support/io.puma.dev/cert.pem puma-dev.pem

[richardonrails]

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.

[nathanpalmer]

It seems the reason the security login-keychain command isn't working is because of the quotes I'm getting in the output.

security login-keychain

"/Users/nathan/Library/Keychains/login.keychain-db"

They can be removed with a little bit of a longer command.

security login-keychain | xargs | sed -e 's/^"//' -e 's/"$//'"

/Users/nathan/Library/Keychains/login.keychain-db

and then adding it back to a one-liner

security add-trusted-cert -k $(security login-keychain | xargs | sed -e 's/^"//' -e 's/"$//') ~/Library/Application\ Support/io.puma.dev/cert.pem

[nonrational]

I believe this is still an outstanding issue as of v0.13 on macOS Mojave. I'm working on some tests to verify the behavior, but security add-trusted-cert currently on master does not correctly trust the puma-dev CA. The -d flag to security add-trusted-cert meant to " Add to admin cert store; default is user" seems to be the issue.

[bradical]

Was there a resolution to this? I'm on Big Sur and still running into problems with the certificate being trusted.

[nonrational]

AFAIK it has been resolved as of the most recent version. What version are you running? Can you see the puma-dev CA in Keychain Access? If you manually trust it with the GUI, does it work? Have you tried -uninstall and reinstalling to regenerate a new certificate?

[bradical]

Ah, ok. It seems to work well on Safari but not on Firefox on MacOS Big Sur. Though perhaps that's a different problem? Do you all have a workaround for that?

[nonrational]

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.