Re-open issue 3227: CACert Error on `vagrant up`

[cliffbdf]

Issue 3227 was never resolved, but closed for some reason.

I have a similar issue to what Bassinator and others who posted on issue 3227 were seeing. I am also behind a proxy. I am on Windows 10, using git bash:

$ export HTTP_PROXY=...(my proxy) $ export HTTPS_PROXY=...(my proxy) $ vagrant box add centos/7 The box 'centos/7' could not be found or could not be accessed in the remote catalog. If this is a private box on HashiCorp's Vagrant Cloud, please verify you're logged in via vagrant login. Also, please double-check the name. The expanded URL and error message are shown below:

URL: ["https://vagrantcloud.com/centos/7"] Error: error setting certificate verify locations: CAfile: /mingw64/ssl/certs/ca-bundle.crt CApath: none

$ ls /mingw64/ssl/certs ca-bundle.crt ca-bundle.trust.crt

Note that git bash treats C:\Users\bergc\AppData\Local\Programs\Git\ as root (/). However, I have tried using a standard Windows command line, and get the same error:

URL: ["https://vagrantcloud.com/centos/7"] Error: error setting certificate verify locations: CAfile: /mingw64/ssl/certs/ca-bundle.crt CApath: none

[abacao]

Im having the same issue...

[rsalz]

i'm also having the same issue

[johnyesberg]

Same issue with Vagrant 2.0.0, Windows 10, standard cmd.exe shell.

[rushlin]

facing same issue, any update on this

[deionut]

same issue, here, on Windows 10

[chrisroberts]

Hi there,

I was trying to reproduce this behavior and was unsuccessful until I modified my HTTPS_PROXY end point to use https://. What are the values being used for the proxy environment variables? If you are using https:// protocol in either of them, does the end point have a valid certificate?

[johnyesberg]

My proxy at work certainly uses https://. I have no proxy at home. I only see the error when I'm at work. I set the HTTPS_PROXY environment variable to https://proxyname:8080 Note that if HTTPS_PROXY is not set, I get an error like: URL: ["https://vagrantcloud.com/centos/7"] Error: OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to vagrantcloud.com:443

But when HTTPS_PROXY is set, I get:

> vagrant box add centos/7                                                
The box 'centos/7' could not be found or                                  
could not be accessed in the remote catalog. If this is a private         
box on HashiCorp's Vagrant Cloud, please verify you're logged in via      
'vagrant login'. Also, please double-check the name. The expanded         
URL and error message are shown below:                                    

URL: ["https://vagrantcloud.com/centos/7"]                                
Error: error setting certificate verify locations:                        
  CAfile: /mingw64/ssl/certs/ca-bundle.crt                                
  CApath: none                                                            

When I run from git bash, the file /mingw64/ssl/certs/ca-bundle.crt' certainly exists. If I try tocurla file usinghttp://, it works. But it doesn't work forhttps://` sites.

$ curl https://www.google.com
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (77) error setting certificate verify locations:
  CAfile: /mingw64/ssl/certs/ca-bundle.crt
  CApath: none

I'm not sure what to try next.

[CmptrExpr]

Pleas try with http rather than https. The proxy itself may not be SSL enabled, but the two endpoints will negotiate an SSL tunnel anyway.

On Wed, Oct 25, 2017 at 8:49 PM johnyesberg notifications@github.com wrote:

My proxy at work certainly uses https://. I have no proxy at home. I only see the error when I'm at work. I set the HTTPS_PROXY environment variable to https://proxyname:8080 Note that if HTTPS_PROXY is not set, I get an error like: URL: ["https://vagrantcloud.com/centos/7"] Error: OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to vagrantcloud.com:443

But when HTTPS_PROXY is set, I get:

vagrant box add centos/7 The box 'centos/7' could not be found or could not be accessed in the remote catalog. If this is a private box on HashiCorp's Vagrant Cloud, please verify you're logged in via 'vagrant login'. Also, please double-check the name. The expanded URL and error message are shown below:

URL: ["https://vagrantcloud.com/centos/7"] Error: error setting certificate verify locations: CAfile: /mingw64/ssl/certs/ca-bundle.crt CApath: none

When I run from git bash, the file /mingw64/ssl/certs/ca-bundle.crt' certainly exists. If I try tocurla file usinghttp://, it works. But it doesn't work forhttps://` sites.

$ curl https://www.google.com % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (77) error setting certificate verify locations: CAfile: /mingw64/ssl/certs/ca-bundle.crt CApath: none

I'm not sure what to try next.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/hashicorp/vagrant/issues/8984#issuecomment-339516589, or mute the thread https://github.com/notifications/unsubscribe-auth/AHp8SL9FIZGOLgEULjtDNj3HjKSa8MyVks5sv9cBgaJpZM4Pcn_W .

-- Steve Freeman

[johnyesberg]

Thanks Steve, When my environment variable is HTTPS_PROXY=https://proxyname:8080 I get the error above. When my HTTPS_PROXY=http://proxyname:8080 it seems to work. So perhaps that's solved. (I wonder whether that will break any other tools, though...)

[samuliasmala]

Same issue here with Vagrant 2.0.2 and Windows 10. Steve's solution to set HTTPS_PROXY=http://proxyname:8080 solved the problem for me as well.

Is this a problem with the company proxy I'm using or with Vagrant?

[abacao]

Currently I'm using vagrant-proxy plugin with Fiddler.

I have this on my Vagrantfile inside windowsuser/.vagrant.d/

config.proxy.http = "http://10.0.2.2:8888" ##localhost of the baremetal box config.proxy.https = "https://10.0.2.2:8888" config.apt_proxy.http = "http://10.0.2.2:8888" config.apt_proxy.https = "https://10.0.2.2:8888" config.proxy.no_proxy = "localhost,127.0.0.1"

[chrisroberts]

My suspicion is that the remote proxy is using a custom cert, and it has been installed and seen as trusted on the host, which is why it would work else where. However, Vagrant is using the cert bundle it has embedded, which would not trust the custom cert leading to the error. I'm working on an update to the windows embedded curl to use winssl which would likely resolve the underlying issue.

[cliffbdf]

On Mar 27, 2018, at 11:37 AM, Chris Roberts notifications@github.com wrote:

My suspicion is that the remote proxy is using a custom cert,

That is standard practice for most enterprises that use proxies - to create a self-signed cert for their proxy.

and it has been installed and seen as trusted on the host, which is why it would work else where. However, Vagrant is using the cert bundle it has embedded, which would not trust the custom cert leading to the error. I'm working on an update to the windows embedded curl to use winssl which would likely resolve the underlying issue.

[IshuS]

This issue is only occurs when I am working behind a proxy at my work. The following solution worked for me. HTTP_PROXY = http://proxyname:proxyport HTTPS_PROXY = https://proxyname:proxyport

You will also have to set the following in your vagrant file config.vm.box_download_insecure = true

[twblamer]

This is also causing problems for me on Windows 10 behind a corporate proxy.

As others noted, I need to HTTP_PROXY and HTTPS_PROXY env variables to the proxy's http:// URL.

I also had to set config.vm.box_download_insecure = true in my Vagrantfile, without it I hit a different error:

An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.

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

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.