SSL/TLS Certificates Explained: How HTTPS Actually Works

The Problem HTTPS Solves

Before HTTPS, when you submitted a login form on a website, your username and password traveled across the internet as plain text. Any router, ISP, or attacker on the network path between your browser and the server could read, copy, or modify that data. This is not a theoretical threat - it was exploited routinely on public Wi-Fi networks with trivially simple tools.

HTTPS solves three distinct problems at once:

• Confidentiality: Data is encrypted in transit. Nobody on the network path can read the content of requests or responses.
• Integrity: Data cannot be tampered with in transit without detection. An attacker cannot modify the HTML your browser receives without breaking the cryptographic signature.
• Authentication: The certificate proves the server is really who it claims to be. You know you are talking to the real bank.com, not an impostor on the same Wi-Fi network.

TLS certificates are the mechanism that makes all three possible.

SSL vs TLS: Clearing Up the Terminology

SSL (Secure Sockets Layer) is the original protocol developed by Netscape in 1995. SSL 2.0 and 3.0 both had serious vulnerabilities and have been deprecated and disabled everywhere since 2015. TLS (Transport Layer Security) is the successor, with TLS 1.3 being the current standard. The version history:

• SSL 2.0 / 3.0: Deprecated. Disabled in all modern software. Do not enable.
• TLS 1.0 / 1.1: Deprecated in 2021 (RFC 8996). Chrome, Firefox, and Safari all block these. Do not enable.
• TLS 1.2: Still widely supported and secure when configured correctly.
• TLS 1.3: Current standard. Faster (1-RTT handshake), more secure, removes legacy cipher suites. All modern browsers support it.

When people say "SSL certificate" in 2026, they always mean a TLS certificate. The terms are used interchangeably in industry even though SSL itself is dead. When people say "SSL is expired," they mean the TLS certificate has passed its validity period.

What Is Inside a TLS Certificate

A TLS certificate is a digitally signed document containing:

• Subject: The domain name(s) the certificate is issued for (Common Name and Subject Alternative Names)
• Public key: The server's public key (used during the handshake for key exchange)
• Issuer: The Certificate Authority (CA) that signed and vouches for this certificate
• Validity period: Not Before and Not After dates. Let's Encrypt issues 90-day certificates; commercial CAs typically issue 1-year certificates (browsers now cap trust at 398 days).
• Serial number: Unique identifier used for revocation lookups
• Signature algorithm: How the CA signed the certificate (e.g., SHA-256 with RSA or ECDSA)

You can inspect any certificate in your browser by clicking the padlock icon, or decode it instantly with our Certificate Decoder.

The TLS 1.3 Handshake: Step by Step

When your browser navigates to an HTTPS URL, the following sequence happens in milliseconds before any HTTP data is exchanged:

1. DNS resolution: The browser resolves the domain to an IP address.
2. TCP connection: A standard TCP three-way handshake establishes a connection on port 443.
3. Client Hello: The browser sends its supported TLS versions, supported cipher suites, and a key share (in TLS 1.3, the client sends a key share guess in the first message to save a round trip).
4. Server Hello: The server selects the TLS version and cipher suite, sends its key share, and includes its certificate chain. In TLS 1.3 this is all encrypted after the key shares are exchanged.
5. Certificate verification: The browser validates the certificate chain: checks the CA signature, verifies the domain matches, confirms the certificate has not expired, and checks the revocation status (via OCSP or CRL).
6. Key derivation: Both sides independently derive the same symmetric session key from the exchanged key shares using Diffie-Hellman key exchange. Neither side ever transmits the session key - it is computed independently on both ends. This is what provides forward secrecy.
7. Encrypted application data: All HTTP requests and responses from this point are encrypted with the session key using AES GCM or ChaCha20-Poly1305.

TLS 1.3 completes in one round trip (1-RTT), compared to two in TLS 1.2. For returning connections, TLS 1.3 supports 0-RTT resumption where the client sends application data with the first message, making HTTPS connection overhead near-zero.

Certificate Types: Which One Do You Need

Domain Validated (DV)

The CA verifies only that you control the domain - either by placing a file at a specific URL (HTTP-01 challenge) or by creating a DNS TXT record (DNS-01 challenge). Validation is automated and takes seconds. This is what Let's Encrypt issues. DV certificates are free, auto-renewable, and sufficient for the vast majority of websites. They show a padlock in browsers but display no organization information.

Organization Validated (OV)

The CA verifies domain control plus the organization's legal identity by checking business registry records. OV certificates include the organization name in the certificate's Subject field. Browsers do not prominently display this information, but it is visible to users who inspect the certificate. OV certificates cost $50–$200/year and take 1–3 business days to issue.

Extended Validation (EV)

The most rigorous validation: legal identity, physical address, operational existence, and right to use the domain are all verified. EV certificates historically showed a green address bar with the company name in browsers, but Chrome removed the visual distinction in 2019 and other browsers followed. Given their high cost ($200–$1000/year) and minimal user-facing benefit, EV certificates are hard to justify for most applications in 2026.

Wildcard Certificates

A wildcard certificate (*.example.com) covers all immediate subdomains: www.example.com, api.example.com, mail.example.com, etc. Important caveats:

• It does not cover the bare domain (example.com itself) - you need to list both *.example.com and example.com as Subject Alternative Names.
• It does not cover second-level wildcards (api.v2.example.com).
• Let's Encrypt issues wildcard certificates for free but requires DNS-01 challenge validation.

Multi-Domain (SAN) Certificates

A single certificate covering multiple distinct domains via Subject Alternative Names (SANs): example.com, example.io, example.co.uk. Useful for organizations managing multiple domains without paying for separate certificates for each.

Certificate Chains and the Web of Trust

Your browser does not directly trust your website's certificate. It trusts a set of root certificates that are pre-installed in the operating system and browser. Root CAs (like DigiCert, Sectigo, GlobalSign) use these root certificates to sign intermediate certificates, which in turn sign your website's certificate.

Chain of Trust:
Root CA (trusted by your browser's built-in store)
  └── Intermediate CA (signed by Root CA)
        └── Your Certificate (signed by Intermediate CA, covers your domain)

This chain structure means root CA private keys can be kept in highly secure, offline hardware security modules, with the intermediate CA doing day-to-day certificate signing. If an intermediate CA is compromised, it can be revoked without replacing the root.

When you configure your web server, you must include the full certificate chain (your certificate plus all intermediate certificates). If you omit the intermediate certificates, mobile devices and clients without cached intermediates will show a certificate error. Use our SSL Checker to verify your chain is complete.

Let's Encrypt and ACME Automation

Let's Encrypt changed the economics of HTTPS by making DV certificates free and fully automated via the ACME protocol. Key facts for 2026:

• Certificates are valid for 90 days (shorter validity encourages automation and limits the window if a key is compromised).
• The most common ACME client is Certbot, maintained by EFF. Install once, runs via cron, handles renewal automatically.
• Supports wildcard certificates via DNS-01 challenge (requires API access to your DNS provider).
• Let's Encrypt has issued over 500 million active certificates globally as of 2026.
• Rate limits apply: 50 certificates per registered domain per week. Use the staging environment for testing.

# Install and obtain a certificate with Certbot (Apache)
sudo certbot --apache -d example.com -d www.example.com

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

# Test automatic renewal
sudo certbot renew --dry-run

# Wildcard certificate (requires DNS plugin)
sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

Configuring Your Web Server for TLS

Getting a certificate is only half the job. Server configuration determines which TLS versions and cipher suites your server accepts. A poorly configured server may accept deprecated protocols even with a valid certificate.

# Nginx: recommended TLS configuration (2026)
server {
    listen 443 ssl;
    server_name example.com;

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

    # Only TLS 1.2 and 1.3
    ssl_protocols TLSv1.2 TLSv1.3;

    # Strong cipher suites with forward secrecy
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;  # let client pick in TLS 1.3

    # OCSP stapling: attach revocation proof to handshake (faster, no client DNS roundtrip)
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    # HSTS: tell browsers to always use HTTPS for this domain
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
}

# Redirect HTTP to HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Common SSL/TLS Mistakes That Cause Incidents

• Expired certificates: The most common cause of HTTPS outages. Set up automated renewal with certbot. Add monitoring alerts 30 days before expiry. Use our SSL Checker to verify expiry dates.
• Incomplete certificate chain: Your certificate is valid but the server does not send the intermediate certificates. Android devices often cannot download missing intermediates and show a trust error. Always include the full chain (fullchain.pem in Let's Encrypt, not cert.pem).
• Mixed content: Loading any HTTP resource on an HTTPS page. Browsers block mixed active content (scripts, iframes) and warn about passive content (images, fonts). Every asset URL must use HTTPS or be protocol-relative.
• Accepting TLS 1.0 or 1.1: Both are deprecated with known downgrade attacks. Remove them from your server configuration. Check with our SSL Checker.
• Weak cipher suites: Disable RC4, DES, 3DES, export-grade ciphers, and any cipher without Perfect Forward Secrecy (ECDHE or DHE key exchange). Use Mozilla's SSL Configuration Generator for up-to-date recommendations.
• Missing HSTS header: Without HSTS, a browser will attempt the first connection over HTTP before being redirected. A network attacker can intercept this first request. Add Strict-Transport-Security with a long max-age and submit to the HSTS preload list.
• Self-signed certificates in production: Self-signed certificates trigger browser warnings that train users to click through security alerts. Use Let's Encrypt for free trusted certificates even for internal tools.

Checking SSL Certificates from the Command Line

# Full certificate details
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -text -noout

# Check expiry date
echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -dates -noout

# Check the full certificate chain
openssl s_client -connect example.com:443 -showcerts 2>/dev/null

# Verify certificate matches a private key (hashes should match)
openssl x509 -noout -modulus -in cert.pem | md5sum
openssl rsa -noout -modulus -in privkey.pem | md5sum

# Check TLS version and cipher suite used
curl -vI https://example.com 2>&1 | grep -E "SSL|cipher|TLS"

Frequently Asked Questions

Does HTTPS encrypt the URL and domain name?

The domain name is partially visible. DNS lookups are not encrypted by default (use DNS-over-HTTPS to fix this), and the domain name is also sent in the TLS SNI (Server Name Indication) field of the handshake in plaintext so the server knows which certificate to present. The full URL path, query parameters, and all request/response content are encrypted. Your ISP can see that you visited example.com but not that you visited example.com/sensitive-page?user=alice.

What is the difference between a certificate and a private key?

The certificate is the public document - it contains your public key and is presented to every browser that connects to your server. The private key is the secret that must never leave your server. The two are mathematically linked: data encrypted with the public key can only be decrypted with the private key. During the TLS handshake, the server uses the private key to prove it possesses it (without revealing it) via a cryptographic signature. If your private key is compromised, you must revoke the certificate and generate a new key pair immediately.

How does Certificate Transparency work?

Certificate Transparency (CT) is a public, append-only log of every TLS certificate issued by trusted CAs. Browsers require that certificates be logged in CT before trusting them. This makes it impossible for a rogue CA to issue a certificate for your domain secretly - any such certificate would appear in the public log. You can monitor CT logs for certificates issued for your domains using services like crt.sh or Facebook's Certificate Transparency Monitoring.

What is HSTS and why does it matter?

HTTP Strict Transport Security (HSTS) is an HTTP response header that tells browsers to only connect to your site over HTTPS, never HTTP, for a specified duration. Without HSTS, even if you redirect HTTP to HTTPS, the browser makes an initial HTTP request that can be intercepted by an attacker on the network (a "SSL stripping" attack). With HSTS, the browser refuses to make any HTTP connection to your domain once it has seen the HSTS header. The HSTS Preload List takes this further: browsers come pre-loaded with domains that must always use HTTPS, even before the first visit.

What happens when a certificate is revoked?

If a private key is compromised, the certificate owner requests revocation from the CA. The CA adds the certificate's serial number to its Certificate Revocation List (CRL) and OCSP (Online Certificate Status Protocol) responder. When a browser sees the certificate, it checks OCSP to see if it has been revoked. OCSP Stapling improves this by having the server attach a fresh, CA-signed OCSP response to the TLS handshake, so browsers do not need to make a separate DNS lookup to the CA for every connection.

How long should TLS certificates be valid?

As of 2020, browsers cap trusted certificate validity at 398 days (~13 months). Apple Safari enforces this strictly. Let's Encrypt issues 90-day certificates and recommends automating renewal at 60 days. Shorter validity periods are better security practice because they limit the window of exposure if a private key is compromised. The trend is toward shorter certificates: proposals exist to reduce the maximum to 45 days in the next few years, relying entirely on automation for renewal.

The Bottom Line

HTTPS is non-negotiable in 2026 - for security, for user trust, and for Google ranking. The implementation path is straightforward: use Let's Encrypt for free DV certificates, automate renewal with certbot, configure TLS 1.2 and 1.3 with strong cipher suites, enable HSTS, and monitor your certificates proactively. The mistakes that cause outages are almost always the same: expired certificates, incomplete chains, or mismatched private keys.

Use our free tool here → SSL Checker - verify any domain's certificate, expiry, chain, and TLS configuration in seconds.