OpenSSL errno 10054,connection refused, whilst trying to connect to our server

Question

We are running a git server over https and didn't have any trouble connecting because we all used visual studio to do so. Now someone wants to use the standard git bash and it fails to connect with the following error output.

fatal: unable to access 'https://server/Repo.git/': Unknown SSL protocol error in connection to server:443

I tried some different ciphersuites, nothing worked. Then it came to me that it might be that git doesn't support ECDSA certificates yet. So I exchanged the ECDSA certificate for one with RSA. That also didn't work.

Then I tried connecting with OpenSSL s_client with the following command:

OpenSSL> s_client -connect server:443

This is the output from running the command:

CONNECTED(0000018C)
write:errno=10054
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 307 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

I searched google for the error number 10054 and found it means connection refused. We use IIS 8.5 to supply the https endpoint for the git server. I can connect to the web environment through all webbrowsers and we can use the git server through the visual studio git interface. So I don't think it's a firewall issue. I'd like to know if anyone has experienced this problem before and if they could help us out here?

Answer 1

10054 is not connection refused, but connection reset by peer. This means, that a TCP connection was successfully established (s_client indicates CONNECTED) but when sending more data from the client to the server the server closed the connection without reading all the data (and send TCP RST back).

While this could be a firewall issue it could also indicate a problem at the server configuration, that is the server accepts the client but then cannot continue because of an invalid configuration. Such invalid configurations might be a missing permissions for the requested data, certificate without usable private key or others. I would suggest that you have a look at the server logs for more information.

I've also seen TCP RST with servers, load balancers or firewalls which do not understand current TLS versions and simply close the connection. Browsers work around this issue by transparently retrying with a lower TLS version. You might try if openssl s_client -ssl3 works against this server and you receive a certificate.

Answer 2

Verify that you are using TLS 1.0 or above. Some servers require TLS 1.2. If you are not sure that your server supports up to TLS 1.2 look at Steffen Ulrich's answer above and try that first.

If that does not help, then check if SNI is required for the endpoint. If that is the case this might be the problem. If you call the s_client command with the servername parameter set to the servername which you'd like to contact that should work.

Example basic command:

s_client -connect example.com:443 -tls1 -servername example.com

You can find the options for s_client at s_client man page.