"SSL connect error" on Windows

[gm23]

I am currently building servo on Windows 10 Pro, version 1511 (64-bit), with msys2 (64-bit) and inside the MinGW-w64 shell, and I get the following error message:

$ ./mach build --release --verbose
cargo build --release -v
 Downloading url v0.5.5
unable to get packages from source

Caused by:
  failed to download package `url v0.5.5` from https://crates.io/api/v1/crates/url/0.5.5/download

Caused by:
  SSL connect error
Build completed in 2.15s

Which is strange as curl works without problems (with redirection):

$ curl -v -L https://crates.io/api/v1/crates/url/0.5.5/download > file
* timeout on name lookup is not supported
*   Trying 23.21.180.91...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to crates.io (23.21.180.91) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: C:/msys64/mingw64/ssl/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [89 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2152 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*        subject: CN=www.crates.io
*        start date: Nov  5 16:52:33 2015 GMT
*        expire date: Nov  7 22:55:23 2016 GMT
*        subjectAltName: crates.io matched
*        issuer: C=US; O=GeoTrust Inc.; CN=RapidSSL SHA256 CA - G3
*        SSL certificate verify ok.
} [5 bytes data]
> GET /api/v1/crates/url/0.5.5/download HTTP/1.1
> Host: crates.io
> User-Agent: curl/7.47.1
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 302 Found
< Connection: keep-alive
< Server: nginx
< Date: Thu, 10 Mar 2016 03:58:47 GMT
< Transfer-Encoding: chunked
< Location: https://crates-io.s3-us-west-1.amazonaws.com/crates/url/url-0.5.5.crate
< Set-Cookie: cargo_session=--PBVtejYpqgihoNU4gy+Z6jCDXMg=; HttpOnly; Secure; Path=/
< Strict-Transport-Security: max-age=31536000
< Via: 1.1 vegur
<
* Ignoring the response-body
{ [5 bytes data]
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Connection #0 to host crates.io left intact
* Issue another request to this URL: 'https://crates-io.s3-us-west-1.amazonaws.com/crates/url/url-0.5.5.crate'
* timeout on name lookup is not supported
*   Trying 54.231.236.0...
* Connected to crates-io.s3-us-west-1.amazonaws.com (54.231.236.0) port 443 (#1)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: C:/msys64/mingw64/ssl/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [89 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2544 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-SHA
* ALPN, server did not agree to a protocol
* Server certificate:
*        subject: C=US; ST=Washington; L=Seattle; O=Amazon.com Inc.; CN=*.s3-us-west-1.amazonaws.com
*        start date: Dec  8 12:05:08 2015 GMT
*        expire date: Sep 21 12:00:00 2016 GMT
*        subjectAltName: crates-io.s3-us-west-1.amazonaws.com matched
*        issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert Baltimore CA-2 G2
*        SSL certificate verify ok.
} [5 bytes data]
> GET /crates/url/url-0.5.5.crate HTTP/1.1
> Host: crates-io.s3-us-west-1.amazonaws.com
> User-Agent: curl/7.47.1
> Accept: */*
>
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0{ [5 bytes data]
< HTTP/1.1 200 OK
< x-amz-id-2: bLCVbUt7EAiyHdocFASXq5cvWafLdRMqsy26ipTQLL9JtqAuav3qe4WyCc5gv4LPOajZ9XbaWWc=
< x-amz-request-id: 13BCB59D959EBB6A
< Date: Thu, 10 Mar 2016 03:58:49 GMT
< Last-Modified: Wed, 10 Feb 2016 15:54:33 GMT
< ETag: "94ea7a572a87cab3383bc45f9024a730"
< Accept-Ranges: bytes
< Content-Type: application/x-tar
< Content-Length: 281821
< Server: AmazonS3
<
{ [5 bytes data]
100  275k  100  275k    0     0   212k      0  0:00:01  0:00:01 --:--:--  764k
* Connection #1 to host crates-io.s3-us-west-1.amazonaws.com left intact

I even tried to disable the Windows firewall completely, still with the same result (also that would not explain why curl works and cargo does not).

I would appreciate if someone could name a few options to get a more verbose output from cargo (more verbose than --verbose).

[alexcrichton]

Do you have any other firewalls or antivirus programs in play? We use WinHTTP so whether or not curl works locally is likely a red herring.

[pffang]

Sadly, http.cainfo doesn't work on Windows MSYS2.

[alexcrichton]

@pffang oh I think that's because on Windows you can't actually specify a custom certificate for a secure connection, the system root trust store must be modified. I think curl may actually just ignore that option on Windows...

[pffang]

@alexcrichton Em...But the custom certificate what is used in my Ubuntu machine was exported from 'Trusted Root Certification Authorities' of my Windows machine.
Administrators already installed the custom certificates in every computer of my company.

[alexcrichton]

@pffang oh dear! In that case I think libcurl should work, although I don't know why it wouldn't :(

Unless maybe some other certificate is being negotiated?

[nugend]

In general the way cargo is surfacing connection related issues is really frustrating. I've just spent 2+ hours banging my head trying to figure out what is going wrong with my Proxy (I think my problem might have something to do with NTLM... maybe? still not really sure).

[alexcrichton]

@nugend unfortunately I think these errors are originating from libcurl and we're not getting much more from the library currently. Do you have the ability to try a dev version of Cargo though? Doing some digging I found another option in libcurl which may help us extract more information.

[alexcrichton]

I've updated the libcurl Rust bindings, and if you can give #3137 a whirl it'd be valuable to see if that has an impact here!

I know libcurl errors also can come from libgit2, and I want to make sure we're not accidentally losing information there as well.

[nugend]

@alexcrichton I'll see what I can do, but (please correct me if I'm wrong): Don't I need to be able to have cargo download dependencies in order to build cargo?

[alexcrichton]

@nugend true yeah, to build Cargo you'll need Cargo to download pieces here and there. Another option is to wait until #3137 is merged and we'll have new nightlies available.

[alexcrichton]

@nugend as a heads up #3137 landed recently so the next nightly of Cargo should have that extra info. Want to give it a spin and see if it gives you a better error?

[nugend]

So I actually managed to figure out my problem (the cert chain for the proxy was separate from the global cert chain and they needed to be combined correctly).

But I did just try the nightly version with the correct configs removed (tried stepping through a few of the scenarios I was trying to fix it with)

Some of the error messages are definitely better. The error message that I was getting stuck on (60) isn't really better at all though (basically, not knowing which peer certificate can't be authenticated makes it very confusing about what's going on and the curl error text doesn't report jack shit about that. I'm also honestly confused about how the curl command line is finding certificates that work with the proxy, but that's got nothing to do with Cargo).

Still, it's definitely a net win in terms of making it easier to diagnose why some of the failures are happening.

The only additional suggestion I would make here is that it would be helpful to indicate that the error code reported is a libcurl error code.