SSL_connect returning error 5 means SSL_ERROR_SYSCALL - the underlying socket failed or the connection was closed before the TLS handshake could complete. The number 5 is the important clue and the reason people go down the wrong path: it is not a certificate error, not a protocol-mismatch error, and not something a new certificate fixes. It means the network layer under TLS broke, so the handshake never got far enough to have a certificate opinion. You are looking for a connection problem, not a crypto problem.
Error 5 is one of the more misdiagnosed TLS errors precisely because it looks like an SSL problem and is almost never one. Here is what actually causes it.
Table of contents
- What error 5 is telling you
- The usual causes, most common first
- Working it on your own service
- Client-side quick checks
- How this fits the rest of the stack
- FAQ
What error 5 is telling you
OpenSSL’s SSL_get_error returns SSL_ERROR_SYSCALL (value 5) when an I/O operation on the socket failed. In plain terms: TLS asked the socket to send or receive bytes, and the socket said no - connection reset, closed by peer, timed out, or refused. The TLS state machine did not reject anything; it never got the chance.
# Reproduce and see the real story with a verbose handshake
openssl s_client -connect example.com:443 -servername example.com
# Watch for: 'connect:errno=', 'Connection reset by peer',
# or the handshake stopping before 'SSL handshake has read N bytes'If openssl s_client also dies early - not with a certificate complaint but with a connection error - you have confirmed the problem is below TLS. That is the fork in the road: certificate errors name the certificate; error 5 names the socket.
The usual causes, most common first
- The peer closed the connection. The server dropped you mid-handshake - often because it did not like something (wrong SNI, an IP-based block, or it simply is not a TLS server on that port).
- Wrong port or plain-text service. Speaking TLS to a port that serves plain HTTP (or nothing) resets immediately. Confirm the service actually listens for TLS on that port.
- A firewall or proxy in the middle. Corporate proxies, deep-packet-inspection firewalls, and some VPNs kill TLS connections they cannot inspect, showing up as error 5 on the client.
- Timeout under load. A server too busy to complete the handshake in time drops the connection, which surfaces as a syscall error rather than a clean TLS alert.
Working it on your own service
If it is your server throwing this at clients, check three things in order: is the service actually up and listening on the TLS port, is it configured for TLS on that port (not plain HTTP), and is something upstream - a load balancer, a firewall, a rate limiter - severing connections.
# Is anything even listening on 443?
ss -tlnp | grep :443 # Linux
# Does a raw TCP connection open at all?
nc -vz example.com 443If nc -vz cannot even open the TCP connection, TLS is a red herring - the port is closed or filtered, and no certificate change will help. This is the most common real cause on your own infrastructure: the process crashed, the port changed, or a security group is blocking 443.
Client-side quick checks
- Try a known-good host.
openssl s_client -connect cloudflare.com:443. If that also fails with error 5, the problem is your network or a local proxy, not the target server. - Disable the VPN or proxy temporarily. If the error vanishes, a middlebox was killing the handshake.
- Update your TLS library. A very old OpenSSL negotiating with a modern TLS 1.3-only server can fail early; but confirm the connection reaches the server first, or you are treating a network problem as a version problem.
How this fits the rest of the stack
Error 5 is a lesson in reading the layer the error actually points at instead of the layer it appears to name - a habit that shortens every debugging session. When TLS termination is handled by a managed platform, this whole class of ‘is it the socket or the certificate’ question mostly disappears, because the certificate and the listener are provisioned together. The RunxBuild hosting calculator shows a service and its bandwidth as line items, and the RunxBuild dashboard is where the connection and TLS logs sit side by side.
Useful related references:
- SSL protocol error: what it means
- SSL certificate verify failed
- Which port SSL and HTTPS use
- Services on RunxBuild
FAQ
What does SSL_connect error 5 mean?
It means SSL_ERROR_SYSCALL: an I/O operation on the underlying socket failed, so the TLS handshake could not complete. The connection was reset, closed by the peer, refused, or timed out before TLS finished. It is not a certificate or protocol-content error, so a new certificate will not fix it - you are looking for a network or connection problem beneath TLS.
Is SSL_connect error 5 a certificate problem?
Almost never. Certificate problems produce specific verification errors that name the certificate. Error 5 means the socket itself failed before the handshake could evaluate any certificate. Common causes are the peer closing the connection, speaking TLS to a non-TLS port, a firewall or proxy killing the handshake, or a server too overloaded to respond in time.
How do I debug SSL_connect error 5?
Run openssl s_client -connect host:443 and watch whether it fails with a connection error rather than a certificate complaint. Then test raw TCP with nc -vz host 443; if that fails, the port is closed or filtered and TLS is irrelevant. Try a known-good host like cloudflare.com:443 to tell whether the problem is your network or the target server.
Can a firewall or proxy cause SSL_connect error 5?
Yes, frequently. Corporate proxies, deep-packet-inspection firewalls, and some VPNs terminate or reset TLS connections they cannot inspect, which the client sees as a syscall error. Temporarily disabling the VPN or proxy is a fast test: if the error disappears, a middlebox was severing the handshake and you should whitelist the destination or route around it.
Why does error 5 happen on my own server?
Usually the TLS service is not actually listening as expected: the process crashed, the port changed, it is serving plain HTTP on that port, or a load balancer, security group, or rate limiter is cutting connections. Check that something is listening on 443 with ss -tlnp, confirm raw TCP opens with nc -vz, and inspect any upstream proxy before suspecting TLS configuration.