curl: (35) TLS connect error: error:0A000102:SSL routines::unsupported protocol

Recent curl releases (8.14.1 here) put "TLS connect error: " before the OpenSSL reason. OpenSSL 1.1.1 names the function: "error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol". When the server is the side that refuses, the client sees "tlsv1 alert protocol version" instead.

curl (OpenSSL backend) — CURLE_SSL_CONNECT_ERROR, SSL_R_UNSUPPORTED_PROTOCOL

What it means

The server answered the ClientHello by choosing a protocol version that curl's TLS library is not allowed to use, typically TLS 1.0 or 1.1. The client then aborts on its own side. The network path and the certificate are irrelevant here: the two ends simply have no TLS version in common.

Why it happens

• The server only supports TLS 1.0 or 1.1

  common

  Old Windows Server/IIS installs, Java 6/7 era applications and unmaintained load balancers still negotiate TLS 1.0. RFC 8996 deprecated TLS 1.0 and 1.1 in 2021, and current clients no longer offer them.

• The client's system policy sets a minimum of TLS 1.2

  common

  Debian, Ubuntu (since 20.04), RHEL 8+ crypto policies and OpenSSL 3's default security level all reject TLS 1.0/1.1. The same server may still work from an older machine, which makes the failure look environment-specific.

• Embedded management interfaces and devices

  occasional

  Printer and UPS web interfaces, old IPMI/iLO firmware, SCADA gateways and similar devices often cannot be upgraded past TLS 1.0.

How to fix it

1. 1.

   Confirm which versions the server accepts

   Try each version explicitly. If only tls1 or tls1_1 succeed, the server must be upgraded; if tls1_2 succeeds too, look for a client option that caps the maximum version.

   # Which versions does the server accept? (each line succeeds or fails on its own)
   for v in tls1 tls1_1 tls1_2 tls1_3; do
     printf '%s: ' "$v"
     openssl s_client -connect legacy.example.com:443 -"$v" </dev/null >/dev/null 2>&1 && echo ok || echo no
   done

2. 2.

   Enable TLS 1.2 and 1.3 on the server

   Turn on TLS 1.2 (and 1.3 where the stack supports it) and turn off 1.0/1.1. This is the only fix that also helps browsers, mobile apps and other API clients.

   # nginx
   ssl_protocols TLSv1.2 TLSv1.3;
   # Apache httpd
   SSLProtocol -all +TLSv1.2 +TLSv1.3
   # IIS / Windows Server: enable TLS 1.2 under
   # HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server

3. 3.

   Last resort: allow TLS 1.0 for one call to a device you cannot upgrade

   Re-enable the old version only for the specific command that talks to the legacy device, never system-wide. TLS 1.0 relies on SHA-1 and CBC constructions with known attacks; keep such traffic on an isolated management network.

   # Last resort for a device you cannot upgrade: allow TLS 1.0 for this one call only.
   # OpenSSL 3 also needs security level 0 for the SHA-1 based handshake of TLS 1.0/1.1.
   curl --tlsv1.0 --ciphers 'DEFAULT:@SECLEVEL=0' https://legacy-device.example.internal/

← Browse the full signature error database