I am trying to download a serious of scripts ... unfortunately it doesn't work.
shell:
$ wget --secure-protocol=TLSv1 --user=username --password=password --no-check-certificate https://www.example.com/bla/foo/bar/secure/1.pdf
respond:
--2014-10-06 12:49:26-- https://www.example.com/bla/foo/bar/secure/1.pdf
Resolving www.example.com (www.example.com)... xxx.xxx.xx.xx
Connecting to www.example.com (www.example.com)| xxx.xxx.xx.xx|:443... connected.
OpenSSL: error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error
Unable to establish SSL connection.
There can be lots of reasons why this fails with this error, among them:
server is unable to cope with newer TLS versions
server requires client authentication
server has a misbehaving SSL load balancer in front
there is a firewall between you and the server rejecting your traffic after initial inspection
That's all which can be said from the information you provide.
You might check the server against sslabs to get more information or provide more details in your question, like the real URL.
Edit: The requested server is www2.cs.fau.de. This server supports only SSLv3 and croaks on TLSv1 (instead of just responding with SSLv3), so you need to enforce SSLv3 with wget:
wget --secure-protocol=SSLv3 ...
The certificate of the server can be verified against the usual trusted CA on Linux, so you probably don't need the --no-check-certificate option.
Most browsers can access this site because they automatically downgrade to older SSL versions if connects with more modern versions does not succeed, but tools like curl or wget do not retry with downgraded versions.
Related
I am trying to install the datadog agent on Azure databricks using the steps mentioned in https://docs.datadoghq.com/integrations/databricks/?tab=allnodes
But while executing the init script, it fails with this error : "curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to s3.amazonaws.com:443".
Tried installing the agent with python package 'datadog', still the issue persists relevant to SSL.
Please let know if there is a fix for this?
Regards.
This error message indicates that there was a system call error during an SSL connection to the Amazon S3 endpoint (s3.amazonaws.com:443). Here are a few possible solutions that might help resolve this issue:
Check your internet connection: Ensure that your machine has a stable internet connection and that it is not being blocked by a firewall or proxy.
Update OpenSSL: Make sure that you have the latest version of OpenSSL installed on your machine. Updating OpenSSL can sometimes resolve SSL-related errors.
Check your network settings: If you are behind a firewall or proxy, ensure that the firewall or proxy is not blocking access to the Amazon S3 endpoint (s3.amazonaws.com:443).
Verify the endpoint: Double-check the endpoint URL to ensure that it is correct and that you are using the correct protocol (https).
If the above steps do not resolve the issue, you may need to contact Datadog support for further assistance.
my company has a web project, named projectA, is deployed in a cloud server(similar as AWS).
projectA is in tomcat.
we have ssl certificate, e.g. mycompany.com, users are able to access projectA by typing https://mycompany.com/projectA which will be redirected to https://mycompany.com/projectA/loginPage.action page if user has not login(only type https://mycompany.com will show 404 page), the browsers shows this website is secured.
however, either curl -w "TCP handshake:%{time_connect}, SSL handshake: %{time_appconnect}\n" -so /dev/null https://mycompany.com or curl -w "TCP handshake:%{time_connect}, SSL handshake: %{time_appconnect}\n" -so /dev/null https://mycompany.com/projectA, or curl -w "TCP handshake:%{time_connect}, SSL handshake: %{time_appconnect}\n" -so /dev/null https://mycompany.com/projectA/loginPage.action their time_appconnect are zero, why? time_connect has value.
i run curl in a cloud server whose CentOS is 7.9.2009(Core), Linux version 3.10.0, curl version is 7.29.0
missing intermediate certificate causes this problem, although we can use this webapp projectA normally in browser.
after concat server certificate and intermediate certificate to produce .keystore, this problem solved. With the help of ssl checker, we can found that the ssl deployment is correct or not.
How do I download a proxy's SSL cert and save it to a file using the Linux command line.
It's possible to download an ssl cert via the openssl tool: https://superuser.com/questions/97201/how-to-save-a-remote-server-ssl-certificate-locally-as-a-file. But this does not work when behind a corporate proxy that re-writes the SSL cert. I would like to download the proxy's ssl cert. Changing the HOST and PORT to my proxy's host and port does not work either.
Downloading the cert using my browser works but I need to do this in a bash script.
You can only extract certificates from the connection which actually get send inside the connection. Within a MITM proxy the root CA you want to have usually does not get send since it is expected to be installed locally as trusted, similar to a public root CA. And the reason you can extract this MITM CA within your browser is because the browser already has this CA as trusted in the CA store and can thus export it.
As mentioned here, openssl 1.1.0 and above support the -proxy argument so you can get the proxy's certificates with a command like (jcenter.bintray.com is just an example host to connect to)
openssl s_client -showcerts -proxy $https_proxy -connect jcenter.bintray.com:443
Also see this script for a more complete example how to import the certificate(s) to a JVM keystore and the system certificates.
I have an API running with express using https. For testing, I've been using tinycert.org for the certificates, which work fine on my machine.
I'm using docker to package up the app, and docker-machine with docker-compose to run it on a digital ocean server.
When I try to connect with Chrome, I get ERR_SSL_VERSION_OR_CIPHER_MISMATCH. When running this with curl, I get a handshake failure: curl: (35) SSL peer handshake failed, the server most likely requires a client certificate to connect.
I tried to debug with Wireshark's SSL dissector, but it hasn't given me much more info: I can see the "Client Hello" and then the next frame is "Handshake Failure (40)".
I considered that maybe node on the docker container has no available ciphers, but it has a huge list, so it can't be that. I'm unsure as to what's going on and how to remedy it.
EDIT
Here's my createServer() block:
let app = express();
let httpsOpts = {
key: fs.readFileSync("./secure/key.pem"),
cert: fs.readFileSync("./secure/cert.pem")
};
let port = 8080;
https.createServer(httpsOpts, app).listen(port);
I've had this problem for a really long time too, there's a weird fix:
Don't convert your certs to .pem; it works fine as .crt and .key files.
Add ca: fs.readFileSync("path to CA bundle file") to the https options.
It looks like your server is only sending the top certificate and the CA bundle file has the intermediate and root certificates which you'll need for non-browser use.
IMPORTANT! Reinstall or update node to the latest version.
You can use sudo apt-get upgrade if you're on Linux (it may take a while).
Re-download your certificate or get a new one.
If you are acting as your own certificate authority it could be not recognizing / trusting the certificate, so try testing your site on ssllabs.com.
If you're using the http2 API try adding allowHTTP1: true to the options.
I have a RHEL5 server in a private zone. I've set up a transparent proxy for ports 80 and 443. When I try a wget on 443, I get the following:
# wget -O- https://www.google.com
--2013-02-14 15:16:50-- https://www.google.com/
Resolving www.google.com... 74.125.129.147, 74.125.129.104, 74.125.129.106, ...
Connecting to www.google.com|74.125.129.147|:443... connected.
OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Unable to establish SSL connection.
I assume the proxy works because it's connecting. I don't know what else could be causing this.
This OpenSSL error indicates that wget sent the initial SSL ClientHello message, but gets an unexpected response from the server (or proxy) which was not an SSL ServerHello message.
This can be because the proxy speaks plain HTTP with the client, instead of HTTPS, because of a configuration error (e.g. with squid if port 443 is redirected to a http_port instead of https_port with the transparent option), or because it does not support transparent proxying of SSL at all. To debug, you may try connecting to http://www.google.com:443/ to see what happens. To know what's going on, you might want to run tcpdump while connecting to see what the server responds with. Also check the error log of your transparent proxy.
Without the transparent proxy configuration it is hard to tell what the problem is.