The Complete SSL/TLS Handshake Guide: Auditing Certificates and Chain Errors
Demystify the TLS 1.3 handshake. Learn how to verify certificates, fix missing intermediate authority errors, and configure secure cipher suites.
Tags
How to use SSL Checker
A secure website is the foundation of digital trust. Modern web standards require HTTPS, powered by SSL/TLS certificates. However, simply installing a certificate is not always enough. Outdated cipher configurations, missing intermediate certificate authority (CA) files, or invalid names can cause browsers to throw insecure connection warnings, blocking visitors from opening your website. This guide demystifies the TLS handshake, explains chain configuration, and outlines steps to pass security checks.
Quick Answer
To prevent SSL chain errors: always install the full bundle file (containing both your domain certificate and the CAs intermediate certificates) rather than the leaf certificate alone. Audit your configuration using an SSL verification checker to ensure the entire trust path is resolved.
The TLS 1.3 Handshake in 4 Steps
When a client opens a connection to a secure server, they agree on cryptographic keys. In TLS 1.3, this handshake happens in just one round-trip (1-RTT):
- Client Hello: The browser sends a list of supported cipher suites, key exchange algorithms, and protocol versions. It also includes the SNI (Server Name Indication) header to specify which domain it is visiting.
- Server Hello & Key Generation: The server selects the strongest cipher and returns its SSL certificate, along with its key share parameter.
- Authentication: The client verifies that the certificate is valid, matches the hostname, and is signed by a trusted root Certificate Authority.
- Encrypted Session Established: Both sides compute symmetric keys and start sending fully encrypted HTTP data.
Fixing the Common 'Incomplete Certificate Chain' Error
The most common SSL configuration error is the Incomplete Certificate Chain. This happens when the server administrator uploads the primary (leaf) certificate but forgets to upload the intermediate certificate bundle (often named ca-bundle.crt or chain.pem).
Because major root certificates are pre-installed in operating systems (Windows, macOS, iOS), CAs use an intermediate certificate as a middle layer to sign leaf certificates. If your server does not serve the intermediate certificate during step 2 of the handshake, some browsers (like Chrome on desktop, which can auto-fetch missing chain links) might work, while mobile devices (like iOS Safari or Android Chrome) will reject the handshake and throw SSL error screens.
To fix this, combine your certificates in the correct order in your server config (Nginx, Apache, or HAProxy). The standard ordering in a combined .crt file is:
-----BEGIN CERTIFICATE-----
[Your Primary Domain Leaf Certificate]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Intermediate Certificate Authority Link]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Optional: Root Certificate Authority Link]
-----END CERTIFICATE-----
Recommendations for Secure SSL/TLS Auditing
- Disable legacy protocols: enforce TLS 1.2 and TLS 1.3, and disable outdated SSL 3.0, TLS 1.0, and TLS 1.1 versions.
- Disable weak ciphers: block MD5, RC4, 3DES, and CBC ciphers, and prioritize AES-GCM and CHACHA20-POLY1305.
- Use SSL Checker to audit your domain. It checks key expiration, hostname match, and resolves the entire CA trust chain to locate intermediate issues.
Related Security Audits
Securing port 443 is step one, but make sure you aren't leaving administrative or database ports exposed by using our Port Scanner Guide. If you run custom APIs, you can also use our tools to verify that headers and scripts do not expose vulnerabilities.
FAQ
Q: What is the difference between SSL and TLS?
A: TLS (Transport Layer Security) is the updated, secure successor to SSL (Secure Sockets Layer). Today, all "SSL certificates" are actually TLS certificates, but the industry still uses "SSL" as a general term.
Q: Why does my SSL certificate fail on mobile but work on desktop browsers?
A: Desktop browsers often have built-in caches of intermediate certificates, allowing them to complete chain lookups. Mobile browsers enforce strict validation and will fail if the server does not serve intermediate certificates.
Q: How long are modern SSL certificates valid for?
A: Public CAs limit validity to a maximum of 397 days (about 13 months). Automated certificates (like Let's Encrypt) are valid for 90 days and rotate automatically.