What SSL Was
SSL — Secure Sockets Layer — was the original protocol for encrypting web traffic. Developed by Netscape in the mid-1990s, it solved a real and urgent problem: how to send credit card numbers and passwords over the internet without anyone being able to read them in transit.
The core idea was sound. SSL created an encrypted channel between a client (like a browser) and a server, authenticated the server’s identity using certificates, and protected data from interception. It was transformative for e-commerce and online banking at a time when most internet traffic was completely unprotected.
The name persists in everyday language — people still say “SSL certificate,” “SSL connection,” and “SSL encryption” — but the protocol itself has been retired. Every connection described as “SSL” today is actually TLS (Transport Layer Security), the successor that replaced SSL versions 1.0 through 3.0.
The SSL Version History
SSL / TLS Timeline
1995 SSL 2.0 — First public release (Netscape) Critical vulnerabilities discovered quickly
1996 SSL 3.0 — Redesigned from scratch Widely deployed for ~15 years POODLE attack (2014) broke it
1999 TLS 1.0 — SSL 3.0 successor, renamed Minor improvements over SSL 3.0 Deprecated by PCI-DSS 3.1 (2015)
2006 TLS 1.1 — Added protection against CBC attacks Deprecated 2020, disabled in major browsers
2008 TLS 1.2 — Introduced SHA-256, GCM, ECDHE Still widely used, considered secure with correct configuration
2018 TLS 1.3 — Major overhaul, removed legacy cipher suites 1-RTT handshake, mandatory forward secrecy Current recommended standardSSL 3.0 was disabled across the industry after the POODLE vulnerability (2014), which allowed attackers to decrypt session cookies from SSL 3.0 connections using a padding oracle attack. By the late 2010s, SSL 2.0 and 3.0 were both fully deprecated across all major platforms.
How SSL/TLS Authentication Works
The authentication part of the protocol — proving you’re actually connected to the site you think you are — depends on digital certificates and a chain of trust.
Certificates: A certificate is a file that binds a public key to an identity. It says: “this public key belongs to example.com.” The certificate is signed by a Certificate Authority (CA) — a trusted third party that has verified the identity of the domain owner.
Certificate Authorities: CAs are organizations trusted by browser vendors (Google, Mozilla, Apple, Microsoft) to verify identities and issue certificates. When a browser connects to a site, it checks that the certificate is signed by a CA it trusts. If you connect to a site with a self-signed certificate (signed by itself, not a trusted CA), your browser shows a warning.
Certificate Chain of Trust
[ Root CA ] Self-signed, distributed with browsers/OS Example: DigiCert Global Root CA | | issued certificate to v [ Intermediate CA ] Signed by Root CA Example: DigiCert TLS Hybrid ECC SHA384 2020 CA1 | | issued certificate to v [ End-Entity Certificate ] The certificate on your website Contains: domain, public key, validity, CA signature
Browser verifies: is the Root CA in my trusted store? If yes: connection is trustedThe root CA is rarely used directly because a compromise of the root CA would be catastrophic. Instead, intermediate CAs issue the actual certificates, and the intermediate is signed by the root.
Certificate Types: What the Validation Level Means
Certificates differ in how thoroughly the CA has verified the identity of the applicant.
Domain Validated (DV) The CA only verifies that the certificate applicant controls the domain name. This can happen in minutes through automated challenge-response (Let’s Encrypt uses this). DV certificates show the padlock icon in browsers but no organization information.
Use when: any website that needs HTTPS. Let’s Encrypt makes these free and automated.
Organization Validated (OV) The CA verifies the domain and also the legal existence of the organization. Takes 1-3 days. The organization name is included in the certificate details.
Use when: business websites, APIs where partners want to see the organization name in the certificate.
Extended Validation (EV) The CA performs extensive verification of the organization’s identity, jurisdiction, and legal standing. Used to show the company name in the browser address bar (the “green bar”). This display was removed from most browsers in 2019 when research showed users paid little attention to it.
Use when: high-value financial transactions, enterprise applications where EV validation is a contractual requirement.
Wildcard Certificates
A certificate that covers a domain and all its immediate subdomains: *.example.com covers www.example.com, api.example.com, mail.example.com, etc. Cheaper than buying individual certs for each subdomain, but a compromise of the certificate affects all subdomains.
Multi-Domain (SAN) Certificates A single certificate covering multiple distinct domains using Subject Alternative Names. Convenient for organizations managing several related properties.
The SSL Handshake: What Happens When You Connect
When a browser navigates to an HTTPS URL, a handshake negotiates the encrypted connection before any application data flows. Here’s what happens in TLS 1.2 (still widely used):
TLS 1.2 Handshake
Browser Server | | |──── 1. ClientHello ─────────────────────> | | TLS version, cipher suites, | | random bytes | | | | <──── 2. ServerHello ─────────────────────| | Chosen cipher suite, random bytes | | | | <──── 3. Certificate ─────────────────────| | Server's cert (public key + identity)| | | | <──── 4. ServerHelloDone ─────────────────| | | | 5. Browser verifies the certificate | | against trusted CA list | | | |──── 6. ClientKeyExchange ───────────────> | | Pre-master secret encrypted with | | server's public key | | | | 7. Both sides derive the same session key | | from the pre-master secret and randoms | | | |──── 8. ChangeCipherSpec + Finished ──────> | | <──── 9. ChangeCipherSpec + Finished ─────| | | |======= Encrypted Application Data ==========|TLS 1.3 simplified this to a single round-trip by combining steps and eliminating the RSA key exchange (step 6 above). In TLS 1.3, the client sends its key share in the very first message, so the server can derive the session key and start encrypting from its first response.
HTTPS: SSL/TLS Applied to HTTP
HTTPS is simply HTTP (the web protocol) running over a TLS connection. The “S” stands for Secure. When you see https:// in a URL, the browser:
- Resolves the domain name to an IP address (DNS)
- Opens a TCP connection to port 443 (the standard HTTPS port)
- Performs the TLS handshake (authenticating the server, agreeing on encryption)
- Sends HTTP requests over the now-encrypted connection
Port 80 is HTTP (unencrypted). Port 443 is HTTPS. Any modern site should redirect HTTP traffic to HTTPS using a 301 redirect, so no one accidentally accesses the unencrypted version.
Why “SSL Certificates” Are Really TLS Certificates
The term “SSL certificate” is purely historical. The certificate format itself — X.509 — hasn’t changed significantly. A certificate issued today works with TLS 1.2 and 1.3 in exactly the same way it would have worked with SSL 3.0. The certificate is just a container for a public key and identity information. The protocol version (SSL or TLS) determines how the handshake works, not the certificate.
When a hosting provider says “install your SSL certificate,” they mean “install your TLS certificate.” When Let’s Encrypt issues a certificate in 2025, it’s a valid TLS certificate that will never negotiate SSL.
Let’s Encrypt: Free, Automated Certificates
Let’s Encrypt (launched 2016, backed by the Linux Foundation and major tech companies) provides free DV certificates via an automated API (the ACME protocol). It has encrypted a significant portion of web traffic that previously used no encryption due to cost and complexity.
# Install certbot and obtain a certificatesudo apt install certbot python3-certbot-nginxsudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
# Certificates auto-renew via a systemd timer or cron jobsudo certbot renew --dry-runCertificates are valid for 90 days and renew automatically. The short validity period limits exposure if a certificate is ever compromised — you don’t need to manually revoke it, it expires quickly anyway.
Certificate Revocation
When a private key is compromised, the certificate needs to be revoked before expiry. Two mechanisms exist:
CRL (Certificate Revocation List): A periodically updated list of revoked certificates published by the CA. Browsers download it to check revocation status. Slow to update and can be large.
OCSP (Online Certificate Status Protocol): Real-time lookup of revocation status for a specific certificate. Faster but requires a live request to the CA’s OCSP server on every connection.
OCSP Stapling: The server fetches its own OCSP response and includes it in the TLS handshake, eliminating the client’s need to contact the CA server separately. Both faster and more private.
Modern practice is moving toward shorter certificate lifetimes (the industry is pushing toward 47-day max certificates as of 2024-2025) rather than relying on revocation, since shorter lifetimes make revocation less critical.
Practical SSL/TLS Checklist for Website Operators
TLS Configuration Checklist
[ ] Certificate from trusted CA (Let's Encrypt is fine) [ ] TLS 1.2 minimum enforced, TLS 1.3 enabled [ ] SSL 2.0, 3.0, TLS 1.0, TLS 1.1 disabled [ ] Weak cipher suites disabled (RC4, DES, 3DES, export ciphers) [ ] ECDHE cipher suites enabled for forward secrecy [ ] HSTS header enabled (min 6 months, preferably 1 year) [ ] HTTP to HTTPS redirect in place [ ] Certificate expiry monitored with automated alerts [ ] Automatic certificate renewal configured [ ] Server tested on ssllabs.com/ssltest (aim for A or A+)SSL is history. TLS is what you’re running. The concepts — certificates, certificate authorities, encrypted handshakes — are the same. The implementation is stronger, faster, and more secure than anything that carried the “SSL” name. The task now is making sure your configuration reflects that.