I've been using wget to pull some .rnx files from the CDDIS NASA archives. This has been working no problem for ~200 iterations until now. Not sure what happened.
I'm receiving an SSL connection error that occurs on other files in the CDDIS website. when I try the same command for, say, www.google.com, the index file is downloaded fine to the given output directory.
I have found this solution thread for linux which seems like my issue:
Unable to establish SSL connection upon wget on Ubuntu 14.04 LTS
or
Unable to establish SSL connection, how do I fix my SSL cert?
I am on Windows 11. To be completely honest despite some googling and toying around with the ports (302/443) based on that thread, it's all a bit opaque on how I can fix this issue myself. Would really appreciate a bit more of a breakdown on how I might approach this problem.
>wget -P C:\Users\name\Desktop\brdc http://cddis.nasa.gov/archive/gnss/data/daily/2021/001/21p/BRDC00IGS_R_20210010000_01D_MN.rnx.gz
--2022-05-01 17:47:05-- http://cddis.nasa.gov/archive/gnss/data/daily/2021/001/21p/BRDC00IGS_R_20210010000_01D_MN.rnx.gz
Resolving cddis.nasa.gov (cddis.nasa.gov)... 198.118.199.52
Connecting to cddis.nasa.gov (cddis.nasa.gov)|198.118.199.52|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://cddis.nasa.gov/archive/gnss/data/daily/2021/001/21p/BRDC00IGS_R_20210010000_01D_MN.rnx.gz [following]
--2022-05-01 17:47:05-- https://cddis.nasa.gov/archive/gnss/data/daily/2021/001/21p/BRDC00IGS_R_20210010000_01D_MN.rnx.gz
Connecting to cddis.nasa.gov (cddis.nasa.gov)|198.118.199.52|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://urs.earthdata.nasa.gov/oauth/authorize?client_id=gDQnv1IO0j9O2xXdwS8KMQ&response_type=code&redirect_uri=https%3A%2F%2Fcddis.nasa.gov%2Fproxyauth&state=aHR0cDovL2NkZGlzLm5hc2EuZ292L2FyY2hpdmUvZ25zcy9kYXRhL2RhaWx5LzIwMjEvMDAxLzIxcC9CUkRDMDBJR1NfUl8yMDIxMDAxMDAwMF8wMURfTU4ucm54Lmd6 [following]
--2022-05-01 17:47:05-- https://urs.earthdata.nasa.gov/oauth/authorize?client_id=gDQnv1IO0j9O2xXdwS8KMQ&response_type=code&redirect_uri=https%3A%2F%2Fcddis.nasa.gov%2Fproxyauth&state=aHR0cDovL2NkZGlzLm5hc2EuZ292L2FyY2hpdmUvZ25zcy9kYXRhL2RhaWx5LzIwMjEvMDAxLzIxcC9CUkRDMDBJR1NfUl8yMDIxMDAxMDAwMF8wMURfTU4ucm54Lmd6
Resolving urs.earthdata.nasa.gov (urs.earthdata.nasa.gov)... 198.118.243.33
Connecting to urs.earthdata.nasa.gov (urs.earthdata.nasa.gov)|198.118.243.33|:443... connected.
Unable to establish SSL connection.
Related
I tried to duplicate my .NET Core Linux environment from this question to have 2 environments, and the logs say
Now listening on: http://[::]:5000
which makes me think it is working, but the requests get this error:
(111: Connection refused) while connecting to upstream, client:
172.31.44.219, server: , request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:5000/", host: "172.31.47.124"
And it times out. I believe everything is the same, while the initial environment is working perfectly fine. I created this one without "configuring more options" so it is not part of a VPC etc but neither is my initial environment. What should I be checking? I have viewed some answers on here for this issue but no fixes worked. For example, I commented out app.UseHttpsRedirection(); but still have the issue.
Okay, so I have noticed that EB creates and attaches a security group, and it listens on port 80, not 5000. I am leaving this here as it might be helpful for someone else (aka my future self).
I am new to HTTPs. In our application to integrate with another system we were given HTTPs URLs along with their certificates. Our team added those certificates in the test store. Now when we are sending request on those URLs, we are getting “Unsupported or unrecognized SSL message”.
And if I do curl -v on that URL, I get error:1408F10B:SSL routines:ssl3_get_record:wrong version number.
Is it problem on our side or this need to be fixed by other systems who shared those URLs with us.
Both of these errors are due to the same reason?
It is very likely that the server does not speak TLS at all.
The client will start with the TLS handshake and the server will reply to this with some non-TLS response. The client expect the server to do its part of the TLS handshake though. Thus it will try to interpret the servers as response as TLS. This will lead to strange error messages depending on the TLS stack used by the client.
With OpenSSL based stacks it will often result in wrong version number, since the trying to extract the TLS version number for the expected TLS record and get some unexpected results since the server did not actually send a TLS record.
Is it problem on our side or this need to be fixed by other systems who shared those URLs with us.
If this is exact the URL you are supposed to use (i.e. no simply changing of http:// to https:// on your site) then it is likely a server side problem. But it might also be a problem of some middlebox or software in the network path to the server, like some antivirus, firewall or captive portal hijacking your data and denying access to the remote system with an error message.
In my case, I had on apache2 another badly configured virtual host. On the other wrong virtual host there was a http virtual server on port 443!!!
The second virtual host was correct but apache cannot use different protocols on the same port for different virtual hosts.
After removing the http on port 443 configuration all other https hosts worked and error
error:1408F10B:SSL routines:ssl3_get_record:wrong version number"
disapeared
I’ve used docker some in the past , I’m trying to introduce it at a new environment, but cannot get docker pull working. Keeps failing with 503 response.
What I could use help with is finding the underlying cause of this issue, so I can have the net/it admins fix whatever it is, be it firewall, ssl, proxy authentication, (all the usual suspects running docker/windows in a corporate network, ya know.)
Where can I look to see the root cause of pull failures to help them out? Also any specific diagnostic tests I could run to help figure this out would help.
I am able to hit registry-1.docker.io in general:
e.g.
curl https://registry-1.docker.io/v2/
{“errors”:[{“code”:“UNAUTHORIZED”,“message”:“authentication required”,“detail”:null}]}
I’ve poked through the logs in %localappdata%/docker, but have not been able to find anything.
the only thing I found at all was in dockerd.log:
2021-08-19T13:59:06Z dockerd time=“2021-08-19T13:59:06.656666400Z” level=debug msg="pulling blob “sha256:9da81141e74e38839836e81c2691d3c7ac54bf34272e5d4a636fc032150506a4"”
2021-08-19T13:59:06Z dockerd time=“2021-08-19T13:59:06.994330700Z” level=info msg=“Download failed, retrying (1/5): received unexpected HTTP status: 503 Service Unavailable”
Which does not really help. I know docker registry is not down, so this is not really a 503 from docker.
System info
OS: Windows 10 19043, WSL2 enabled (VM with virtualization enabled, if that matters)
Docker version 20.10.7, build f0df350
repro steps:
docker run -d -p 80:80 docker/getting-started
Unable to find image ‘docker/getting-started:latest’ locally
latest: Pulling from docker/getting-started
540db60ca938: Retrying in X seconds (repeats countdown a few times with increasing wait times )
0ae30075c5da: Retrying in X seconds
9da81141e74e: Retrying in X seconds
b2e41dd2ded0: Waiting
7f40e809fb2d: Waiting
758848c48411: Waiting
23ded5c3e3fe: Waiting
38a847d4d941: Waiting
docker: received unexpected HTTP status: 503 Service Unavailable. (finally)
See ‘docker run --help’.
Thanks.
JS
Answering my own question: I ran docker through fiddler, by setting the docker proxy to localhost:8888. Inspecting the body of the 503 response in fiddler, I was able to see the cause: The corporate firewall rules were blocking executable file transfers.
I have a wordpress site.Everything was running fine but after I activated SSL sertificate and Cloudflare things got messed up.
I am trying to send emails via mailgun smtp. but I got this error.
smtp error
I googled for this one and I tried to change from google DNS to openDNS but no success
Also when I want to install a plugin these errors shows up
install error
However I can upload plugins manually so it should not be a permission issue.
I am running Nginx and here are my iptables
iptables
And to check ports Listening
Listen
Since this is curl error I tried to run:
curl -v https://mydomain.info
In a perfect world it should return html but I got this instead:
curl: (6) Could not resolve host: mydomain.info
If anyone has any idea where to look for answers I would really appreciate that.
wget fails to download through a proxy server with the following message: Invalid request -- HOST header was not sentUnable to establish SSL connection.
Example:
[root#foosrv0234ccpra ~]# wget https://packages.chef.io/stable/el/6/chefdk-0.18.26-1.el6.x86_64.rpm
--2016-09-27 16:57:44-- https://packages.chef.io/stable/el/6/chefdk-0.18.26-1.el6.x86_64.rpm
Resolving deehprx024ccpxa.ehn.sr.dev.sdc.mycomp.com (deehprx024ccpxa.ehn.sr.dev.sdc.mycomp.com)... 129.35.62.40
Connecting to deehprx024ccpxa.ehn.sr.dev.sdc.mycomp.com (deehprx024ccpxa.ehn.sr.dev.sdc.mycomp.com)|129.35.62.40|:8080... connected.
Proxy tunneling failed: Invalid request -- HOST header was not sentUnable to establish SSL connection.
[root#foosrv0234ccpra ~]# env|grep proxy
http_proxy=http://barsrvprx024ccpxa.ehn.sr.dev.sdc.mycomp.com:8080
https_proxy=http://barsrvprx024ccpxa.ehn.sr.dev.sdc.mycomp.com:8080
no_proxy=barsrvacp014ccpra,barsrvchf014ccpra.ssm.sdc.gts.mycomp.com,localhost,127.0.0.1,barsrvacp014ccpra.ssm.sdc.gts.mycomp.com
It took me a while to get through this, so I'm sharing the issue on StackOverflow. Please have a look at the answer below.
The problem above happens because HTTP 1.1 requires the client to provide a HOST header and the proxy server does not support HTTP 1.1 (refer to RFC 2616 for more details on this requirement).
Some alternatives:
Upgrade your proxy to support HTTP 1.1
Downgrade wget to a version that only supports HTTP 1.0 (wget v1.12 or below)
Find another way to force all HTTP calls to be made using 1.0 and not 1.1 (I haven't explore this possibility and I'm not sure how to do it... downgrading wget solved my issue)