I'm trying to download files from noaa ncep site, but I get this error
usuario#wrf:~/wrf_data/GRIB$ curl https://ftp.ncep.noaa.gov/data/nccf/com/gfs/prod/gfs.2019020700//gfs.t00z.pgrb2.1p00.f000 -sslv3
* About to connect() to ftp.ncep.noaa.gov port 443 (#0)
* Trying 140.172.138.66... connected
* Connected to ftp.ncep.noaa.gov (140.172.138.66) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS alert, Server hello (2):
* error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
* Closing connection #0
I could download the files until Tuesday, I used this..
curl -O $FILEDWLT
The version
curl --version
curl 7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
I tried with wget and get similar error. I used a debian machine (squeeze), its old but for now is all I have.
Someone can guide me please?
Best Regards
Carina
Related
tl;dr
Git on Windows stops connecting to github because of mysterious "SSL protocol" errors. Halp!
The Issue
I'm developing on Windows, using a private GitHub repo for source control. When I first boot my system, I'm able to access the remote repo without issue - pull, push, fetch, etc. all work just fine.
After some amount of time(*), this stops, and I get the following error:
fatal: unable to access 'https://github.com/our-team/private-repo.git/': Unknown SSL protocol error in connection to github.com:443
(*) The amount of time seems variable - I've witnessed as little as an hour or two, up to a whole day. Usually after coming back from the system sleeping, it seems to be an issue, but I don't know if it's caused by a time delay or by the system sleeping.
Checking via cURL, I get
λ curl -v "https://github.com/our-team/private-repo.git/"
* Trying 192.30.252.130...
* Connected to github.com (192.30.252.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
CApath: none
* TLSv1.0, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to github.com:443
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to github.com:443
Using set GIT_CURL_VERBOSE=1 with git pull shows similar information. Sometimes it succeeds (see below), but most of the time it fails.
Further Notes
There's a little bit of a sporadic nature to it - sometimes I can get requests to succeed, but once it starts exploding, it's generally broken 9 out of 10 requests or more.
A successful cURL request looks like:
λ curl -v "https://github.com/our-team/private-repo.git/"
* Trying 192.30.252.130...
* Connected to github.com (192.30.252.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
CApath: none
* TLSv1.0, TLS handshake, Client hello (1):
* TLSv1.0, TLS handshake, Server hello (2):
* TLSv1.0, TLS handshake, CERT (11):
* TLSv1.0, TLS handshake, Server finished (14):
* TLSv1.0, TLS handshake, Client key exchange (16):
* TLSv1.0, TLS change cipher, Client hello (1):
* TLSv1.0, TLS handshake, Finished (20):
* TLSv1.0, TLS change cipher, Client hello (1):
* TLSv1.0, TLS handshake, Finished (20):
* SSL connection using TLSv1.0 / AES128-SHA
* Server certificate:
* subject: businessCategory=Private Organization; 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; serialNumber=5157550; street=548 4th Street; postalCode=94107; C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com
* start date: 2014-04-08 00:00:00 GMT
* expire date: 2016-04-12 12:00:00 GMT
* subjectAltName: github.com matched
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA
* SSL certificate verify ok.
> GET /our-team/private-repo.git/ HTTP/1.1
> User-Agent: curl/7.41.0
> Host: github.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: GitHub.com
< Date: Mon, 11 May 2015 15:19:43 GMT
< Content-Type: text/html
< Content-Length: 178
< Location: https://github.com/our-team/private-repo/
< Vary: Accept-Encoding
< X-Served-By: 76f8aa18dab86a06db6e70a0421dc28c
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host github.com left intact
The Question
I've googled a good bit on trying to find this (over the course of several weeks, so I don't have links), but most suggestions seem to point at certificate errors or OpenSSL version mismatches / bugs (which wouldn't be sporadic like this AFAIK).
What might be causing this failure, and how can I resolve it?
Relevant Software:
λ git --version
git version 1.9.5.msysgit.1
λ curl --version
curl 7.41.0 (i386-pc-win32) libcurl/7.41.0 OpenSSL/0.9.8zf zlib/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz
Oddly, it turns out that the issue is that the laptop was throttled because of a weak power supply. The docking station I was using was plugged into a low-amp powersupply (3.3 A), which, while it was compatible with the laptop, immediately kicked it into a heavily-throttled mode.
Apparently, this slowed everything down enough that the SSL handshake wasn't able to complete fast enough.
We finally tracked it down after reading a Dell support forum post (http://en.community.dell.com/support-forums/laptop/f/3518/t/19363340) that discussed slowness issues. The solution there was to change the power supply.
I had also experienced this slowness, but I did not think it was related. We swapped to a high-amp power supply for the dock, and everything was fine again, and the SSL errors described above went away.
That looks like an error which could result from the security initiatives taken after the Logjam attack -- weakdh.org --.
That resulted in the suppression of some ciphers accepted in a SSL/TLS transaction.
Note that, as reported in "Cannot communicate securely with peer: no common encryption algorithm(s)", you will be able to pass the right cipher list to curl via git.
Before that, you can also try if the issue persists while using a more recent Git for Windows (like the Git 2.4.1)
Had the same issue. Disabled my wifi connection and switched to cable and everything works again. Btw: Used a Dell in Docking-Station too.
I have make a request to url from the same server with a cron task. In the past I did this with the next bash script:
#!/bin/sh
curl "http://www.mydomain.es/myfolder/importTwitter" >> /var/log/mydomain/import_twitter.log
I migrated the website to https and the curl command fails returning the next error:
* About to connect() to www.mydomain.es port 443 (#0)
* Trying xxx.xxx.xxx.xxx...
* Connection refused
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
I have tried to add the next parameters to the curl command, and get the same error:
--cacert -> specify ssl ca root certificate
--cert -> specify ssl pem certificate
--location -> using the http url and force to follow redirects
--insecure -> allows insecure curl connections
Finally I also have tried make the request from another host and works fine, but I have do the request from the same server.
The server have Debian 3.2.65-1+deb7u2 x86_64
Curl version:
curl 7.26.0 (x86_64-pc-linux-gnu) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
* Connection refused
You've got your problem right there. Long before anything with crypto can start, your server simply does not allow a connection from your host.
Make sure your server is configured correctly and that no firewall is blocking loopback connections to port 443.
I'm on Windows attempting to use cURL using SSL, but running into certificate issues that I absolutely cannot figure out.
For example, here is an example of what I'm trying to run.
$ curl "https://google.com" --ntlm -v --negotiate -u USERNAME:PASSWORD --proxy "PROXY" --cert "c:\temp\curl-ca-bundle.crt"
* Adding handle: conn: 0x147ce88
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x147ce88) send_pipe: 1, recv_pipe: 0
* About to connect() to proxy PROXY port 8080 (#0)
* Trying 192.168.134.80...
* Connected to PROXY (PROXY_IP) port 8080 (#0)
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.30.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied OK to CONNECT request
* unable to use client certificate (no key found or wrong pass phrase?)
* Closing connection 0
curl: (58) unable to use client certificate (no key found or wrong pass phrase?)
Attempting to use --cacert instead of --cert yields the following message -
* Adding handle: conn: 0x130cdf8
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x130cdf8) send_pipe: 1, recv_pipe: 0
* About to connect() to proxy PROXY port 8080 (#0)
* Trying 192.168.135.80...
* Connected to PROXY (PROXY_IP) port 8080 (#0)
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.30.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied OK to CONNECT request
* successfully set certificate verify locations:
* CAfile: c:\temp\curl-ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://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.
The curl-ca-bundle.crt I have is from here, which was update a few minutes ago. I ensured the file is not blocked by Windows.
For what it's worth, I'm behind a corporate proxy and firewall. I have read everything I could find on this issue and don't know what to do next. I do realize I can ignore SSL, but would like to avoid this at all costs.
For what it's worth, I'm behind a corporate proxy and firewall. I have read everything I could find on this issue and don't know what to do next. I do realize I can ignore SSL, but would like to avoid this at all costs.
I would suggest the firewall does SSL interception, i.e. it works as a man-in-the-middle. To inspect encrypted connections it will split it into two encrypted connections, but of course it will not be able to sign the connection between browser and proxy with the original certificate. Thus it will create a new certificate, signed by a CA specific to the firewall. You need to add this CA to your CA bundle or the verification will fail.
For more details you might try to access the target site with a web browser and check the CA which signed the servers certificate or ask your system administrator for details of the SSL interception.
I am trying to use cURL and get the following error on every https request I make. The error is always the same. HTTP requests work flawlessly. The verbose output is quite useless.
bash:$ curl https://google.com -vv
* Adding handle: conn: 0x7fe09b803a00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fe09b803a00) send_pipe: 1, recv_pipe: 0
* About to connect() to google.com port 443 (#0)
* Trying 74.125.226.129...
* Connected to google.com (74.125.226.129) port 443 (#0)
* Unknown SSL protocol error in connection to google.com:-9805
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to google.com:-9805
bash:$ curl https://google.com -V
curl 7.30.0 (x86_64-apple-darwin13.0) libcurl/7.30.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz
bash:$ openssl s_client -connect google.com:443 < /dev/null
CONNECTED(00000003)
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
24255:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-50/src/ssl/s23_lib.c:182:
The results are the same on two different networks, so it does not appear to be network-specific. Attempting to connect using openssl s_client fails similarly so it is not library-dependent either (curl on the Mac uses SecureTransport). The debug output of s_client shows that the SSL handshake proceeds normally to the point where the client sends ChangeCipherSpec and the Finished messages but does not receive ChangeCipherSpec back from the server.
I have tried running these commands on a Debian VM on my Mac, and everything there runs correctly. In addition, using curl to connect to a local OpenSSL server (openssl s_server with a self-signed certificate) also works correctly.
I have looked through other answers on this forum and other places on the internet, but haven't found an answer. Most people's issues involve particular servers and the configuration of SSL on these servers. Mine however is problematic anytime HTTPS is used (with any website).
It was suggested that the issue might be in the certificate store. But if I understand it correctly, if the issue was with the certificate store, it would cause certificates to be rejected by all apps. However, all my browsers (chrome, safari, firefox) negotiate SSL with no problems. There is nothing suspicious in the environment variables for GUI applications or the shell.
Can someone please suggest what I should be looking into to solve the problem? Can it be that something is not properly configured? What should I be looking for?
I've been trying to install RVM all day and I've been hung up this entire time by curl, which refuses to connect to https://github.com.
Here is my current error: curl: (35) error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm
Here is the log output when I use the verbose flag:
* About to connect() to github.com port 443 (#0)
* Trying 192.30.252.130...
* Adding handle: conn: 0x100805400
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x100805400) send_pipe: 1, recv_pipe: 0
* Connected to github.com (192.30.252.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /System/Library/OpenSSL/certs/cacert.pem
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm
* Closing connection 0
I'm on a 2011 MacBook Pro running Mavericks (10.9.2). Brew says that my curl and my openssl are up to-date.
Originally, curl was telling me that github didn't have the proper SSL certificate, but I managed to finally get around that with this command: export CURL_CA_BUNDLE="/System/Library/OpenSSL/certs/cacert.pem"
Any help would be greatly appreciated!
I had the same error; I tried the "-k" option and it worked.
I figured it out. Turns out, my environment wasn't using the system curl, it was using Anaconda's version of curl, which was outdated and not linked to OSX's keychain. I simply used conda
remove curl to get rid of it and everything seems to be working fine now.