Viewed   592 times

I was using cURL on my localhost for the longest time and all the sudden I noticed it no longer works unless I explictly set the option, CURLOPT_SSL_VERIFYPEER=FALSE.

I have no idea how/when this changed but I'm using NGINX and PHP and I can verify that this is not a specific issue to a specific requested host. I'm getting blank responses from and

Anyone have any thoughts?



Thanks to Dave Chen's suggestions, I realized I must have misplaced my certificate. The problem is solved by this certificate which is provided by the cURL creator (extracted from Mozilla):

So after downloading this cacert.pem file into your project, in PHP you can now do this:

curl_setopt($ch, CURLOPT_CAINFO, "/path/to/cacert.pem");

Alternatively, this can be set globally by adding the following to your php.ini

Thursday, December 15, 2022

The web site likely uses cookies to store your session information. When you run

curl --user user:pass  #works ok
curl #doesn't work

curl is run twice, in two separate sessions. Thus when the second command runs, the cookies set by the 1st command are not available; it's just as if you logged in to page a in one browser session, and tried to access page b in a different one.

What you need to do is save the cookies created by the first command:

curl --user user:pass --cookie-jar ./somefile

and then read them back in when running the second:

curl --cookie ./somefile

Alternatively you can try downloading both files in the same command, which I think will use the same cookies.

Thursday, October 27, 2022

Unfortunately, I don't have an easy way of checking it on Windows, so I'm going to use VirtualBox running on Linux here. Install vagrant, then:

$ vagrant box add laravel/homestead
$ git clone
$ cd homestead
$ git checkout v7.3.0
$ bash

I've simplified Homestead.yaml a bit (you might prefer to stick with the defaults):

ip: ""
provider: virtualbox
    - map: /home/yuri/_/la1
      to: /home/vagrant/code
    - map: homestead.test
      to: /home/vagrant/code/public


$ mkdir -p ~/_/la1/public
$ echo '<?php echo "it works";' > ~/_/la1/public/index.php

$ vagrant up

$ vagrant ssh -c 'ls /etc/nginx/sites-enabled'

$ vagrant ssh -c 'cat /etc/nginx/sites-enabled/homestead.test'
server {
    listen 80;
    listen 443 ssl http2;
    server_name .homestead.test;
    root "/home/vagrant/code/public";
    ssl_certificate     /etc/nginx/ssl/homestead.test.crt;
    ssl_certificate_key /etc/nginx/ssl/homestead.test.key;

As we can see it has the certificates in /etc/nginx/ssl:

$ vagrant ssh -c 'ls -1 /etc/nginx/ssl'

I tried to trust server certificate systemwide, but it didn't work out. It appeared on Servers tab in Firefox' Certificate Manager, but that didn't make Firefox trust it. I could probably have added an exception, but trusting CA certificates looks like a better option. Trusting CA certificate makes browser trust any certificate they issue (new sites running under Homestead). So we're going to go with CA certificate here:

$ vagrant ssh -c 'cat /etc/nginx/ssl/ca.homestead.homestead.crt' > ca.homestead.homestead.crt

$ sudo trust anchor ca.homestead.homestead.crt

$ trust list | head -n 5
    type: certificate
    label: Homestead homestead Root CA
    trust: anchor
    category: authority

Then, I've added homestead.test to /etc/hosts, restarted Chromium, and it worked:

P.S. I'm running Chromium 65.0.3325.162, and Firefox 59.0.


Apparently, Windows doesn't have trust utility. Under Windows one has two stores: Local Machine and Current User Certificate stores. No point in using Local Machine Certificate Store, since we're making it work just for our current user. Then, there are substores. With two predefined of them being of most interest: Trusted Root Certification Authorities and Intermediate Certification Authorities Stores. Commonly referred in command line as root and CA.

You can access Chrome's Certificate Manager by following chrome://settings/?search=Manage%20certificates, then clicking Manage certificates. Of most interest are Trusted Root Certification Authorities and Intermediate Certification Authorities tabs.

One way to manager certificates is via command line:

>rem list Current User > Trusted Root Certification Authorities store
>certutil.exe -store -user root

>rem list Local Machine > Intermediate Certification Authorities store
>certutil.exe -store -enterprise CA

>rem GUI version of -store command
>certutil.exe -viewstore -user CA

>rem add certificate to Current User > Trusted Root Certification Authorities store
>certutil.exe -addstore -user root pathtofile.crt

>rem delete certificate from Current User > Trusted Root Certification Authorities store by serial number
>certutil.exe -delstore -user root 03259fa1

>rem GUI version of -delstore command
>certutil.exe -viewdelstore -user CA

The results are as follows (for both Local Machine and Current User Certificate stores):

        appears in Trusted Root Certification Authorities tab
        doesn't work, appears in Other People tab
        doesn't work, appears in Intermediate Certification Authorities tab

Other options would be double-clicking on a certificate in Explorer, importing certificates from Chrome's Certificate Manager, using Certificates MMC Snap-in (run certmgr.msc), or using CertMgr.exe.

For those who have grep installed, here's how to quickly check where is the certificate:

>certutil.exe -store -user root | grep "homestead|^root|^CA" ^
& certutil.exe -store -user CA | grep "homestead|^root|^CA" ^
& certutil.exe -store -enterprise root | grep "homestead|^root|^CA" ^
& certutil.exe -store -enterprise CA | grep "homestead|^root|^CA"

So, installing CA certificate into Current User > Trusted Root Certification Authorities store seems like the best option. And make sure not to forget to restart your browser.

more in-depth explanation of how it works

In Vagrantfile it requires scripts/homestead.rb, then runs Homestead.configure. That's the method, that configures vagrant to make all the needed preparations.

There we can see:

if settings.include? 'sites'
    settings["sites"].each do |site|

        # Create SSL certificate
        config.vm.provision "shell" do |s|
   = "Creating Certificate: " + site["map"]
            s.path = scriptDir + "/"
            s.args = [site["map"]]


        config.vm.provision "shell" do |s|
            s.path = scriptDir + "/serve-#{type}.sh"


So, these two files create certificate and nginx config respectively.

further reading

How to make browser trust localhost SSL certificate?

Tuesday, September 13, 2022

I assume that your Tomcat doesn't like the protocol version that Ruby tries to negotiate. Ruby uses SSLv23 by default, but I've heard other cases where this was a problem for Java-based web servers. The error message you are getting indicates that the handshake fails while setting up the connection and trying to read the server's response. Try adding either

http.ssl_version = :TLSv1


http.ssl_version = :SSLv3

and see if that already helps.

If this does not fix the problem yet, it would be very interesting to see why your server rejects the connection attempt. Try running your Tomcat with and please post the relevant parts (connection information, exception stacktrace) as to why the attempt fails.

Tuesday, October 18, 2022

You're using the third party city-fan repository. This repo has dependencies which are in the EPEL repository, one of which is libnghttp2, so you must have EPEL enabled to use city-fan.

Friday, September 30, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :