How HTTPS and TLS Actually Work

Every time you visit a website with a padlock icon, TLS is working behind the scenes. But most developers never look beyond that padlock. Understanding how HTTPS and TLS actually function is essential for building secure applications, debugging connectivity issues, and making informed decisions about certificates and encryption.

This article demystifies the TLS handshake, explains the certificate chain of trust, covers the cryptographic keys involved, and shows you how to inspect and verify certificates using hands-on tools.

What Is HTTPS?

HTTPS is simply HTTP encrypted with TLS:

HTTP  = Application data in plaintext
HTTPS = HTTP + TLS encryption layer

When you type https://bestwordz.com in your browser:
1. DNS resolves the domain to an IP address
2. TCP connection is established (port 443)
3. TLS handshake happens (this article)
4. Encrypted HTTP requests/responses flow
5. Connection closes

Without TLS, everything is visible: your passwords, session tokens, search queries, and browsing history. With TLS, an eavesdropper sees only encrypted gibberish.

The Three Pillars of TLS

The TLS 1.3 Handshake

TLS 1.3 is the current standard (RFC 8446, 2018). It completed the handshake in just 1 round-trip — down from 2 round-trips in TLS 1.2. Here is what happens:

Step 1: ClientHello

The browser initiates the handshake by sending its supported options:

ClientHello contains:
├── TLS version: "I support TLS 1.3"
├── Cipher suites: [AES-256-GCM, ChaCha20-Poly1305, ...]
├── Key share: my ECDHE public key (X25519)
├── SNI: "bestwordz.com" (which domain I want)
└── Extensions: ALPN (h2 for HTTP/2), supported groups

The key share is critical: the client generates a temporary ECDHE key pair and sends its public key. This enables 1-RTT because the server can immediately compute the shared secret.

Step 2: ServerHello + Certificate

The server responds with its chosen parameters and identity:

ServerHello contains:
├── Chosen cipher suite: AES-256-GCM-SHA384
├── Key share: my ECDHE public key
├── Certificate: my X.509 certificate chain
├── CertificateVerify: signature over handshake transcript
└── Finished: MAC of entire handshake

The server's CertificateVerify message proves it owns the private key matching the certificate's public key. This is how authentication works — the server signs the entire handshake transcript with its private key.

Step 3: Key Derivation

Both sides now compute shared secrets without ever transmitting them:

1. ECDHE key exchange:
   Client private × Server public = Shared secret
   Server private × Client public = Same shared secret

2. HKDF key derivation:
   Shared secret → Handshake traffic keys
   Shared secret → Application traffic keys

3. Encryption begins:
   Each direction gets its own AES-256-GCM key
   Client-to-server and server-to-client are independent

Try it yourself: Use the Diffie-Hellman Demo to see how two parties can agree on a shared secret over an insecure channel. Then try the ECDH Key Agreement tool for the elliptic-curve variant used in modern TLS.

Certificates: The Chain of Trust

TLS authentication relies on X.509 certificates — digital documents that bind a domain name to a public key. But how does your browser know the certificate is legitimate? Through a chain of trust.

What's Inside a Certificate?

X.509 Certificate:
├── Subject:       bestwordz.com
├── Issuer:        Let's Encrypt Authority X3
├── Public Key:    RSA 2048-bit or ECDSA P-256
├── Valid From:    2026-01-01
├── Valid Until:   2026-04-01
├── Serial:        04:a3:b2:c1:d5:e6...
├── Extensions:
│   ├── Subject Alternative Names: bestwordz.com, www.bestwordz.com
│   ├── Key Usage: Digital Signature, Key Encipherment
│   └── Basic Constraints: CA:FALSE
└── Signature:     SHA-256 with RSA (by issuer)

Inspect any certificate: Use the Certificate Decoder to paste any PEM certificate and see all its fields. Or use the X.509 Certificate Viewer for detailed inspection.

How Certificate Verification Works

When your browser receives a server certificate, it performs these checks:

1. Chain validation: Is the certificate signed by a trusted intermediate CA? Is that intermediate signed by a trusted root CA?
2. Validity dates: Is the current date between the "Not Before" and "Not After" dates?
3. Domain match: Does the certificate's Subject Alternative Name (SAN) match the domain you're visiting?
4. Revocation check: Has the certificate been revoked? (CRL or OCSP)
5. Key usage: Is the certificate authorized for TLS server authentication?

If any check fails, the browser shows a security warning and refuses to connect.

Symmetric vs Asymmetric Keys in TLS

TLS uses both types of cryptography, each for a different purpose:

Try it: Use the Symmetric vs Asymmetric Demo to see why TLS uses asymmetric crypto for key exchange but symmetric crypto for bulk data. Generate keys with the RSA Key Pair Generator or ECDSA Key Generator.

Certificate Authorities (CAs)

A Certificate Authority is an organization trusted by operating systems and browsers to sign certificates. The major CAs include:

You can verify any SSL certificate with the SSL Certificate Checker. Check expiry with the Certificate Expiry Checker.

TLS 1.2 vs TLS 1.3

TLS 1.3 (2018) made significant improvements over TLS 1.2 (2008):

Try RSA encryption: Use the RSA-OAEP Encrypt tool to see why RSA key exchange was removed — it doesn't provide forward secrecy.

Forward Secrecy Explained

Forward secrecy (also called perfect forward secrecy or PFS) ensures that even if a server's private key is compromised in the future, past sessions cannot be decrypted.

Common TLS Configurations

# Nginx TLS configuration (modern)
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 on;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_stapling on;
ssl_stapling_verify on;

# Security headers
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Analyze headers: Use the Security Headers Analyzer to check your site's security headers. Generate HSTS with the HSTS Header Generator. Build a CSP with the CSP Builder.

Debugging TLS Issues

Common TLS problems and how to diagnose them:

Inspect certificates: Use the Certificate Inspector for detailed analysis, the Certificate Fingerprint tool to compute SHA-256 fingerprints, and the URL Security Analyzer to check any URL's TLS configuration.

Certificate Management Tools

Working with certificates in development or production? These tools help:

Certificate Inspection

• Certificate Decoder — Decode any PEM certificate and see all fields
• X.509 Certificate Viewer — Detailed certificate inspection
• Certificate Inspector — Analyze certificate chain and trust
• Certificate Expiry Checker — Check when certificates expire
• Certificate Fingerprint — Compute SHA-256 fingerprints
• SSL Certificate Checker — Verify any SSL certificate

Key Generation

• RSA Key Pair Generator — Generate RSA public/private keys
• ECDSA Key Generator — Generate elliptic curve keys
• AES Key Generator — Generate symmetric encryption keys

Certificate Format Conversion

• PEM Decoder — Decode PEM-encoded certificates and keys
• PEM Encoder — Encode data to PEM format
• PEM to DER — Convert PEM to DER binary format
• DER to PEM — Convert DER to PEM text format
• CSR Generator — Create Certificate Signing Requests
• CSR Decoder — Decode Certificate Signing Requests

Key Exchange & Signatures

• Diffie-Hellman Demo — See key exchange in action
• Diffie-Hellman Visual — Visual key exchange simulation
• ECDH Key Agreement — Elliptic curve key exchange
• Digital Signature Demo — See how certificates are signed
• RSA-PSS Sign — Create RSA signatures
• RSA-PSS Verify — Verify RSA signatures
• ECDSA Sign — Create ECDSA signatures
• ECDSA Verify — Verify ECDSA signatures

TLS Security Checklist

Conclusion

HTTPS is not a single technology — it is a carefully orchestrated sequence of cryptographic operations. The TLS handshake negotiates algorithms, exchanges keys via ECDHE, authenticates the server via X.509 certificates, and derives symmetric session keys — all in about 100 milliseconds.

Understanding this process helps developers debug certificate issues, configure secure servers, choose the right certificate type, and build applications that protect user data by default. The padlock icon represents an enormous amount of engineering — now you know what's behind it.