Valet: certificate problems in High Sierra

Created on 20 Oct 2017 · 31Comments · Source: laravel/valet

I recently upgraded to OSX High Sierra, and also updated all my brew recipes. Ever since I get certificate errors in my Laravel Passport guzzle/curl:

"cURL error 60: SSL certificate problem: unable to get local issuer certificate (see http://curl.haxx.se/libcurl/c/libcurl-errors.html"

I have no idea which action caused this problem unfortunately. I tried supplying php with an updated cacert.pem but that didnt seem to help. Anyone have an idea? This is currently preventing me from doing any development.

Source

corbosman

Most helpful comment

To get around this for now, locally I'm doing 'verify' => false, when I new up a Guzzle client instance.

etelford on 25 Oct 2017

👍5

All 31 comments

You might try switching your global composer to use valet's dev-master version, since there's an untagged fix you may need there.

Ref: https://github.com/laravel/valet/commit/7b2deaf8a4b1a6265009f02503e99a0aa8f14922

drbyte on 20 Oct 2017

Unfortunately that didnt help. The sites work fine, but curl doesnt. So when oauth2 client tries to make the oauth curl call to exchange code for token, it fails. If I unsecure the sites, things do work, but with broken ssl certs. (something is redirecting http -> https even when unsecure, not sure what, could be the browser)

corbosman on 20 Oct 2017

I think there is something up with the local curl in High Sierra. The osx version gives me cert error, if I install a brew version it doesnt. But if i install php71 using the brew curl, it doesnt fix my problem.

/usr/bin/curl https://passport.app
curl: (60) SSL certificate problem: unable to get local issuer certificate

/usr/local/opt/curl/bin/curl https://passport.app
<!DOCTYPE html>
<html>

corbosman on 20 Oct 2017

I just verified with someone else that they're seeing the same problem. It's not possible in High Sierra with php71 to curl to a valet secure site. So if you use guzzle for instance, it doesnt work.

I tried all kinds of ways to build my own php with different curl lib and openssl but I havent found the magic combination.

corbosman on 20 Oct 2017

Can you update the title of this issue to reflect that this symptom is specific to OSX High Sierra ?

drbyte on 20 Oct 2017

I imagine the underlying issue is that whatever curl is doing in this situation it's not linking into the Keychain to honor the local certificates.

drbyte on 20 Oct 2017

To get around this for now, locally I'm doing 'verify' => false, when I new up a Guzzle client instance.

etelford on 25 Oct 2017

👍5

Yeah, normally I would too but I use Laravel Passport, and client fails its guzzle call now. Turned off SSL altogether.

corbosman on 25 Oct 2017

Passport is actually working fine for me w/ SSL turned on, running Homebrew PHP 7.0, Laravel 5.5, and Passport ^4.0.

etelford on 25 Oct 2017

To be specific, it's league client that's failing its call to passport to exchange code for token. I run both oauth2 client and server on Valet for development.

corbosman on 25 Oct 2017

@corbosman This is the one that's failing for you?: https://laravel.com/docs/5.5/passport#requesting-password-grant-tokens

etelford on 25 Oct 2017

Yeah. Using League client.

[2017-10-20 19:46:53] local.ERROR: cURL error 51: SSL: certificate verification failed (result: 5) (see http://curl.haxx.se/libcurl/c/libcurl-err
ors.html) {"exception":"[object] (GuzzleHttp\\Exception\\RequestException(code: 0): cURL error 51: SSL: certificate verification failed (result: 
5) (see http://curl.haxx.se/libcurl/c/libcurl-errors.html) at /Users/cor/Vagrant/sites/portal/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.ph
p:187)

corbosman on 25 Oct 2017

Same issue here, @corbosman did you find something?

sylouuu on 15 Nov 2017

No, i was forced to turn off ssl for development on valet.

corbosman on 15 Nov 2017

If this ends up being unsolvable we will probably just remove SSL support from Valet entirely. Can you get cURL to work on High Sierra to any self signed certificates, even those that are created and managed completely outside of Valet?

adamwathan on 1 Dec 2017

I am also facing same issue. I uninstalled homebrew to diagnose the issue .. and now I am not able to install it.. Any solution guys ??

ravindra14 on 8 Dec 2017

With chrome now forcing HTTPS on .dev and other domains, this has imo become critical for valet. You cant even turn off SSL anymore.

corbosman on 9 Dec 2017

Switch to a different TLD, don't use .dev.

Valet uses .test by default now, that's what I have switched to as well. It will remain safe to use forever because it's guaranteed by RFC 2606.

I personally haven't upgraded to High Sierra yet on any of my machines so have no means troubleshoot this issue. Once I do (I'm not planning on it for at least a few more patch releases), I'll try and make time to troubleshoot this further.

adamwathan on 9 Dec 2017

👍3

Yup, moving to .test as I type this.

corbosman on 9 Dec 2017

For whoever is still wondering I had the same problem with valet and high sierra. I had to:

uninstall valet: composer global remove laravel/valet
remove valet folder sudo rm -r ~/.valet
Install it again composer global require laravel/valet
secure the local domain I wanna work on with valet secure <projectname>

MelMacaluso on 9 Dec 2017

👍1

I have not found a solution for this still.

gladgladwrap on 12 Dec 2017

For my specific situation I just forced the league client to disable ssl verification for local environment by registering a replacement class to the container that allows you to set verify=false.

corbosman on 12 Dec 2017

Ended up here because chrome rejected the certificate.
Moved domain to .test, unsecured and secured my sites again, now everything works for me.

Also tried curl just to seed what is going on, here is the full output which had some extra info (macOS 10.13.2):

curl https://demo.test
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure.

henriquebremenkanp on 13 Dec 2017

👍2

Facing the same issue with guzzle/curl (macOS High Sierra 10.13.1)

IamSwap on 11 Jan 2018

If you want to keep using .app or .dev, this will work. Modify as needed. Just use your own class instead of a GenericProvider, and override one method. This will allow you to set verify=>false, which I do when my environment is local.

namespace Auth\OAuth;

use League\OAuth2\Client\Provider\GenericProvider;

class PassportProvider extends GenericProvider
{
    /** override GenericProvider method */
    protected function getAllowedClientOptions(array $options)
    {
        $client_options = ['timeout', 'proxy', 'verify'];

        return $client_options;
    }
}

corbosman on 11 Jan 2018

With the merge of #515 I think this is resolved.
Feedback welcome; however a new thread would be a more appropriate place for new discussion.

drbyte on 19 Sep 2018

Not sure if anyone else is still seeing this issue still, but I have it in a similar setup to @corbosman's original problem setup (PHP 7.1, High Sierra).

Turns out that cURL in 7.1 isn't looking at the system CA bundle, which means the Laravel Valet CA certificate needs to be added to the openssl cert.pem bundle.

simonhamp on 19 Mar 2019

👍1

If anyone still get this error, is maybe because you change your DNS configuration for example, my DNS configuration is:

1.1.1.1
1.0.0.1

The solutions was only to change to

127.0.0.1
1.1.1.1
1.0.0.1

Adding the 127.0.0.1 to loop block for seach.
Note: Do you need to restart valet after this change.

Screenshot 2019-09-16 at 12 57 02

gravataLonga on 16 Sep 2019

👍3

@gravataLonga This is exactly what I’ve had to do for now, but this is happening regardless of custom DNS Servers or not.

One thing to bear in mind when adding this: you may experience unexpected results in public free Wi-Fi networks that require you to connect through their DNS host.

It’s not really related to the SSL issue and is more about hostname resolution.

The basic problem that this attempts to address is that cURL isn’t looking at 127.0.0.1 first when attempting to resolve domains. I haven’t found a fix for this yet.

simonhamp on 16 Sep 2019

For CURL not looking at 127.0.0.1 or not doing ip4 resolution, perhaps some of the ideas in this article may help: https://superuser.com/questions/830920/curl-local-host-names-on-mac-os-x-yosemite

inspect whether you have multiple localhost definitions in your hosts file (ideally you only want it to have 127.0.0.1 and ::1 defined to localhost)
add the --ipv4 flag to your ~/.curlrc file

Also consider blanking-out any Proxy bypass entries in your Network settings if there are any in there, at least as a test.

drbyte on 16 Sep 2019

Also, what's the output of the following on your command line:
scutil --dns

and
openssl version
curl --version

drbyte on 16 Sep 2019

Was this page helpful?

0 / 5 - 0 ratings