SSL Handshake failure


We are still getting the same error below when renewing the certificate. And error “curl: (35) TCP connection reset by peer” as well. Thanks for any help.

File "/opt/", line 646, in send
    r = adapter.send(request, **kwargs)
  File "/opt/", line 514, in send
    raise SSLError(e, request=request)
SSLError: HTTPSConnectionPool(host='', port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLError("bad handshake: SysCallError(104, 'ECONNRESET')",),))

Hi @linuxworld,

Does the error happen every time you try to get a certificate? I suspect this may be a different problem than what was reported above.

Could you provide the following info?:
OS version: (e.g. ubuntu 16.04, centos 7)
Certbot version: (e.g. output of certbot --version or certbot-auto --version)

Output from the following commands on the OS you are trying to obtain a certificate:
curl -vvv
mtr -c 20 -w -r

Thank you @andygabby !
Yes this should be a different problem. The renewal has been working well except this time. It seems to be SSL handshake failure.
# openssl s_client -connect -tls1_2

no peer certificate available

No client certificate CA names sent

SSL handshake has read 0 bytes and written 0 bytes

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE

OS is CentOS 7.6. Certbot version 0.39.0. Network connectivity is good, while getting curl error. Also tried the curl command from other server, result is good.
#curl -vvv
* About to connect() to port 443 (#0)
* Trying…
* Connected to ( port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TCP connection reset by peer
* Closing connection 0
curl: (35) TCP connection reset by peer

Much appreciated if you could give any help.

:wave: I moved your post and replies to a new thread so we can keep things one-distinct-problem-per-thread as much as possible. Thanks!


It looks like there might be a firewall between you and our edge nodes blocking the connection. While I can’t yet rule out that it isn’t our CDN edge nodes, I suspect it is either on your host or a firewall device on your end.

I am not sure how comfortable you are with using tcpdump/Wireshark, but one way to tell if it was a firewall is to run a tcpdump during your openssl s_client command and capture the output then analyze the pcap with Wireshark. If you see that you get a tcp reset (RST) during the process then you may be able to track down what device sent it and perhaps a firewall rule that is not allowing the connection to proceed.

Here is a tcpdump command you could use:
sudo tcpdump -i $eth_interface -s0 -w $output_filename.pcap
Example: sudo tcpdump -i eno12121212 -s0 -w troubleshooting.pcap
The resulting troubleshooting.pcap file would be what you could then analyze with Wireshark.


The tcpdump revealed that the TCP reset is from
This IP address resolves to hostname
It does not look like a device either of us control.

Any suggestion on how to proceed next ?


Thank you for the tests and information!

In my testing, the TCP reset that causes this sort of issue will still appear to come from the destination IP that you are trying to reach but the mac address can be a tell that it was really a firewall or other device than the actual destination that sent it. I saw similar behavior when testing on my firewall with traffic blocked.

I still suspect there is something before you get to our API CDN (the Cloudflare ip) that is blocking your connection. It could be software on your local host (bugs that may be fixed in newer software packages, host based firewalls) or a firewall rule on your local network.

I can confirm that this is not coming from the local host itself neither within our network. I can see the TCP RST coming back from the internet.

On our network, we have 2 paths to the internet. We now know that this issue comes from one side only. By forcing the renewal to use a given ISP, everything works fine.

We can live with this situation for now. I will inquire to our second ISP if they can provide any assistance with the source of this TCP RST.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.