Identify, understand, and fix SSL/TLS error codes. Browse browser certificate errors, TLS alert codes, and OpenSSL errors with step-by-step troubleshooting guides.
These errors appear in Chrome, Edge, Firefox, and Safari when the browser detects a problem with the server's SSL/TLS certificate or the secure connection setup. They block the page load and require user action to proceed.
The server's SSL/TLS certificate has expired or is not yet valid according to the system clock.
The browser does not trust the Certificate Authority that signed the server's SSL certificate.
The browser could not establish a secure connection because the SSL/TLS protocol negotiation failed.
The domain name in the URL does not match any of the names listed in the server's SSL certificate.
The server requires a client certificate for mutual TLS authentication, but the client's certificate was rejected.
The browser and server could not agree on a supported SSL/TLS version or cipher suite.
The server's SSL certificate has been revoked by its Certificate Authority and is no longer trusted.
The server's certificate chain does not contain a public key that matches a previously pinned key (HPKP or built-in pin).
TLS alerts are protocol-level messages defined in RFC 8446 that communicate errors during the TLS handshake or session. These appear in server logs, packet captures, and debugging tools like openssl s_client.
The TLS handshake could not be completed because the client and server failed to negotiate acceptable security parameters.
A certificate in the TLS handshake was corrupt, contained invalid signatures, or could not be parsed.
The certificate type is not supported by the TLS implementation or does not meet the required criteria.
The TLS peer determined that the presented certificate has been revoked by its issuing Certificate Authority.
The TLS peer rejected the certificate because it has passed its expiration date.
The certificate was rejected for a reason not covered by other specific TLS certificate alerts.
A field in a TLS handshake message contained an out-of-range or inconsistent value.
The certificate chain could not be validated because the root CA is not in the peer's trust store.
The TLS handshake was rejected because the peer determined the sender is not authorized to proceed.
A TLS message could not be decoded because a field was out of range or the message length was incorrect.
The TLS protocol version offered by the client is not supported by the server.
The server rejected the cipher suites offered by the client because they do not meet minimum security requirements.
OpenSSL errors are returned by the OpenSSL library used in most server-side TLS implementations. These appear in application logs, curl output, and when debugging TLS connections from the command line.
An I/O error occurred during an SSL operation, typically indicating a network-level problem or abrupt connection termination.
An error occurred in the SSL/TLS library itself, typically indicating a protocol violation or internal processing failure.
The SSL/TLS library received a record that exceeds the maximum allowed size, usually indicating the server is sending non-TLS data.
The TLS connection was shut down cleanly by the peer sending a close_notify alert.
The SSL operation could not complete because the underlying transport needs to read more data first.
Every HTTPS connection begins with a TLS handshake — a series of messages between the client and server that establish the encrypted channel. Understanding this process is essential for diagnosing SSL/TLS errors because each error maps to a specific stage of the handshake.
The client sends a ClientHello with supported versions, cipher suites, and extensions. The server responds with ServerHello (choosing a cipher and version), its certificate chain, and a ServerKeyExchange for Diffie-Hellman. The client verifies the certificate, sends its key exchange value, and both sides derive the session keys. ChangeCipherSpec messages signal the switch to encrypted communication. This takes two network round trips before encrypted data can flow.
TLS 1.3 combines the ClientHello and key share into one message. The server responds with ServerHello, its key share, the certificate, and a Finished message — all in a single flight. The client verifies and sends its Finished message. The entire handshake completes in one round trip. TLS 1.3 also supports 0-RTT for resumed connections, allowing encrypted data to be sent with the very first message.
The client sends its supported TLS versions, cipher suites, key shares (TLS 1.3), and extensions including SNI (Server Name Indication). Errors here: protocol_version if no version overlap.
The server selects a protocol version and cipher, then sends its certificate chain. Errors here: handshake_failure if no common cipher, ERR_CERT_* if certificate validation fails.
The client validates the certificate chain: checks dates, domain name match, CA trust, revocation status, and chain completeness. Most SSL errors occur at this stage.
Both sides complete the key exchange and derive session keys. The Finished messages verify the handshake was not tampered with. Errors here: illegal_parameter, decode_error.
The handshake is complete and both sides can send encrypted data. Errors after this point (like SSL_ERROR_SYSCALL) are usually network-level, not TLS protocol errors.
SSL/TLS security relies on a hierarchical trust model. Every certificate must be traceable back to a trusted root Certificate Authority through a chain of cryptographic signatures. Understanding this chain is critical for diagnosing certificate errors.
Self-signed certificates from organizations like DigiCert, Let's Encrypt (ISRG Root), GlobalSign, and Sectigo. These are pre-installed in operating systems and browsers. There are roughly 150 root CAs trusted by major browsers. Root CAs rarely sign end-entity certificates directly — they delegate to intermediates.
Signed by the root CA, intermediates act as delegates that actually issue certificates to customers. This layering protects the root key — if an intermediate is compromised, only it needs to be revoked, not the root. Your server MUST send intermediates during the TLS handshake. Missing intermediates are the most common certificate chain error.
The certificate issued for your specific domain. It contains your domain name(s) in the Subject Alternative Name (SAN) field, your public key, validity dates, and the intermediate CA's signature. This is what browsers validate against the URL. Leaf certificates cannot sign other certificates (the Basic Constraints extension prevents this).
When a browser receives a certificate chain, it verifies each link: the leaf certificate's signature is checked against the intermediate's public key, and the intermediate's signature is checked against the root's public key. If the root is in the browser's trust store, the entire chain is trusted. If any signature is invalid, any certificate is expired, or the root is not trusted, the browser shows a certificate error. You can inspect the chain with: openssl s_client -connect yourdomain.com:443 -showcerts
SSL/TLS errors fall into two broad categories. Knowing which type you are dealing with immediately narrows down the troubleshooting path:
A quick way to tell them apart: if the error message contains the word "certificate" or "cert," it is a certificate error — the TLS handshake reached the certificate validation stage. If the error mentions "protocol," "cipher," "handshake," or "version," it is a protocol error — the handshake failed before certificate validation could begin.