How HTTPS and TLS Really Work: Handshake and Certificates

Why HTTPS Matters (and Why It's Misunderstood)

You've probably seen the padlock icon in your browser and assumed the site is "secure." But what does that really mean? HTTPS is not just about encryption; it's about identity, integrity, and trust. Many developers treat TLS as a black box—configure it once and forget it. That leads to misconfigurations, expired certificates, and vulnerable cipher suites.

In this article, we'll break down how HTTPS and TLS actually work, from the handshake to certificate validation, and show you how to set it up correctly. No fluff, just practical knowledge you can apply today.

The TLS Handshake: What Happens Before the First Byte

When a client (browser) connects to a server over HTTPS, they perform a TLS handshake. This establishes a secure channel. Here's a simplified version (TLS 1.3):

1. Client Hello: The client sends supported cipher suites, a random value, and a key share (for key exchange).
2. Server Hello: The server picks a cipher suite, sends its own random value and key share, and presents its certificate chain.
3. Authentication: The client verifies the server's certificate against trusted CAs and checks the hostname.
4. Key Derivation: Both sides compute the shared secret using ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).
5. Finished: Both send encrypted "Finished" messages to confirm the handshake.

After this, application data is encrypted with symmetric keys. TLS 1.3 reduces round trips to one, improving latency.

Key Exchange: ECDHE vs RSA

Older TLS versions used RSA key exchange, which lacks forward secrecy. If the server's private key is compromised, past traffic can be decrypted. Modern setups use ECDHE, which provides forward secrecy—each session has unique keys.

# Example: Check supported key exchange algorithms
openssl s_client -connect example.com:443 -cipher 'ECDHE'

Certificates: The Trust Anchors

A certificate binds a public key to an identity (domain name). It's signed by a Certificate Authority (CA) that the client trusts. Browsers ship with a store of trusted root CAs.

When you visit a site, the server sends a chain: leaf certificate (for your domain) → intermediate CA → root CA. The client verifies each signature up to a trusted root.

Types of Certificates

• Domain Validated (DV): Only proves control of the domain. Quick and free (e.g., Let's Encrypt).
• Organization Validated (OV): Includes verified organization details.
• Extended Validation (EV): Stricter vetting; browsers no longer show a green bar, but some enterprises still use them.

Certificate Validation Steps

Browsers check:

• Signature chain leads to a trusted root.
• Certificate is within its validity period.
• Hostname matches (Subject Alternative Names).
• Certificate is not revoked (via OCSP or CRL).

If any check fails, you get a warning. Never bypass these warnings in production.

Configuring HTTPS on Your Server

Let's look at a typical Nginx configuration for HTTPS with modern TLS settings.

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers off;

    # HSTS (use cautiously)
    add_header Strict-Transport-Security "max-age=63072000" always;
}

Notes:

• Use TLS 1.2 and 1.3 only; disable older versions.
• Prefer ECDHE ciphers for forward secrecy.
• Enable HTTP/2 for performance.
• HSTS forces browsers to use HTTPS; only enable after testing.

Obtaining Certificates with Let's Encrypt

Let's Encrypt provides free DV certificates. Use Certbot to automate issuance and renewal:

sudo certbot --nginx -d example.com -d www.example.com

Certbot modifies your Nginx config and sets up a cron job for renewal. Always test renewal with --dry-run.

Common Pitfalls and How to Avoid Them

• Expired certificates: Set up monitoring and auto-renewal.
• Incomplete chain: Include intermediate certificates (fullchain.pem).
• Weak ciphers: Disable RC4, DES, and export ciphers.
• Mixed content: Ensure all resources (images, scripts) load over HTTPS.
• No HSTS: Without HSTS, users can be downgraded to HTTP.

Testing Your HTTPS Configuration

Use online tools like SSL Labs or command-line tools to verify your setup.

# Check certificate details
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -text

# Test TLS 1.3 support
openssl s_client -connect example.com:443 -tls1_3

Look for:

• Valid certificate chain.
• No weak protocols (SSLv3, TLS 1.0, TLS 1.1).
• Forward secrecy enabled.
• HSTS header present.

FAQ

What is the difference between TLS and SSL?

SSL is the predecessor of TLS. TLS 1.0 was essentially SSL 3.1. Today, "SSL" is often used colloquially, but you should always use TLS 1.2 or 1.3.

Do I need a paid certificate for HTTPS?

No. Free DV certificates from Let's Encrypt are trusted by all major browsers and provide the same encryption as paid ones. Paid certificates offer warranties and support, but encryption is identical.

How does HTTPS affect performance?

TLS adds latency due to the handshake, but TLS 1.3 reduces it to one round trip. With session resumption and HTTP/2, the overhead is minimal. Encryption/decryption costs are low on modern CPUs.

Ready to inspect your server's TLS configuration? Use our Nginx Log Analyzer to spot unusual traffic patterns and ensure your HTTPS setup is working as expected.