SSL Certificate Errors Reference
Identify, understand, and fix SSL/TLS error codes. Browse browser certificate errors, TLS alert codes, and OpenSSL errors with step-by-step troubleshooting guides.
Last reviewed and updated: March 2026
Browser Errors
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.
Certificate Date Invalid
The server's SSL/TLS certificate has expired or is not yet valid according to the system clock.
Certificate Authority Invalid
The browser does not trust the Certificate Authority that signed the server's SSL certificate.
SSL Protocol Error
The browser could not establish a secure connection because the SSL/TLS protocol negotiation failed.
Certificate Name Mismatch
The domain name in the URL does not match any of the names listed in the server's SSL certificate.
Bad Client Authentication Certificate
The server requires a client certificate for mutual TLS authentication, but the client's certificate was rejected.
SSL Version or Cipher Mismatch
The browser and server could not agree on a supported SSL/TLS version or cipher suite.
Certificate Revoked
The server's SSL certificate has been revoked by its Certificate Authority and is no longer trusted.
Pinned Key Not in Certificate Chain
The server's certificate chain does not contain a public key that matches a previously pinned key (HPKP or built-in pin).
TLS Alert Codes
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.
TLS Handshake Failure
The TLS handshake could not be completed because the client and server failed to negotiate acceptable security parameters.
Bad Certificate
A certificate in the TLS handshake was corrupt, contained invalid signatures, or could not be parsed.
Unsupported Certificate
The certificate type is not supported by the TLS implementation or does not meet the required criteria.
Certificate Revoked
The TLS peer determined that the presented certificate has been revoked by its issuing Certificate Authority.
Certificate Expired
The TLS peer rejected the certificate because it has passed its expiration date.
Certificate Unknown
The certificate was rejected for a reason not covered by other specific TLS certificate alerts.
Illegal Parameter
A field in a TLS handshake message contained an out-of-range or inconsistent value.
Unknown Certificate Authority
The certificate chain could not be validated because the root CA is not in the peer's trust store.
Access Denied
The TLS handshake was rejected because the peer determined the sender is not authorized to proceed.
Decode Error
A TLS message could not be decoded because a field was out of range or the message length was incorrect.
Protocol Version Not Supported
The TLS protocol version offered by the client is not supported by the server.
Insufficient Security
The server rejected the cipher suites offered by the client because they do not meet minimum security requirements.
OpenSSL Errors
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.
SSL System Call Error
An I/O error occurred during an SSL operation, typically indicating a network-level problem or abrupt connection termination.
SSL Library Error
An error occurred in the SSL/TLS library itself, typically indicating a protocol violation or internal processing failure.
SSL Record Too Long
The SSL/TLS library received a record that exceeds the maximum allowed size, usually indicating the server is sending non-TLS data.
SSL Connection Closed Cleanly
The TLS connection was shut down cleanly by the peer sending a close_notify alert.
SSL Wants Read
The SSL operation could not complete because the underlying transport needs to read more data first.
How Does the TLS Handshake Work?
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.
TLS 1.2 Handshake (2 round trips)
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 Handshake (1 round trip)
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.
What Is the Certificate Chain of Trust?
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.
Root CA Certificate
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.
Intermediate CA Certificate
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.
Leaf (End-Entity) Certificate
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
What Is the Difference Between Certificate and Protocol Errors?
SSL/TLS errors fall into two broad categories. Knowing which type you are dealing with immediately narrows down the troubleshooting path:
Certificate Errors
- When they occur: After the TLS handshake has successfully negotiated a protocol version and cipher, but the certificate validation fails.
- Examples: ERR_CERT_DATE_INVALID, ERR_CERT_AUTHORITY_INVALID, ERR_CERT_COMMON_NAME_INVALID, ERR_CERT_REVOKED, unknown_ca, certificate_expired.
- Fix: Renew, reissue, or reconfigure the certificate. Check the certificate chain, domain names, and CA trust. Use DNS Inspector to verify CAA records.
Protocol Errors
- When they occur: Before or during the TLS handshake, when the client and server fail to agree on how to communicate securely.
- Examples: ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH, handshake_failure, protocol_version, insufficient_security.
- Fix: Update TLS configuration to support modern protocol versions and cipher suites. Use Port Scanner to verify port 443 is open.
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.
Troubleshoot SSL/TLS Errors with Free Tools
Diagnose certificate, handshake, and configuration issues with these free diagnostic tools.
DNS Inspector
Verify CAA records and domain DNS resolution for certificate validation.
Port Scanner
Check if port 443 (HTTPS) is open and accepting TLS connections.
Security Headers Checker
Audit TLS configuration, HSTS policy, and security headers.
Redirect Checker
Check HTTPS redirect chains and mixed content issues.
HTTP Header Checker
Inspect certificate details and TLS version in response headers.
Related Error Code References
SSL/TLS errors frequently surface alongside HTTP status codes, Cloudflare edge errors, and server-side log entries. These companion references help diagnose the full picture.