SSL/TLS Certificates Explained: How HTTPS Actually Works

SSL vs TLS: Clearing Up the Terminology

SSL (Secure Sockets Layer) is the original protocol created by Netscape in the 1990s. It has been deprecated since 2015 due to known vulnerabilities. TLS (Transport Layer Security) is the successor, with TLS 1.3 being the current standard as of 2026. When people say "SSL certificate," they almost always mean a TLS certificate. The terms are used interchangeably in practice, even though SSL itself is dead.

What Does a TLS Certificate Do?

A TLS certificate serves three purposes:

1. Authentication: It proves that the server you are connecting to is actually who it claims to be (e.g., really google.com, not an impostor).
2. Encryption: It enables the TLS handshake that establishes an encrypted channel between your browser and the server.
3. Integrity: It ensures that data has not been modified in transit between the client and server.

The TLS 1.3 Handshake (Simplified)

When your browser connects to an HTTPS website, the following happens in milliseconds:

1. Client Hello: Your browser sends supported cipher suites and a random number.
2. Server Hello: The server picks a cipher suite, sends its certificate and a random number. In TLS 1.3, the server also sends its key share in this message (one fewer round trip than TLS 1.2).
3. Certificate verification: Your browser checks the certificate against its trusted Certificate Authority (CA) store, verifies the domain name matches, and checks that the certificate has not expired or been revoked.
4. Key exchange: Both sides derive the same session key using the exchanged key shares (ECDHE in TLS 1.3). This session key encrypts all subsequent traffic.
5. Encrypted communication: All HTTP requests and responses are now encrypted with the session key.

TLS 1.3 completes the handshake in just one round trip (1-RTT), compared to two round trips in TLS 1.2. It also supports 0-RTT resumption for returning connections, making HTTPS faster than ever.

Certificate Types

Domain Validated (DV)

The CA verifies that you control the domain (via DNS record or HTTP challenge). This is what Let's Encrypt issues. It is free, automated, and sufficient for most websites. DV certificates show a padlock in the browser but no organization name.

Organization Validated (OV)

The CA verifies domain ownership plus the organization's legal identity. OV certificates include the organization name in the certificate details but browsers do not display it prominently. They cost $50-$200/year.

Extended Validation (EV)

The most rigorous validation: legal identity, physical address, and operational existence. EV certificates used to show a green bar with the company name, but most browsers have removed this visual distinction. Given the cost ($200-$1000/year) and minimal UX benefit, EV is increasingly hard to justify for most sites.

Wildcard Certificates

A wildcard certificate covers all subdomains of a domain: *.example.com covers www.example.com, api.example.com, mail.example.com, etc. It does not cover example.com itself (you need to include both the bare domain and wildcard as SANs).

Certificate Chains and Trust

When a CA issues your certificate, it signs it with an intermediate certificate, which in turn is signed by a root certificate. Root certificates are pre-installed in your browser and operating system. This creates a chain of trust:

Your Certificate → Intermediate CA → Root CA (trusted by browser)

If you forget to include intermediate certificates in your server configuration, some browsers will fail to validate the chain. Use our SSL Checker to verify your certificate chain is complete and correctly configured.

Let's Encrypt and ACME

Let's Encrypt revolutionized SSL by making DV certificates free and fully automated via the ACME protocol. Key facts for 2026:

• Certificates are valid for 90 days (encourages automation via certbot or other ACME clients).
• Supports wildcard certificates via DNS-01 challenge.
• Issues over 400 million active certificates globally.
• Use certbot renew --dry-run to test renewal before it matters.

Common SSL/TLS Mistakes

• Mixed content: Loading HTTP resources on an HTTPS page. Browsers block mixed active content and warn about passive content. Check with browser DevTools or our SSL Checker.
• Expired certificates: Set up automated renewal. Let's Encrypt + certbot handles this. Monitor expiry dates proactively.
• Incomplete certificate chain: Always include intermediate certificates. Test with openssl s_client -connect example.com:443 -showcerts.
• Using SSL 3.0 or TLS 1.0/1.1: These are deprecated. Disable them in your web server config. Only enable TLS 1.2 and 1.3.
• Weak cipher suites: Disable RC4, DES, 3DES, and any cipher without forward secrecy. Use Mozilla's SSL Configuration Generator for recommended settings.
• Not redirecting HTTP to HTTPS: Always set up a 301 redirect and enable HSTS (HTTP Strict Transport Security).

Checking SSL Certificates

You can inspect any website's SSL certificate using several methods:

# OpenSSL command line
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -text -noout

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

# curl with certificate details
curl -vI https://example.com 2>&1 | grep -A6 "Server certificate"

Or use our online SSL Checker for a visual, comprehensive analysis without installing anything. You can also use DNS Lookup to verify your domain's DNS records and Whois Lookup to check domain registration details.

The Bottom Line

HTTPS is non-negotiable in 2026. Use Let's Encrypt for free DV certificates, automate renewal with certbot, configure TLS 1.3 with strong cipher suites, and regularly verify your setup with an SSL checker. Your users and Google's ranking algorithm will thank you.

Explore more security and DevOps tools: Hash Generator, Password Generator, DNS Lookup, and 50+ more free tools.