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
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.
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.