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/eff.org/certbot/venv/lib/python2.7/site-packages/requests/sessions.py", line 646, in send
r = adapter.send(request, **kwargs)
File "/opt/eff.org/certbot/venv/lib/python2.7/site-packages/requests/adapters.py", line 514, in send
raise SSLError(e, request=request)
SSLError: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLError("bad handshake: SysCallError(104, 'ECONNRESET')",),))
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)
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 acme-v02.api.letsencrypt.org:443 -tls1_2
CONNECTED(00000003)
write:errno=104
—
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 https://acme-v02.api.letsencrypt.org/directory
* About to connect() to acme-v02.api.letsencrypt.org port 443 (#0)
* Trying 172.65.32.248…
* Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* NSS error -5961 (PR_CONNECT_RESET_ERROR)
* TCP connection reset by peer
* Closing connection 0
curl: (35) TCP connection reset by peer
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 172.65.32.248
This IP address resolves to hostname ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
It does not look like a device either of us control.
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.
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!