Every time your browser shows a padlock icon, a sophisticated cryptographic protocol has already run in the background — usually in under 100 milliseconds. TLS is one of the most well-engineered security systems in use today, and understanding it pays dividends when you're debugging certificate errors, configuring servers, or evaluating security claims.
TLS vs. SSL: Clearing Up the Naming
SSL (Secure Sockets Layer) is the older protocol. It went through versions 1.0, 2.0, and 3.0 before being renamed TLS (Transport Layer Security) at version 1.0 in 1999. SSL 2.0 and 3.0 are broken and disabled everywhere. TLS 1.0 and 1.1 are deprecated. TLS 1.2 and 1.3 are what's actually in use.
TLS 1.3 (published as RFC 8446 in 2018) removed weak algorithms, simplified the handshake, and reduced round trips. When people say "SSL" in casual conversation, they almost always mean TLS. The terms are used interchangeably but only TLS is current.
The TLS 1.3 Handshake, Step by Step
The TLS handshake establishes a shared encryption key between the client and server without ever transmitting that key over the network.
sequenceDiagram
participant C as Client (browser)
participant S as Server
Note over C,S: 1-RTT TLS 1.3 handshake
C->>S: ClientHello (versions, ciphers, key_share, client_random)
S->>C: ServerHello (chosen cipher, key_share, server_random)
Note over C,S: Both derive the same session key via Diffie-Hellman
S->>C: {Certificate, CertificateVerify, Finished} (encrypted)
C->>S: {Finished} (encrypted)
C->>S: Application data (encrypted)
S->>C: Application data (encrypted)
Step 1 — ClientHello
Your browser sends a message listing the TLS version it supports, a random value (client_random), and the cipher suites it supports (e.g. TLS_AES_256_GCM_SHA384). In TLS 1.3, the client also includes a "key share" — it picks a few likely key exchange algorithms and pre-generates public keys for each, sending them speculatively to save a round trip.
Step 2 — ServerHello
The server picks the cipher suite, sends its own server_random, and selects one of the key shares. At this point, both sides can compute the same session key independently using Diffie-Hellman math — the key was never transmitted.
Step 3 — Certificate The server sends its certificate. This is a public document that contains the server's public key and is signed by a Certificate Authority. Everything from here is already encrypted with the session key derived in the previous step.
Step 4 — CertificateVerify and Finished
The server signs a transcript of the entire handshake with its private key, proving it owns the certificate. The client verifies this signature. Both sides exchange Finished messages containing a MAC of the full handshake transcript — if anything was tampered with in transit, this check fails.
The entire TLS 1.3 handshake takes 1 round trip (down from 2 in TLS 1.2). Resumed sessions can use 0-RTT data, sending application data in the first message.
Certificate Chains
A TLS certificate isn't just one piece — it's a chain.
flowchart TD R["Root CA<br/>(self-signed,<br/>trusted by OS/browser)"] I["Intermediate CA<br/>(signed by Root)"] L["Leaf cert: example.com<br/>(signed by Intermediate)"] R -- signs --> I I -- signs --> L classDef root fill:#1f1f1f,stroke:#f5c842,color:#e4e4e4; classDef inter fill:#1f1f1f,stroke:#60a5fa,color:#e4e4e4; classDef leaf fill:#1f1f1f,stroke:#4ade80,color:#e4e4e4; class R root class I inter class L leaf
- Leaf certificate: Your site's certificate. Contains your domain name and public key.
- Intermediate certificate(s): Signed by the root CA. Root CAs don't sign leaf certs directly to limit exposure if an intermediate is compromised.
- Root certificate: Self-signed by the CA. Trusted by your OS/browser by default.
Your browser walks the chain from your site's cert up to a root it already trusts. If any link in the chain is invalid, the connection fails. This is why forgetting to include the intermediate certificate when configuring your web server causes errors — your browser may not be able to build the chain.
You can inspect a certificate chain in browser DevTools: click the padlock, then "Certificate" (Chrome) or "More Information > View Certificate" (Firefox). You'll see each certificate in the chain.
How Your Browser Verifies a Certificate
flowchart TD
Start([Receive certificate for example.com])
Domain{Domain matches<br/>CN or SAN?}
Validity{Within Not Before /<br/>Not After window?}
Chain{Each cert signed<br/>by trusted parent?}
Revoke{OCSP / CRL<br/>says valid?}
CT{Present in<br/>CT logs?}
OK([Padlock])
Fail([Red warning])
Start --> Domain
Domain -- yes --> Validity
Validity -- yes --> Chain
Chain -- yes --> Revoke
Revoke -- yes --> CT
CT -- yes --> OK
Domain -- no --> Fail
Validity -- no --> Fail
Chain -- no --> Fail
Revoke -- no --> Fail
CT -- no --> Fail
When your browser receives a certificate for example.com, it checks several things:
- Domain match: Does the
Common NameorSubject Alternative Namefield match the hostname? Wildcards like*.example.comare allowed. - Validity period: Is today between
Not BeforeandNot After? - Chain of trust: Does each certificate in the chain have a valid signature from the next?
- Revocation: Has the certificate been revoked? This is checked via OCSP (Online Certificate Status Protocol) or by consulting a CRL (Certificate Revocation List).
- CT logs: Is the certificate in the Certificate Transparency logs? More on this below.
If any check fails, you see the red warning. The error codes (ERR_CERT_COMMON_NAME_INVALID, ERR_CERT_DATE_INVALID, etc.) directly correspond to which check failed.
Certificate Transparency
Since 2018, all publicly trusted certificates must be logged in Certificate Transparency (CT) logs — append-only public databases. This means every certificate issued for yourbank.com is publicly visible. Anyone can monitor CT logs for certificates issued for their domains, making it very hard for a rogue CA to issue a secret certificate.
You can search CT logs at crt.sh. If you own a domain and want alerts when new certificates are issued, services like Facebook's Certificate Transparency monitoring will notify you. This is a genuine security win — it's how unauthorized certificate issuance gets caught.
HSTS: Forcing HTTPS After the First Visit
HTTP Strict Transport Security (HSTS) tells browsers that your site should only be accessed over HTTPS, for a specified period:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadOnce a browser has seen this header, it will refuse to connect to your site over HTTP — even if the user types http:// — until the max-age expires. The preload directive gets your domain added to a browser-maintained list that enforces HTTPS before the first visit.
HSTS prevents a class of attacks where someone intercepts the initial HTTP request before the redirect to HTTPS. But there's a catch: if you accidentally set a very long max-age and then need to revert to HTTP (e.g. your cert lapses), users will be locked out. Start with a short max-age, verify everything works, then extend it.
Mixed Content
Mixed content warnings appear when an HTTPS page loads resources (images, scripts, stylesheets) over HTTP. Browsers block active mixed content (scripts, iframes) entirely and often warn on passive mixed content (images). If your site shows a padlock with a warning triangle, this is usually the cause. Check the browser console — it'll identify the offending resources.
Let's Encrypt and Automated Certificates
Before Let's Encrypt (launched 2016), getting a TLS certificate meant paying a CA, completing manual verification, and renewing annually. Let's Encrypt made certificates free and automated via the ACME protocol.
sequenceDiagram participant Server as Your server (Caddy/Certbot) participant LE as Let's Encrypt Server->>LE: Account registration + new-order request for example.com LE->>Server: Challenge token (HTTP-01 or DNS-01) Server->>Server: Place token at /.well-known/acme-challenge/<br/>or _acme-challenge TXT record LE->>Server: Verify challenge by fetching token LE->>Server: Issue 90-day certificate Note over Server,LE: Renewal repeats automatically every ~60 days
With Certbot or built-in server support (Caddy does this automatically), your server proves domain ownership by either serving a specific file over HTTP or creating a DNS record, then receives a 90-day certificate. Renewal happens automatically. This is why HTTPS is now essentially free — the barrier was cost and friction, not technical capability.
TLS is deeply connected to the hashing and public key infrastructure we covered elsewhere. If you want to understand how SHA-256 and digital signatures play into the certificate verification steps, Hashing Algorithms Guide and Public Key Cryptography Explained fill in those layers.
The Hash Generator tool lets you generate SHA-256 and other hashes to explore the algorithms that underpin TLS. The Base64 Encoder is useful when working with PEM certificate files, which are base64-encoded DER data.
TLS 1.3 is a well-designed protocol — the engineers who built it learned decades of hard lessons from SSL's failures. When you configure a new server, enforcing TLS 1.3 minimum and setting HSTS correctly gives you solid protection against most network-level attacks.
FAQ
Should I disable TLS 1.2 and only allow TLS 1.3?
Not yet, in 2026. TLS 1.2 with modern cipher suites (AES-GCM, ChaCha20-Poly1305) is still considered secure, and a small but non-trivial slice of clients — older Android, embedded devices, some corporate proxies — still negotiate 1.2. The right policy is: enforce TLS 1.2 minimum, prefer TLS 1.3, and disable TLS 1.0/1.1 entirely.
Why does my site show "Not Secure" even though I have a certificate?
The most common cause is mixed content — an HTTPS page loading an http:// script, image, or stylesheet. The second most common is an incomplete chain (you forgot to install the intermediate cert) or a certificate that doesn't cover the exact hostname (e.g. cert for example.com but user visited www.example.com). Browser DevTools' Security tab will tell you exactly which.
Is HTTPS slower than HTTP?
In 2026, no — usually faster. TLS 1.3 reduces the handshake to one round trip, modern CPUs have AES-NI hardware acceleration, and HTTP/2 and HTTP/3 only run over TLS, so HTTPS unlocks multiplexing and 0-RTT resumption that plain HTTP doesn't get. The "HTTPS is slower" rule of thumb stopped being true around 2015.
Do I need to pay for a certificate?
No. Let's Encrypt, ZeroSSL, and Google Trust Services all issue free DV (domain-validated) certificates that browsers trust the same as any paid cert. Paid certs (OV/EV) only matter if you specifically need an organization name in the cert details, which most users never look at. For 99% of sites, free is the correct choice.
Why are certificates only valid for 90 days?
Shorter validity limits the damage from a leaked private key — at most 90 days of risk vs. years for older 2-year certs. CT logs and revocation are imperfect, so reducing the window matters. Browsers are pushing toward 47-day validity by 2027, which means automated renewal (ACME) is no longer optional.
What happens if my cert expires?
Every browser shows a hard-block error and most users will leave. There's no grace period, no "expires soon" mode — it works one minute, fails the next. This is why automated renewal with monitoring is critical. Set alerts at 30 days before expiry so a failed cron job doesn't take you down.
Can someone with my certificate impersonate my site?
The certificate alone isn't enough — they also need the matching private key, which never leaves your server in normal operation. If your private key leaks, an attacker can impersonate your site until you revoke the cert and CT logs may detect the rogue issuance. This is why private keys live in restricted directories with 600 permissions and ideally inside an HSM or KMS.
What's the difference between SSL and TLS in 2026?
There is no SSL anymore — every "SSL certificate" sold today is actually a TLS certificate. The name persists in product marketing because it's recognizable. SSL 2.0 and 3.0 are broken (POODLE attack); even TLS 1.0 and 1.1 are deprecated by all major browsers. Anyone still saying "use SSL" technically means TLS.