The "curl: (35) GnuTLS handshake() failed" error on Ubuntu 16.04 typically stems from an outdated certificate store or incompatible TLS protocol versions. Resolving this requires updating the ca-certificates package and ensuring the system uses modern TLS protocols supported by the target server.
Understanding the Error Context
When executing acurl command, users may encounter the specific failure message indicating that the GnuTLS library encountered an issue during the initial handshake phase. This is distinct from network connectivity issues or DNS resolution failures. The error suggests that while the connection to the remote host was established, the negotiation of encryption parameters failed. On older distributions like Ubuntu 16.04, this often happens because the default configuration restricts TLS versions to older standards, which many modern servers no longer support due to security vulnerabilities. Additionally, if the root certificates used to verify the server's identity are missing or corrupted, the handshake will abort immediately to prevent potential man-in-the-middle attacks.
Updating Certificate Authorities
The most common cause for this specific error is an incomplete or outdated local copy of trusted Root Certificates. Thecurl utility relies on these certificates to validate the SSL/TLS certificate presented by the remote server. If the local store does not contain the issuer of the server's certificate, the handshake fails. To rectify this, you must update the certificate database using the package manager. Run the following commands to ensure your system has the latest trust anchors.
sudo apt-get update
sudo apt-get install --reinstall ca-certificates
sudo update-ca-certificatesca-certificates package, which replaces any potentially corrupted files. Finally, the update-ca-certificates script regenerates the combined bundle of certificates that applications like curl read. After running these steps, attempt the original curl command again. In many cases, this simple update resolves the handshake failure without requiring further configuration changes.
Configuring TLS Protocol Versions
If updating the certificates does not resolve the issue, the problem likely lies in the protocol version negotiation. Older versions of GnuTLS, defaulting to Ubuntu 16.04, might attempt to use TLS 1.0 or 1.1, which are deprecated by many web services. You can explicitly tellcurl to use only TLS 1.2 or higher by adding the --tlsv1.2 flag. This forces the client to propose a secure protocol version that the server is known to accept.
curl --tlsv1.2 https://example.com--tls-max 1.2 if the server rejects newer proposals, though this is less common. Another approach is to disable strict hostname checking temporarily for diagnostic purposes using -k or --insecure, but this should be avoided in production as it exposes the connection to interception. If the command succeeds with --tlsv1.2, you have confirmed that the server requires a modern protocol version. For persistent scripts, consider setting the environment variable CURL_SSL_VERSION=tls_1_2 to avoid typing the flag every time.
Checking System Dependencies and Libraries
In rare instances, the issue may arise from a mismatch between thecurl binary and the installed GnuTLS libraries. If multiple versions of OpenSSL or GnuTLS are present on the system, dynamic linking errors can occur. Verify that the libgnutls28-dev package is installed and up to date. You can check the version of GnuTLS currently linked to your curl binary using the ldd command.
ldd $(which curl) | grep gnutlscurl itself.
sudo apt-get remove curl
sudo apt-get install curlRelated Resources
For more complex scenarios involving custom certificates or specific server configurations, you might find additional guidance in our guide on establishing connections with unknown CAs, which covers manual certificate injection. Additionally, troubleshooting steps for other Linux distributions like RHEL8 can provide insights into broader system-level network configurations that affect curl behavior. Make cURL establish TLS connection with CA unknown Troubleshooting curl not working on an RHEL8 ServerFrequently Asked Questions
Why does the error happen only on some websites?
This occurs because different servers enforce different security policies. While one site might still support older TLS versions, another may require TLS 1.2 or 1.3 exclusively. Your client must match the server's minimum requirement to complete the handshake.
Can I fix this by disabling SSL verification?
You can use the -k or --insecure flag to bypass certificate verification, but this is highly discouraged for production use. It leaves your connection vulnerable to man-in-the-middle attacks by ignoring invalid certificates entirely.
Does this error affect wget or other tools?
Yes, if they are configured to use GnuTLS or similar SSL libraries. However, tools like wget often have separate configuration files or flags to specify SSL backends. Checking the documentation for your specific tool is necessary to apply equivalent fixes.
How do I check my current TLS version support?
You can test your system's supported versions by running curl -v https://www.howsmyssl.com/a/check. The verbose output will show the exact TLS version negotiated during the connection, helping you confirm if your client is using a deprecated protocol.
Is upgrading Ubuntu 16.04 the permanent solution?
While upgrading to a supported LTS release provides the latest security patches and libraries, it is not always feasible immediately. Applying the certificate updates and protocol flags outlined above provides a robust workaround for maintaining functionality on legacy systems.