10

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?

Feanaro
  • 922
  • 3
  • 19
  • 35
  • 1
    Possibly related: [An application may receive the "10054" error when the application receives data from a connection on a computer that is running Windows 7 or Windows Server 2008 R2 if a TDI filter driver is installed](https://support.microsoft.com/kb/981344). – jww Aug 25 '14 at 12:36
  • We are running windows server 2012 R2. The hotfix doesn't apply to our version of windows server. But thanks for the suggestion. And the computer running the openssl client is a windows 8.1 pro computer running the x64 version of openssl. – Feanaro Aug 25 '14 at 13:20
  • I tried adding a new entry for port 443 on our firewall. It didn't change anything. I also tried to connect to another https endpoint on port 8080 that didn't work either. Interestingly when I tried connecting to one of our other servers it worked as it should. – Feanaro Aug 25 '14 at 16:13

2 Answers2

18

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.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
11

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.

jww
  • 97,681
  • 90
  • 411
  • 885
Feanaro
  • 922
  • 3
  • 19
  • 35