Receiving "SSL_connect returned=1 errno=0 state=SSLv3 read server hello A: sslv3 alert handshake failure" with openshift nodejs app - node.js

I have a nodejs app on openshift, and we use the rhc port-forward command to connect to our database when we develop locally.
We have implemented passport to authenticate users through google and through facebook. I have authenticated my self, and we could still use the rhc commands. My partner has recently authenticated himself through facebook, and shortly after that (~1 week), we got this error thrown our way. Dont know if that is entirely relevant, but it couldn't hurt to include.
Connection to openshift.redhat.com failed: A secure connection could not be established to the server
(SSL_connect returned=1 errno=0 state=SSLv3 read server hello A: sslv3 alert handshake failure). You may
disable secure connections to your server with the -k (or --insecure) option
'https://openshift.redhat.com/broker/rest/api'.
If your server is using a self-signed certificate, you may disable certificate checks with the -k (or
--insecure) option. Using this option means that your data is potentially visible to third parties.
Any ideas on how to resolve this? I have seen this error on other stack questions, but every question I saw, the people posing the question were using ruby.


This is likely a result of the POODLE SSLv3 debacle. You can fix it by updating the httpclient ruby gem. At the command line type:
sudo gem update httpclient
Or you can also fix it by adding the following to your .openshift/express.conf file:
ssl_version=tlsv1
Both of these fixes essentially tell your app to use TLSv1 instead of SSLv3.


The rhc gem has been updated, please run gem update rhc and you will get the newest fixed version.


I had the same issue on Windows with ruby 1.9.3 and httpclient 2.3.4.1
gem update httpclient updated the same to 2.5.3.3 and thus fixed the issue.

Related

unexpected eof when using openssl

I am unable to get a basic react app to work using a self signed certificate on a local development server (Linux Mint 21, Linux 5.15.0-46-generic).
I installed node version 18.10. This has npm/npx v 8.19.2
I created a basic react app using
npx create-react-app myapp
I generated certificate and key using openssl. The certificate has been generated with the CN=sandbox.local, so that I'm not using an IP address.
I then start the app, using
HTTPS=true \
HOST=sandbox.local BROWSER=none \
SSL_CRT_FILE=certification/sandbox.local.pem \
SSL_KEY_FILE=certification/sandbox.local.pem \
npm start
This successfully starts the application, informing me that I can browse the application on https://localhost:3000 (or via the IP address on the network).
Attempting to browse from my local machine (also running Linux Mint 21), in firefox I get:
Secure Connection Failed
An error occurred during a connection to sandbox.local:3000. PR_END_OF_FILE_ERROR
In Chromium:
This page isn’t working
sandbox.local didn’t send any data.
ERR_EMPTY_RESPONSE
And using curl,
curl: (35) error:0A000126:SSL routines::unexpected eof while reading
There's a plethora of pages out there telling me that this is something to do with openssl version 3 expecting a response and not getting one. There's nothing that I've been able to find that tells me how to fix that in the context of a react application.
On the same machine I have a dash/plotly application, running with self signed certificates that were generated in exactly the same way. That application is accessible and works, which leads me to wonder if there it's something in the react/node interaction with openssl. I can resolve sandbox.local both with http and https for other types of applications.
The created app is literally the output of create-react-app. If I install and run it on the same machine, it works fine.
Is there some configuration option I'm missing? I haven't been able to generate an error log file from node, so apart from the SSL error from curl, I'm flying blind. Will update if/when I figure out how to log errors.

Getting The SSL connection could not be established error while installing Build Agent on Azure Server

I am trying to install a self-hosted build agent on my azure server and I am unable to install it due to below error,
However, I am able to install it on my other server without any error. I am not sure what am I missing on the server where I am getting the above error.
I had tried using the --sslskipcertvalidation as well but no success. I also created a self signed SSL cert as well by referring the below URL but still the issue exist.
https://thycotic.force.com/support/s/article/Installing-a-Self-Signed-SSL-HTTPS-Certificate

Renewed my SSL certificate but getting UNABLE_TO_VERIFY_LEAF_SIGNATURE in nodejs on AWS EC2 server

I have a nodejs/express api on a AWS EC2 server with a ssl certificate that is generated with Let's encrypt every 3 months.
Auto renewal isn't on and we let it exipre before trying to renew but after renewing it we are getting an error saying:
Unable to verify the first certificate
or
UNABLE_TO_VERIFY_LEAF_SIGNATURE
depending on what we are testing with.
We are using Certbot for renewing with the following command (and not $ certbot renew) :
$ sudo certbot certonly --dns-route53 -d *.example.com -d example.com --server https://acme-v02.api.letsencrypt.org/directory
Certificates are generated as expected with an expiration date 3 months from now.
Any ideas on what's going on ? I've tried most of the things I could find on SO and elsewhere but nothing worked.
P.S. Servers and I don't go along very well :/ (I do mobile app dev) so assume that I don't know anything when replying :D

Solution was quite easy, just needed to use the fullchain.pem file (and reboot your server if applicable).
Sidenote:
If someone on your team tells you that they've tested a solution and that it didn't work, don't just blindly trust them but test it yourself if all other possible solutions didn't work...(have lost 1+ day because someone thought they did test with the fullchain.pem (or did it wrongly)

why am I receiving error starting microclimate on macos stating TLS handshake timeout

I've successfully completed the ./install.sh command. When I run the next "~/mcdev start -o" I receive this error: "Starting Microclimate
Pulling microclimate-file-watcher (ibmcom/microclimate-file-watcher:1809)...
ERROR: Get https://registry-1.docker.io/v2/ibmcom/microclimate-file-watcher/manifests/1809: net/http: TLS handshake timeout
Error starting Microclimate"
I have running on my pc:
git version 2.17.1 (Apple Git-112); Docker version 18.06.1-ce; MacOS
High Sierra v 10.13.6; latest Microclimate v18.09
My network is up and I don't have any proxy.
What am I missing or doing wrong?

I got this to work by changing to a different wifi \ internet connection. Still not sure why my home wifi, with no restrictions that I'm aware of, will 'block' the dependency downloads upon start of Microclimate.
If anybody has additional info to help find the root cause please feel free to share.

This docker error generally shows up when your internet connection is too slow for Docker, as it times out performing the TLS handshake. This would also explain why moving to another network fixes the issue.

SSL negotiation failed with svn

I am running a server that accepts https requests. I have generated my own certificate. When going to the site in firefox I get the unknown certificate error, but that's fine. This (I think) indicates that port forwarding and such works.
I am trying to use svn with this. When using svn on the server (but using the external ip) it works. Again I get the certificate is unknown, but I don't care.
When using svn on mac OS X I get
SSL negotiation failed: SSL error code -1/1/336032856
I've found several posts on google about this, but they all say it's a bug with openssl version 0.9.8, and that using something higher should fix it.
I am currently using openssl 1.0.0c. I have no idea what's going wrong. I also checked the error log in httpd and nothing comes up.
Any ideas on this would really help.
Thanks

Upgrading from SVN 1.6.15 to 1.6.16 fix this issue for me.

I received the same error message when my Apache configuration was wrong - my ServerName parameter in httpd.conf did not match hostname in the self-signed certificate.

I started getting this error from older subversion clients (Tortoise 1.6.4 i think, and pysvn r1280) when our svn server had its Apache instance upgraded. It went from using OpenSSL 0.9.8n to 1.0.0d.
Tortoise got fixed by upgrading to 1.6.16 (uses OpenSSL 1.0.0d).
Fixing pysvn was a different story. The latest version (r1360) came bac kwith the same error. There didn't seem to be much info around apart from hints that OpenSLL might need upgrading. I tried copying in different versions of OpenSSL (libeay32.dll and ssleay32.dll) and here are the results:
0.9.8j (the existing DLL version, bundled with pysvn r1280) FAIL
0.9.8o (bundled with the latest pysvn, r1360) FAIL
0.9.8r (the latest in the 0.9.8 series) FAIL
1.0.0* (the 1.0 series is not binary compatible with pysvn) FAIL
0.9.8L (nabbed from CollabNet SVN 1.6.9 command line client) SUCCESS!
So whatever they fixed in release L got broken again soon after, or there's something special about CollabNet's OpenSSL binaries.

In my case it started happening after some certificates changes on the server side. I tried deleting the .subversion/ dir, updating openssl, openssh, svn, and nothing...
It got finally fixed when I replaced the url host name with the ip address of that host.
In existing working copies was enough with:
svn switch --relocate http://hostname.com https://ipaddress
Not sure if this is a bug or what, but it seems that the new certificates are not recognized and keeps using the old cached ones for a given host name.

I agree with the earlier answer by Lukas Cenovsky, that setting ServerName in the apache configuration fixes the problem.
In this link http://www.elegosoft.com/files/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf it is said that the error originates from the SSL library.
The full error message(just to enable better google indexing) I receive is:
$ svn ls https://www.OMITTED.dk/svn
svn: E175002: Unable to connect to a repository at URL 'https://www.OMITTED.dk/svn'
svn: E175002: OPTIONS of 'https://www.OMITTED.dk/svn': SSL handshake failed: SSL error code -1/1/336032856 (https://www.OMITTED.dk)
In the file /etc/apache2/sites-available/ssl (debian linux)
I added the ServerName as:
NameVirtualHost *:443
<VirtualHost *:443>
ServerAdmin webmaster#localhost
SSLEngine On
ServerName www.OMITTED.dk

See what happens if you eliminate the SSL problem by adding your generated certificate to your client's trusted certificate store.

One step ahead, my case is a MSWindows Client workstation and a CentOs server with Apache.
Using Tortoise Subversion 1.6.16, I realise that after execute a "svn checkout https://OMITTED.dk/project", I got the same ssl handshake error.
What I did was
update c:\windows\system32\drivers\etc\hosts with "IP_address
OMITTED.dk"
update the entries with the project directory. Edit the
file project/entries and replace the IP_address by OMITTED.dk.
Thus I try the command : svn update path_to_project --non-interactive --trust-server-cert.
Hope will be usefull

Resources