
Every time you log into your bank, buy something online, or even just read a blog post, a small padlock icon (or a similar connection icon, depending on the browser) sits next to the address bar. Most people know it's "good" and that its absence is "bad," but few can say what it actually does.
You've probably also seen three terms used almost interchangeably: SSL, TLS, and HTTPS. They are related, but they are not the same thing. This post untangles them, walks through what happens behind the scenes when you visit a secure site, and gives you a practical checklist for securing your own website.
The Short Version
SSL (Secure Sockets Layer) is the original security protocol for the web. It is obsolete and no longer considered safe.
TLS (Transport Layer Security) is SSL's modern successor. When people say "SSL" today, they almost always mean TLS.
HTTPS (HTTP Secure) is simply regular HTTP running on top of TLS. It's what you see in the URL when a connection is protected.
A useful way to remember it: TLS is the engine, HTTPS is the car. TLS does the encryption work, and HTTPS is the everyday protocol you use that relies on it.
Why We Need Any of This
When data travels from your browser to a website, it passes through many machines you don't control: your Wi-Fi router, your internet provider, and several networks in between. Plain HTTP sends everything in readable text, so anyone along that path could read or alter it.
TLS solves three distinct problems:
Confidentiality: Data is encrypted, so eavesdroppers see only scrambled bytes.
Integrity: Data can't be modified in transit without detection.
Authentication: You can verify that you're really talking to the site you intended, not an impostor.
That third point is easy to overlook, but it's critical. Encryption with the wrong party is worthless. Certificates, which we'll cover shortly, are how TLS proves identity.
A Brief History: From SSL to TLS
SSL was developed by Netscape in the mid-1990s. Security researchers found serious flaws in each early version, and the protocol was eventually replaced and renamed TLS. Here's how the timeline looks:
Protocol | Introduced | Status |
|---|---|---|
SSL 2.0 | 1995 | Broken and prohibited |
SSL 3.0 | 1996 | Broken (the POODLE attack, 2014) and prohibited |
TLS 1.0 | 1999 | Deprecated |
TLS 1.1 | 2006 | Deprecated |
TLS 1.2 | 2008 | Still widely used and considered secure when configured well |
TLS 1.3 | 2018 | Current standard: faster and more secure |
The name "SSL certificate" stuck around out of habit, which is why hosting companies still sell "SSL certificates" that are really used for TLS. It's a naming leftover, not a technical truth.
What Is HTTPS?
HTTP is the language browsers and servers use to exchange web pages. On its own, it's unencrypted. HTTPS is HTTP delivered through a TLS-encrypted tunnel, typically over port 443 instead of port 80.
The HTTP requests and responses themselves don't change. TLS simply wraps them in a protective layer, so the page you request, the form data you submit, the cookies and headers, and the content that comes back are all hidden from anyone watching the network.
How Does HTTPS Work?
HTTPS first builds an encrypted, authenticated channel to the server using TLS, then sends ordinary HTTP requests and responses through it. Here is the full journey from typing a URL to seeing a page:
You enter a URL. You type
https://example.comor click a link. Thehttpsscheme tells your browser to use a secure connection, on port 443 by default. If you typed plainhttp://, the site (or your browser, via HSTS) redirects you to the HTTPS version.DNS lookup. Your browser asks a DNS server to translate
example.cominto an IP address. This happens before encryption starts, so the domain name is normally visible to the network unless you use encrypted DNS.Connection setup. Your browser opens a connection to that IP address on port 443. (HTTP/3 does this over QUIC instead, which has TLS 1.3 built in.)
TLS handshake. Browser and server agree on encryption settings, the server presents its certificate, and both sides derive the same secret session keys. The next section walks through this step in detail.
Certificate check. Your browser confirms the certificate chains up to a trusted authority, matches the domain, and hasn't expired. If anything fails, it shows a warning page and stops before any page data is sent.
Encrypted request. Your browser sends its HTTP request (the page path, headers, and cookies) encrypted with the session key. Nobody on the network can read it or change it unnoticed.
Encrypted response. The server replies with the page, also encrypted. Your browser decrypts it, checks that it wasn't altered, and renders it.
Connection reuse. The same secure connection carries the page's images, scripts, and later requests. On a return visit, TLS session resumption lets the browser skip part of the handshake.
How a TLS Connection Works
TLS uses two kinds of cryptography together:
Asymmetric (public-key) cryptography is used at the start. It lets two parties who have never met agree on a secret safely, but it's relatively slow.
Symmetric cryptography is used for the rest of the session. It's very fast, but both sides need the same secret key.
The clever part of TLS is using the slow method just long enough to establish a shared key, then switching to the fast one. This setup phase is called the handshake. Here's a simplified version of the TLS 1.3 handshake:
Client Hello: Your browser says hello, lists the TLS versions and cipher suites it supports, and sends its half of a key exchange.
Server Hello: The server picks a cipher suite and sends back its half of the key exchange.
Certificate: The server presents its digital certificate to prove its identity.
Verification: Your browser checks that the certificate is valid, unexpired, issued for this exact domain, and signed by a trusted authority.
Shared secret: Both sides independently compute the same session keys from the key exchange. The secret itself is never sent over the wire.
Finished: Each side confirms the handshake wasn't tampered with, and encrypted communication begins.
In TLS 1.3 this takes just one round trip between browser and server, which is one reason modern HTTPS is often just as fast as old-fashioned HTTP.
Modern TLS also provides forward secrecy: even if a server's private key were stolen in the future, past recorded traffic can't be decrypted, because each session used its own temporary keys.
Certificates and the Chain of Trust
How does your browser know a certificate is genuine? Anyone can claim to be your bank, after all.
A TLS certificate is a digital document that binds a domain name to a public key. It's signed by a Certificate Authority (CA), an organization your device already trusts. Your operating system and browser ship with a built-in list of trusted root certificates.
The trust works as a chain:
Root CA: Pre-installed and trusted by your device.
Intermediate CA: Signed by the root, and does the day-to-day signing so the root can be kept safely offline.
Leaf certificate: Issued to the website, signed by an intermediate.
Your browser follows the chain from the site's certificate up to a trusted root. If any link is missing, expired, or invalid, you get a warning page.
A certificate typically contains the domain name(s) it covers, the organization it was issued to (for some types), the issuer, the validity dates, and the site's public key.
Types of Certificates
Domain Validated (DV): Proves control of a domain. Fast, cheap, and often free. This is enough for most sites and blogs.
Organization Validated (OV): Also verifies the legal organization behind the site.
Extended Validation (EV): The most rigorous vetting. Browsers no longer show special visual treatment for EV, so its practical value has shrunk.
All three provide the same level of encryption. The difference is how much identity checking the CA performed.
What the Padlock Does (and Doesn't) Tell You
This is the biggest misconception about HTTPS. The padlock means your connection to the site is encrypted and the site's domain matches its certificate. It does not mean the site is trustworthy.
Phishing sites routinely use HTTPS, because getting a free DV certificate is easy. A secure connection to a malicious site is still a connection to a malicious site. Always check the actual domain name, not just the lock.
HTTPS also doesn't hide everything. Observers can often still see which domain you're visiting (through DNS lookups and the server name sent in the handshake) and roughly how much data you transfer. What they can't see is the specific pages, content, or credentials.
Common HTTPS Errors and What They Mean
Certificate expired: The certificate's validity period has ended. Almost always a renewal that was forgotten or failed.
Name mismatch: The certificate was issued for a different domain than the one you visited (for example, it covers
example.combut notwww.example.com).Untrusted issuer: The certificate was signed by an authority your browser doesn't trust, or it's self-signed.
Incomplete chain: The server isn't sending its intermediate certificate.
Mixed content: The page loads over HTTPS, but some images, scripts, or stylesheets are still requested over plain HTTP. Browsers block or warn about these.
How to Secure Your Own Website
Getting HTTPS running is easier than it has ever been.
1. Get a certificate
The easiest route is a free, automated CA such as Let's Encrypt. Many hosting providers and platforms enable it with one click. If you manage your own server, a tool like Certbot automates issuance and renewal:
sudo certbot --nginx -d example.com -d www.example.com2. Automate renewal
The industry is steadily moving toward shorter certificate lifetimes, which limits the damage from a compromised key. That makes automatic renewal essential. Manual renewals are how sites end up with expired-certificate outages.
3. Redirect HTTP to HTTPS
Make sure visitors who type or follow an http:// link end up on the secure version. In Nginx, for example:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}4. Enable HSTS
HTTP Strict Transport Security tells browsers to only use HTTPS for your site in the future, closing the window for downgrade attacks:
Strict-Transport-Security: max-age=31536000; includeSubDomainsTest your setup carefully before enabling it for long durations, since it's hard to undo once browsers have cached it.
5. Use modern TLS settings
Support TLS 1.2 and 1.3 only, and disable SSL and older TLS versions. Tools like Qualys SSL Labs' server test will grade your configuration and point out weaknesses.
6. Fix mixed content
Audit your pages so every image, script, font, and embed loads over HTTPS. Using relative or https:// URLs throughout avoids most problems.
Why HTTPS Is Worth It Beyond Security
User trust: Browsers label plain HTTP sites as "Not secure," which scares visitors away.
Search visibility: Google has used HTTPS as a lightweight ranking signal for years.
Modern features: Many browser capabilities, such as geolocation, service workers, and HTTP/2 in practice, require a secure connection.
Data integrity: Even a static blog benefits, because HTTPS prevents ISPs and network operators from injecting ads or modifying your pages.
Key Takeaways
SSL is the old name; TLS is what's actually in use today. "SSL certificate" is just a lingering term.
HTTPS = HTTP + TLS. It protects the confidentiality and integrity of data between browser and server.
The handshake uses public-key cryptography to agree on a shared key, then switches to fast symmetric encryption.
Certificates and CAs are how browsers verify a site's identity.
The padlock means "encrypted and correctly addressed," not "safe to trust."
Securing your site is cheap and automatable. There's little reason not to do it.
Conclusion
SSL, TLS, and HTTPS aren't three competing technologies. They're chapters of one story: how the web learned to keep conversations private and verify who's on the other end. SSL was the first draft, TLS is the refined and hardened version, and HTTPS is how you experience it every day.
If you run a website, make sure it's served over HTTPS with modern TLS and automated renewals. If you're just a visitor, appreciate the padlock, but keep reading the address bar.
Comments(0)
Join the discussion by logging into your account.
No comments yet. Be the first to comment!