SSL Certificate Fundamentals
Every time you visit an HTTPS site, a small miracle of cryptography happens in the background. Your browser and the server negotiate encryption algorithms, verify identities, and establish a shared secret — all in under 100 milliseconds. If you're new to SSL, you might want to start with our What is SSL? overview before diving into the technical details.
The current standard is TLS 1.3 (RFC 8446), which represents a significant overhaul of how the handshake works. We'll cover both TLS 1.2 and 1.3 since you'll encounter both in production. For the history ofSSL vs TLS vs HTTPS, we've got a separate explainer.
Public Key Infrastructure
SSL uses asymmetric encryption with public and private key pairs. The public key encrypts; only the matching private key can decrypt. This is what makes secure communication between strangers possible. Learn more about PKI →
Digital Signatures
Certificate Authorities digitally sign certificates to vouch for their authenticity. Your browser checks this signature against its built-in trust store — if the math checks out, the connection proceeds.
Secure Your Website Today
Get professional SSL certificates with our easy installation
SSL Certificate with Installation
Starting at $9.99/year
- Professional Installation
- 256-bit Encryption
- 99.9% Browser Trust
- 24/7 Support
The TLS 1.2 Handshake (2-RTT)
This is the "classic" handshake that's still widely used. It takes two round-trips between browser and server before encrypted data can flow. Here's what happens step by step:
TLS 1.2 Handshake — Step by Step
Client Hello
Browser sends supported TLS versions, a list of cipher suites it can handle, and a random number (called client_random) for key derivation.
Server Hello + Certificate
Server picks a cipher suite, sends its random number (server_random), and delivers its SSL certificate with the full chain.
Certificate Verification
Browser walks the certificate chain up to a trusted root CA, checks expiration, verifies the domain name, and optionally checks revocation status via OCSP.
Key Exchange
Browser generates a pre-master secret, encrypts it with the server's public key, and sends it over. Both sides derive session keys from the pre-master secret + randoms.
Session Keys Created
Both sides independently compute the same session keys and switch to symmetric encryption.
Secure Connection Established
Both parties exchange "Finished" messages encrypted with the new session key, confirming everything worked. Data flows securely from here on out.
The TLS 1.3 Handshake (1-RTT)
TLS 1.3 rethought the handshake from scratch. Instead of negotiating parameters over multiple round-trips, the client sends its key share in the very first message. The result? Encrypted data starts flowing after just one round-trip — cutting latency roughly in half.
Key Differences from TLS 1.2
What Changed
- Client sends key shares immediately (no separate exchange)
- Server response includes encrypted extensions
- 0-RTT mode for resumed sessions (data in first packet)
- Only AEAD cipher suites allowed
What Was Removed
- Static RSA key exchange (no forward secrecy)
- CBC-mode ciphers (vulnerable to padding oracle)
- RC4, 3DES, and other weak algorithms
- Compression (CRIME attack vector)
Pro Tip: 0-RTT Has a Caveat
TLS 1.3's 0-RTT resumption is great for performance, but it's vulnerable to replay attacks. Don't use it for non-idempotent requests (like payments or form submissions). Most web servers handle this correctly by default, but it's worth verifying if you're tuning performance. For server-specific configuration, check our SSL vs TLS guide.
Encryption Methods Used
SSL/TLS uses two types of encryption, and understanding why is important: asymmetric encryption is secure but slow, symmetric encryption is fast but requires a shared secret. The handshake uses the first to establish the second.
Asymmetric Encryption
Used during the handshake for secure key exchange. Two mathematically linked keys — one public, one private. Slower, but solves the "chicken and egg" problem of sharing secrets.
- • RSA (2048-bit or 4096-bit) — widely supported
- • ECDSA (P-256, P-384) — smaller keys, same security
- • Used for digital signatures and key exchange
Symmetric Encryption
Takes over after the handshake for actual data. Both sides share the same session key — much faster than asymmetric, which is why we don't use RSA for everything.
- • AES-128-GCM or AES-256-GCM (most common)
- • ChaCha20-Poly1305 (great on mobile)
- • Session keys are ephemeral — destroyed after use
Need Help with SSL Implementation?
Our technical team can help you set up SSL correctly
SSL Technical Support
Starting at $9.99/year
- Expert Installation
- Configuration Review
- Performance Optimization
- Troubleshooting
Certificate Chain of Trust
Your SSL certificate doesn't exist in isolation. It's part of a hierarchy — a "chain of trust" — that traces back to a root CA pre-installed in your browser. If any link in that chain is broken or missing, visitors get a security warning.
Root Certificate
Self-signed by the CA — pre-installed in browsers and operating systems
Intermediate Certificate
Signed by the root — this is the one people forget to install
End-Entity Certificate
Your website's SSL certificate — the one you install on your server
In Practice
The most common chain-related issue we see? Missing intermediate certificates. Desktop Chrome can sometimes find the intermediate on its own (via AIA fetching), which masks the problem — but mobile Safari, older Android browsers, and API clients will fail. Always install the full chain. Use our SSL Checker to verify. For a deeper dive on certificate trust models, see What is PKI?
OCSP Stapling: Faster Certificate Checks
When a browser checks whether your certificate has been revoked, it traditionally contacts the CA's OCSP responder directly. That adds latency and creates a privacy concern (the CA knows which sites your visitors are checking). OCSP stapling fixes both problems.
With stapling, your server periodically fetches the OCSP response from the CA and includes ("staples") it in the TLS handshake. The visitor gets proof that the cert isn't revoked without making a separate network call. It's a significant performance win, especially on first connections.
Most modern web servers support stapling out of the box — you just need to enable it. Check our Nginx SSL guide orSSL Configuration guide for the exact directives. If you're automating with ACME, our Certbot guide covers renewal hooks that refresh the stapled response automatically.
Browser Security Indicators
Browsers communicate your connection's security status through visual cues. The specifics vary by browser, but the core signals are consistent:
Secure (HTTPS)
Padlock icon and "https://" prefix — valid certificate, encrypted connection
Mixed Content
HTTPS page loading HTTP resources — partial protection, often a configuration issue
Not Secure
No encryption, expired certificate, or domain mismatch — visitors see a red warning
Performance Considerations
The Performance Myth
"HTTPS is slow" was true in 2005. It's not true anymore. Modern hardware handles AES encryption with dedicated CPU instructions (AES-NI), and TLS 1.3's 1-RTT handshake is actually faster than establishing an unencrypted HTTP/2 connection in some cases.
Why It's Fast Now
- • Hardware AES acceleration is standard
- • TLS 1.3 halves the handshake latency
- • Session resumption avoids repeat handshakes
- • ECDSA certs are faster to verify than RSA
Optimization Tips
- • Use ECDSA P-256 certificates
- • Enable OCSP stapling
- • Prefer ChaCha20 on mobile (no AES-NI)
- • Enable HTTP/2 (requires HTTPS)