What is the difference between the two https wget request? One is getting download while other is having certificate issue on same machine
-- not working
/home/bsoft>wget https://storage.googleapis.com/minikube/iso/minikube-v1.25.2.iso
--2022-04-29 01:16:42-- https://storage.googleapis.com/minikube/iso/minikube-v1.25.2.iso
Resolving storage.googleapis.com (storage.googleapis.com)... 216.58.221.48, 142.250.194.240, 142.250.206.112, ...
Connecting to storage.googleapis.com (storage.googleapis.com)|216.58.221.48|:443... connected.
ERROR: cannot verify storage.googleapis.com's certificate, issued by ‘emailAddress=certadmin#netskope.com,CN=ca.stlgs.goskope.com,OU=86e3620a322d5cba9f90e0eedfd92cdd,O=bsoft technology,L=Gurugram,ST=IN,C=IN’:
Self-signed certificate encountered.
To connect to storage.googleapis.com insecurely, use `--no-check-certificate'.
/home/bsoft>
-- working
/home/ravi>wget https://speed.hetzner.de/100MB.bin
--2022-04-29 09:57:31-- https://speed.hetzner.de/100MB.bin
Resolving speed.hetzner.de (speed.hetzner.de)... 88.198.248.254, 2a01:4f8:0:59ed::2
Connecting to speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: ‘100MB.bin.2’
100MB.bin.2 100%[=================================================================================================================================================================>] 100.00M 783KB/s in 98s
2022-04-29 09:59:10 (1.02 MB/s) - ‘100MB.bin.2’ saved [104857600/104857600]
/home/ravi>
Related
I was using wget to download GEDI data from LP DAAC data pool. It always returns an error of "unable to establish SSL connection". I attempted wget in promote or Pycharm and added the "--no-check-certificate" configuration.
The wget is the newest release (1.21.3,64bit).
OS: windows11.
from the following massages, I guess the connection to EarthData is successful because it returns the data downloading link that I can open manually in the browser and then can start downloading. This error could happen in the last step that wget starts accessing the returned link and then downloading.
returned messages:
--2022-08-14 09:51:09-- https://e4ftl01.cr.usgs.gov//GEDI_L1_L2/GEDI/GEDI01_B.002/2019.04.20/GEDI01_B_2019110092939_O01996_01_T03334_02_005_01_V002.h5
Resolving e4ftl01.cr.usgs.gov (e4ftl01.cr.usgs.gov)... 2001:49c8:4000:127d::133:130, 152.61.133.130
Connecting to e4ftl01.cr.usgs.gov (e4ftl01.cr.usgs.gov)|2001:49c8:4000:127d::133:130|:443... failed: Bad file descriptor.
Connecting to e4ftl01.cr.usgs.gov (e4ftl01.cr.usgs.gov)|152.61.133.130|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://urs.earthdata.nasa.gov/oauth/authorize?scope=uid&app_type=401&client_id=ijpRZvb9qeKCK5ctsn75Tg&response_type=code&redirect_uri=https%3A%2F%2Fe4ftl01.cr.usgs.gov%2Foauth&state=aHR0cHM6Ly9lNGZ0bDAxLmNyLnVzZ3MuZ292Ly9HRURJX0wxX0wyL0dFREkvR0VESTAxX0IuMDAyLzIwMTkuMDQuMjAvR0VESTAxX0JfMjAxOTExMDA5MjkzOV9PMDE5OTZfMDFfVDAzMzM0XzAyXzAwNV8wMV9WMDAyLmg1 [following]
--2022-08-14 09:51:55-- https://urs.earthdata.nasa.gov/oauth/authorize?scope=uid&app_type=401&client_id=ijpRZvb9qeKCK5ctsn75Tg&response_type=code&redirect_uri=https%3A%2F%2Fe4ftl01.cr.usgs.gov%2Foauth&state=aHR0cHM6Ly9lNGZ0bDAxLmNyLnVzZ3MuZ292Ly9HRURJX0wxX0wyL0dFREkvR0VESTAxX0IuMDAyLzIwMTkuMDQuMjAvR0VESTAxX0JfMjAxOTExMDA5MjkzOV9PMDE5OTZfMDFfVDAzMzM0XzAyXzAwNV8wMV9WMDAyLmg1
Resolving urs.earthdata.nasa.gov (urs.earthdata.nasa.gov)... 2001:4d0:241a:4081::89, 198.118.243.33
Connecting to urs.earthdata.nasa.gov (urs.earthdata.nasa.gov)|2001:4d0:241a:4081::89|:443... failed: Bad file descriptor.
Connecting to urs.earthdata.nasa.gov (urs.earthdata.nasa.gov)|198.118.243.33|:443... connected.
Unable to establish SSL connection.
I'm installing OpenVPN Access Server on a Google Cloud instance. Its webUI listens on port 943 using https. It has a self-signed certificate whose name doesn't match the server's hostname (10.150.0.2). I can't start an SSH tunnel. I'm looking for a way to troubleshoot the connection from the IAP service to my server.
The command I'm running is gcloud compute start-iap-tunnel vpn 943 --local-host-port=localhost:943 I receive the normal Testing if tunnel connection works message.
It errs out with ERROR: (gcloud.compute.start-iap-tunnel) While checking if a connection can be made: Error while connecting [4003: 'failed to connect to backend']. (Failed to connect to port 943)
If I add --log-http to the command invocation the relevant information follows (it looks like a normal req/resp cycle with a 200 that I assume is from my client to the IAP service):
Testing if tunnel connection works.
=======================
==== request start ====
uri: https://oauth2.googleapis.com/token
method: POST
== headers start ==
b'content-type': b'application/x-www-form-urlencoded'
b'user-agent': b'google-cloud-sdk gcloud/367.0.0 command/gcloud.compute.start-iap-tunnel invocation-id/db27de82264f47fcb63f6680afaa8327 environment/None environment-version/None interactive/False from-script/False python/3.7.9 term/xterm-256color (Macintosh; Intel Mac OS X 21.2.0)'
== headers end ==
== body start ==
Body redacted: Contains oauth token. Set log_http_redact_token property to false to print the body of this request.
== body end ==
==== request end ====
---- response start ----
status: 200
-- headers start --
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Encoding: gzip
Content-Type: application/json; charset=utf-8
Date: Fri, 24 Dec 2021 02:11:52 GMT
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Pragma: no-cache
Server: scaffolding on HTTPServer2
Transfer-Encoding: chunked
Vary: Origin, X-Origin, Referer
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 0
-- headers end --
-- body start --
Body redacted: Contains oauth token. Set log_http_redact_token property to false to print the body of this response.
-- body end --
total round trip time (request+response): 0.246 secs
---- response end ----
----------------------
ERROR: (gcloud.compute.start-iap-tunnel) While checking if a connection can be made: Error while connecting [4003: 'failed to connect to backend']. (Failed to connect to port 943)
To my knowledge this is the limit of easily accessible troubleshooting for start-tap-tunnel.
Moving on to the local machine we can connect to 10.150.0.2:943 before puking a la certificate.
root#viongier:/usr/local/openvpn_as# wget https://10.150.0.2:943
--2021-12-24 02:01:47-- https://10.150.0.2:943/
Connecting to 10.150.0.2:943... connected.
ERROR: The certificate of ‘10.150.0.2’ is not trusted.
ERROR: The certificate of ‘10.150.0.2’ doesn't have a known issuer.
The certificate's owner does not match hostname ‘10.150.0.2’
It seems to me that my client happily connects to the IAP service which fails to connect to my server. I would expect to see an IAP error if it was erring out because of the cert. The only thing I can think of to test this is by generating a certificate whose issuer google likes. (LetsEncrypt for example.)
This message means that the backend does not have a socket open in the listening state. Common reasons are that no service has been started or a firewall is blocking the port.
To allow the Identity Aware Proxy into your VPC, allow traffic from 35.235.240.0/20.
ERROR: (gcloud.compute.start-iap-tunnel) While checking if a
connection can be made: Error while connecting [4003: 'failed to
connect to backend']. (Failed to connect to port 943)
This error means that the certificate provided does not match the address that the connection is made to:
ERROR: The certificate of ‘10.150.0.2’ is not trusted. ERROR: The
certificate of ‘10.150.0.2’ doesn't have a known issuer. The
certificate's owner does not match hostname ‘10.150.0.2’
Some clients, such as wget support ignoring SSL certificate validation. For wget see the --no-check-certificate flag.
Once you solve that problem you will run into another set of problems:
Under normal circumstances, you can not use HTTPS with tunnels. Tunnels are a form of man in the middle. There are tricks that can be employed, none of them secure.
Commercial SSL certificates do not support IP addresses only public domain names. You would need to create your own self-signed certificate, which would not be trusted or do not validate the certificate.
The last issue is that HTTPS endpoints require encryption negotiation from the client party. The start-iap-tunnel command does not initiate encryption (TLS negotiation). This command also does not do any form of certificate exchange and that is why you do not see an IAP error about certificates. This command only transfers data between the tunnel endpoints.
In summary, you cannot use HTTPS with TCP / SSH tunnels without deploying tricks and/or disabling features which defeats the purpose of HTTPS.
Allow IAP traffic through the firewall allowed my external client to connect to the internal port 943 via an IAP tunnel.
Allowing port 943 from 35.235.240.0/20 solved my problem.
More information is available at the GCP IAP docs
I'm trying to build OpenCog from here and when I issue this command
octool -rdcpav -l default
It builds everything but it then gets to the step of installing Link-Grammar and this happens
[octool] Installing Link-Grammar....
--2020-06-13 10:09:36-- http://www.abisource.com/downloads/link-grammar/current/
Resolving www.abisource.com (www.abisource.com)... 130.89.149.216
Connecting to www.abisource.com (www.abisource.com)|130.89.149.216|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://www.abisource.com/downloads/link-grammar/current/ [following]
--2020-06-13 10:09:37-- https://www.abisource.com/downloads/link-grammar/current/
Connecting to www.abisource.com (www.abisource.com)|130.89.149.216|:443... connected.
OpenSSL: error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
Unable to establish SSL connection.
I'm on ubuntu 20.04 LTS
www.abisource.com supports only TLS version 1.0, which is now broken (or at least weakened) and way obsolete. According to its headers it is Apache 2.2.15 (Fedora) which dates from 2010!
This therefore appears to be the same problem as OpenSSL v1.1.1 ssl_choose_client_version unsupported protocol except Ubuntu instead of Debian and wget (used by octool) instead of openvpn. Try the accepted anser there: edit /etc/ssl/openssl.cnf under [system_default_sect] to downgrade MinProtocol=TLSv1 and possibly CipherString=DEFAULT:#SECLEVEL=1 -- the server's DHE key is 1k, and I don't recall if that works at level 2, although its cert is absurdly RSA 4k!
UPDATE: Okay, I downloaded and installed Ubuntu 20.04 including source for libssl1.1 and looked at it, and they did NOT keep the Debian approach here, they changed it. Specifically, they didn't change the openssl.cnf file to require TLSv1.2, instead they compiled OpenSSL/libssl to make the default SECLEVEL 2 and to have SECLEVEL 2 force TLSv1.2 (which it doesn't upstream).
However, you can still fix it by adding the desired (weak) configuration to openssl.cnf:
somewhere in the default section, i.e. before the first line beginning with [, add a line
openssl_conf = openssl_configuration
I like putting it at the very top, but that's just me.
technically at any section boundary, but much-easiest at the end, add three new sections:
[openssl_configuration]
ssl_conf = ssl_configuration
[ssl_configuration]
system_default = tls_system_default
[tls_system_default]
CipherString = DEFAULT:#SECLEVEL=1
Note that since MinProtocol wasn't already there you don't need to add it (the code default is okay) but you can if you want.
Now it works:
$ wget https://www.abisource.com/
--2020-06-20 05:11:11-- https://www.abisource.com/
Resolving www.abisource.com (www.abisource.com)... 130.89.149.216
Connecting to www.abisource.com (www.abisource.com)|130.89.149.216|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7687 (7.5K) [text/html]
Saving to: ‘index.html’
index.html 100%[===================>] 7.51K --.-KB/s in 0.002s
2020-06-20 05:11:12 (3.90 MB/s) - ‘index.html’ saved [7687/7687]
This is, as you commented, a global change. You can change it for this specific operation by editting your copy of octool to add the option --ciphers=DEFAULT:#SECLEVEL=1 to the wget command(s). With the original openssl.cnf:
$ wget --ciphers=DEFAULT:#SECLEVEL=1 https://www.abisource.com/
--2020-06-20 05:15:21-- https://www.abisource.com/
Resolving www.abisource.com (www.abisource.com)... 130.89.149.216
Connecting to www.abisource.com (www.abisource.com)|130.89.149.216|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7687 (7.5K) [text/html]
Saving to: ‘index.html.1’
index.html.1 100%[===================>] 7.51K --.-KB/s in 0s
2020-06-20 05:15:22 (330 MB/s) - ‘index.html.1’ saved [7687/7687]
I can't currently use the PayPal Sandbox to test my shopping-cart integrations. When i access the sandbox in a browser or via curl, all i get is connection errors.
Here's an example curl-session:
curl -v "https://api-3t.sandbox.paypal.com/nvp?user=test"
* Trying 173.0.82.83...
* TCP_NODELAY set
* Connected to api-3t.sandbox.paypal.com (173.0.82.83) port 443 (#0)
* TLS 1.2 connection using TLS_RSA_WITH_AES_256_CBC_SHA256
* Server certificate: api-3t.sandbox.paypal.com
* Server certificate: Symantec Class 3 Secure Server CA - G4
* Server certificate: VeriSign Class 3 Public Primary Certification Authority - G5
> GET /nvp?user=test HTTP/1.1
> Host: api-3t.sandbox.paypal.com
> User-Agent: curl/7.51.0
> Accept: */*
>
* SSLRead() return error -9806
* Curl_http_done: called premature == 1
* Closing connection 0
curl: (56) SSLRead() return error -9806
Any hints if this is a serverside issue or something i can work around?
Thanks!
Looks like the NVP/SOAP integration method of Paypal Express Checkout is deprecated as of January 1, 2017. The live URL (https://api-3t.paypal.com/nvp) seems to work for now, but this might be why the sandbox doesn't work anymore.
I don't exactly understand why, but using POST instead of GET when submitting data to the PayPal Sandbox solves the problem nicely. No more weird SSL-errors.
Found below answer to curl 56 error . Hope that could help work out of the problem.
curl (56) Recv failure
PHP CURL Error - curl: (56) Recv failure: Connection reset by peer
I'm hosting a Ghost blog using Digital Ocean. My droplet is Ubuntu Ghost 0.8.0 on 14.04.
Yesterday I successfully installed a TLS/SSL certificate from LetsEncrypt in order to enable HTTPS. The site was working fine then and this morning.
Today I uploaded a new Ghost theme and restarted Ghost in order to access it. I now get the response 502 Bad Gateway when I try to access the site.
Each request for the site adds an instance of the following errors to mynginx error log.
Would someone walk me through what these 2 error messages mean? I'd really appreciate it.
Please note that I've substituted my actual domain name with example.com
2016/06/16 17:28:45 [error] 8125#0: *13 connect() failed (111: Connection refused) while connecting to upstream, client: 98.247.253.8, server: example.com, request: "GET /favicon.ico HTTP/1.1", upstream: "http://127.0.0.1:2368/favicon.ico", host: “example.com”, referrer: "https://example.com/“
2016/06/16 17:30:14 [error] 8125#0: *18 connect() failed (111: Connection refused) while connecting to upstream, client: 98.247.253.8, server: example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:2368/", host: “example.com”