What is SSL/TLS?

02What the handshake does

Before any data moves, client and server negotiate. The client announces which TLS versions and cipher suites it supports; the server picks from that list, presents its certificate, and the two derive a shared secret that only they know.

The clever part is that the shared secret is derived rather than transmitted. With modern key exchange, someone recording the whole conversation still cannot decrypt it later even if the server's private key is stolen afterwards — a property called forward secrecy. TLS 1.3 made it mandatory by removing static RSA and Diffie-Hellman key exchange altogether.

TLS 1.3 also cut the full handshake from the two round trips of TLS 1.2 to one. It adds an optional 0-RTT mode for resumed connections that sends data immediately, at a price the specification spells out: that early data is not forward secret and can be replayed, so it should only carry requests that are safe to repeat.

Because the ClientHello is sent before any keys exist, its contents are visible to the network: the server name requested and the versions, cipher suites and extensions offered. Different TLS libraries produce recognisably different ClientHellos, which is the basis of TLS fingerprinting.

client → ClientHello        versions, cipher suites, key share
server → ServerHello        chosen suite, key share
         Certificate        proof of identity
         Finished           handshake authenticated
client → Finished           encrypted from here on

one round trip, then application data flows encrypted

03What a certificate actually proves

A certificate binds a public key to a domain name, signed by a certificate authority your browser already trusts. When the server presents it, the browser checks the signature chain, that the name matches, and that it has not expired or been revoked.

It is worth being precise about what that proves: control of the domain at the time of issue. Nothing more. A valid certificate does not mean the site is honest, safe or run by a real company — a phishing site can obtain one in minutes.

Certificates are also getting shorter-lived. Under CA/Browser Forum ballot SC-081, publicly trusted TLS certificates issued from 15 March 2026 may be valid for at most 200 days, falling to 100 days from 15 March 2027 and 47 days from 15 March 2029. Manual renewal stops being realistic well before the last step.

Publicly trusted certificates are recorded in public, append-only Certificate Transparency logs; Chrome and Safari require proof of logging. That is good for catching mis-issued certificates and bad for anyone hoping a hostname stays secret: a certificate for origin.example.com announces that the name exists, one of the leaks covered in hiding your origin IP.

04TLS termination and re-encryption

When a reverse proxy or CDN sits in front of your server, it usually terminates TLS: the encrypted connection ends there, the request is inspected, and a second connection is made to your origin. This is what makes a WAF possible at all — you cannot inspect what you cannot read.

The second leg should also be encrypted. If a provider terminates TLS at the edge and then talks to your origin in plain text, everything between them and you is readable by anyone on that path. Full end-to-end encryption should be the default, not an upgrade.

• Edge termination — required for caching, inspection and compression
• Re-encryption to the origin — should always be on
• Automatic certificate issuance and renewal, so nothing expires silently
• Certificates issued through DNS validation (the ACME dns-01 challenge in RFC 8555), so the origin never has to be publicly reachable for issuance

05Configuring it well

The settings below cover most of what matters on an origin server. The snippet is nginx; every web server has the same choices under different names. Set the protocol list explicitly rather than relying on defaults, which have changed between versions.

• Disable everything below TLS 1.2 — TLS 1.0 and 1.1 are deprecated
• Prefer TLS 1.3 where clients support it
• Enable HSTS (RFC 6797), one of the HTTP security headers, so browsers refuse to fall back to plain HTTP — and know that it also removes the option to click through a certificate warning, so a lapsed certificate becomes a hard outage
• Automate renewal; a certificate nobody remembered is one of the most avoidable outages there is
• Serve the full chain, leaf first and intermediates after it in the same file — a missing intermediate breaks some clients and not others, which is a miserable bug to chase

# Port 80 only redirects; nothing is served in plain text
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;

    # leaf certificate first, then the intermediates, in one file
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_session_cache shared:TLS:10m;

    # one year; add includeSubDomains only once every subdomain has HTTPS
    add_header Strict-Transport-Security "max-age=31536000" always;

    root /var/www/example.com;
}

06Checking a server from the command line

The SSL/TLS checker shows expiry, chain and negotiated version for any public hostname, and the security headers checker confirms whether HSTS is actually being sent. From a terminal, OpenSSL answers the same questions and also works on servers that are not public yet.

# certificate subject, issuer, expiry and the names it covers
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -enddate -ext subjectAltName

# chain, hostname and negotiated version: look for "Verify return code: 0 (ok)"
openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com </dev/null 2>&1 \
  | grep -E '^New,|Verify return code'

# TLS 1.1 must be refused; SECLEVEL=0 lets the client at least offer it
openssl s_client -connect example.com:443 -servername example.com -tls1_1 \
  -cipher 'DEFAULT:@SECLEVEL=0' </dev/null

# will the certificate still verify 30 days from now?
openssl s_client -connect example.com:443 -servername example.com \
  -attime $(date -d '+30 days' +%s) </dev/null 2>&1 | grep 'Verify return code'

07Common TLS errors and what they mean

Browsers and OpenSSL name the same failures differently. The browser codes below are Chromium's; the OpenSSL messages are what the commands above print. The NET::ERR_CERT codes behind a "Your connection is not private" warning, including the visitor-side causes, are mapped one by one in your connection is not private.