Can't connect to Let's Encrypt server

curl --version

curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.34 zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets

Outdated and full with security holes:

curl version 7.29.0 was released on February 6 2013 . The following 46 security problems are known to exist in this version.

I updated curl to version 7.62, and updated it’s dependancies as well. The problem went away from another similar server of ours, but it still persists on the original server.

Never mind, the problem came back to the other server.

Error code 35 says:


A problem occurred somewhere in the SSL/TLS handshake. You really want the error buffer and read the message there as it pinpoints the problem slightly more. Could be certificates (file formats, paths, permissions), passwords, and others.

So try a manual use of curl with the -v option. Looks like your server has a deprecated configuration.


Have you tried to update all server softwares from your system repo?

Also, please try to use curl -vvvv -I -L and share us the full outputs in an online text bin service link (such as

Thank you

Yes, we have updated everything.

curl -vvvv -I -L

  • Trying…
  • Connected to ( port 443 (#0)
  • Initializing NSS with certpath: sql:/etc/pki/nssdb
  • CAfile: none
    CApath: none
  • loaded
  • NSS error -5961 (PR_CONNECT_RESET_ERROR)
  • TCP connection reset by peer
  • Closing connection 0
    curl: (35) TCP connection reset by peer

Tried using openssl, with command “openssl s_client -connect” and received “write:errno=104”. Other server, which works (sometimes) didn’t receive it.

If you have this 35 error, your settings are looking broken.

Try to load the Ssllabs - client test

via your curl and save the output. There may be informations about your protocol and your cipher suite.

If I understood you correctly, I ran “curl” from the command line. I then ran the same command on another CWP-server, which has AutoSSL working. I saved both results in .html-file and compared them, and they were identical.

I also tested “curl --insecure”, still getting

  • NSS error -5961 (PR_CONNECT_RESET_ERROR)
  • TCP connection reset by peer
  • Closing connection 0
    curl: (35) TCP connection reset by peer

Try either of these in /etc/hosts:


(not a reliable solution, but can pin the cause down/can be a workaround for 1 day)

1 Like

Thank you!

The first one connected succesfully with curl, and AutoSSL started to work as well.

Any idea how to fix the issue in the long run? Both servers tried to connect to the same IP address with curl (

I don’t, sorry. More or less every month there is a user or two who have problems with the specific Akamai servers that are closest to them, for whom that workaround helps.

However, in the years that this has been happening, I’ve never seen anybody been able to pin it down and debugging on both ends has been fruitless.

If it affects your entire network, perhaps you can get your NOC look into it. If it only affects a single server, then I have no idea.

There were problems on multiple servers at one point, but all the others started to work on their own. For now it’s only been a single server with this issue (that we know of).

Are the different servers connecting to the same Akamai IP addresses?

Maybe some of them use IPv6?

One simple test may be to just run:

curl --resolve

on all of your servers, and see which ones fail.

If your NOC can also run that from their routers, that would be good too.

(The IP address is the “bad” one from earlier in the thread)

Same Akamai IP address, no IPv6, same subnet.

Most of our servers are Windows servers though, and Certify the Web works fine with those. Only a few with CentOS (and CWP).


Do you mind to check the MTU size on those affected Centos server?
ifconfig| grep MTU
A user reported a similar issue earlier that was resolved by changing the MTU value…

Thank you

MTU values were identical: eth0 flags 4163, mtu 1500, lo flags 73, mtu 65536

Okay… Then this might not be the issue…

Do you mind to also perform a traceroute to

If possible, please try to perform the same command on a normal machine (in the same subnet)…

(This is the last thing i know to diagnose those issues…)

Thank you

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