curl: (35) SSL Connect Error. Read the Reason and Fix the Handshake

Exit code 35 is CURLE_SSL_CONNECT_ERROR. The libcurl documentation is blunt about it: «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.» The code only says «the handshake failed»; the text after it says why.

With the OpenSSL backend that text is OpenSSL's error string, for example TLS connect error: error:0A000410:SSL routines::sslv3 alert handshake failure. When OpenSSL has no reason to give, because the socket simply closed, curl prints OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com:443 (lib/vtls/openssl.c). On Windows builds using Schannel the text starts with schannel: next InitializeSecurityContext failed: followed by a Windows status.

A rejected certificate is a different exit code. When the handshake completes but the chain or name does not verify, curl returns 60 (CURLE_PEER_FAILED_VERIFICATION) with SSL certificate problem: .... Exit 35 happens earlier: the two sides never agreed on a connection at all.

The OpenSSL wording changed between releases: OpenSSL 3.0 prints «sslv3 alert handshake failure» while 3.2 and later print «ssl/tls alert handshake failure» for the same reason code 1040 (crypto/err/openssl.txt). Search logs by the hex code 0A000410 to catch both.

Most error 35 reports after an OS upgrade are version or cipher mismatches. OpenSSL 3 refuses TLS 1.0 and 1.1 at its default security level, so a client that worked against a legacy appliance stops working after the upgrade while browsers were already refusing it. The fix belongs on the server: TLS 1.2 or 1.3 with ECDHE ciphers. As a short diagnostic only, you can check whether an old protocol is the reason by testing it explicitly; do not ship such an override.

When the error appears only on one network (a corporate LAN, a hotel, a CI runner) and the same command works elsewhere, something in the path is interfering: a proxy that resets TLS to hosts it does not like, or a filter keyed on the SNI host name. SSL_ERROR_SYSCALL with zero bytes read is the usual signature. If you must go through an HTTPS-inspecting proxy, configure it with -x rather than letting it intercept transparently.

A server that requires a client certificate also stops TLS 1.2 handshakes with an alert. Under TLS 1.3 curl reports the missing certificate separately, as TLS cert problem: with exit code 58 (CURLE_SSL_CLIENTCERT).

1. See how far the handshake got. curl -v https://example.com/ prints each TLS step (Client hello, Server hello...). If nothing comes back after the client hello, the server or a middlebox closed the connection.
2. Check the TLS library curl uses: curl -V shows OpenSSL/3.x, Schannel or another backend. The reason strings differ between them.
3. Test each version and SNI with OpenSSL:

   openssl s_client -connect example.com:443 -servername example.com -tls1_3 -brief </dev/null
   openssl s_client -connect example.com:443 -servername example.com -tls1_2 -brief </dev/null
   openssl s_client -connect example.com:443 -noservername -brief </dev/null

   If only the last one fails, the server needs SNI and your client is not sending it, typically because it connects to an IP address.
4. List what the server offers: nmap --script ssl-enum-ciphers -p 443 example.com. No TLS 1.2 or 1.3 entries means the server is the problem.
5. On your server (nginx): check nginx -T | grep -E 'ssl_protocols|ssl_ciphers' and enable ssl_protocols TLSv1.2 TLSv1.3;. Look in the error log for SSL_do_handshake() failed lines with the same OpenSSL reason.
6. Schannel revocation failures: make sure the machine can reach the CRL and OCSP URLs in the certificate. --ssl-revoke-best-effort ignores revocation checks only when the distribution points are missing or offline; --ssl-no-revoke turns checks off entirely and loosens security.

curl -sS -o /dev/null -w '%{http_code} %{ssl_verify_result}\n' https://example.com/
# 200 0
openssl s_client -connect example.com:443 -servername example.com -brief </dev/null
# Protocol version: TLSv1.3

Test from the network that failed. To see which protocol versions and certificate the server presents from outside, run the SSL/TLS checker.

• wrong version number — the port is not speaking TLS
• curl 60: unable to get local issuer certificate — handshake done, chain untrusted
• SSL handshake failed — the same failure seen from other clients
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH — Chrome's no-shared-version error
• curl error 28 — the handshake hung instead of failing
• How to debug a TLS handshake — step-by-step with s_client