If you’ve ever seen a padlock in the browser bar and wondered what “SSL,” “TLS,” and “HTTPS” actually refer to, you’re looking at three names for mostly the same thing. SSL is a deprecated protocol from the 1990s; TLS is the modern replacement; HTTPS is HTTP running over TLS. The terms have different histories but in practice they point at the same padlock.
What each term actually means
SSL (Secure Sockets Layer) was developed by Netscape to encrypt web traffic. TLS (Transport Layer Security) replaced it, and today’s web runs on TLS 1.2 and TLS 1.3. SSL 3.0 was deprecated in 2015; TLS 1.0 and 1.1 followed in 2021. The word “SSL” persists because hosting panels and certificate vendors latched onto it before TLS gained traction, and marketing rarely retreats once a term sticks.
HTTPS is not a separate protocol. It is HTTP with a TLS layer underneath. When a browser connects to https://example.com, it opens a TLS connection, negotiates encryption, and then sends the HTTP request inside the encrypted tunnel. The padlock in the address bar signals that wrapping is in place.
One practical upshot: when someone asks for an “SSL certificate,” they mean a TLS certificate. The certificate is a signed document that identifies a server; the protocol version is negotiated at connection time, separately. Nobody sells actual SSL certificates in 2026 because SSL no longer runs, but the name on the product hasn’t changed.
How the TLS handshake works
TLS establishes a shared encryption key before any page data moves. In TLS 1.3 this takes a single round-trip; in TLS 1.2, two.
At a high level:
- Client hello. The browser announces the TLS versions and cipher suites it supports.
- Server hello. The server picks a cipher suite and sends its certificate.
- Certificate check. The browser verifies the certificate against a list of trusted Certificate Authorities (CAs) built into the OS or browser. It checks the signature, the domain match, and the expiry date.
- Key exchange. Using elliptic-curve Diffie-Hellman, both sides independently derive the same session key without ever sending it across the wire. Everything after this point is symmetrically encrypted with that key.
The asymmetric key exchange is computationally expensive but happens once per session. The symmetric encryption that follows is fast. That split is why TLS can secure high-bandwidth connections without measurable latency overhead in normal use.
TLS 1.3 cut handshake latency roughly in half compared to TLS 1.2 and removed support for cipher suites with known weaknesses. If your server still negotiates 1.2 with legacy ciphers, you have traded security for nothing in particular.
What a certificate actually does
A certificate binds a domain name to a public key, and is signed by a CA that browsers trust. The browser checks the chain: the CA’s signature must trace back to a root certificate it already trusts. A broken chain or an unknown CA triggers a hard browser warning that blocks the page.
Three certificate types matter in practice:
- DV (Domain Validated): The CA confirms you control the domain. Automated, instant, and free via Let’s Encrypt. Sufficient for the vast majority of sites.
- OV (Organization Validated): The CA also checks that a real legal entity controls the domain. Useful for B2B or financial products where visitors inspect certificate details.
- EV (Extended Validated): Rigorous manual vetting of the organization. Browsers used to display a green company name bar for EV; they dropped that in 2019. The practical gap over OV is now narrow.
One detail that trips teams up: wildcard scope. A certificate issued for example.com does not cover www.example.com unless the subdomain is listed as a Subject Alternative Name, or the certificate is a wildcard (*.example.com). Missing this is one of the most common causes of a browser warning on a site that supposedly “has HTTPS.”
Let’s Encrypt automated DV issuance through the ACME protocol, and certificate renewal can (and should) run automatically. The old argument that HTTPS was expensive or complicated expired with that project.
What HTTPS actually changes
HTTPS delivers three things that plain HTTP doesn’t.
Encryption. Traffic between the browser and server is ciphertext. An observer on the same network, whether that’s a coffee shop router or an ISP, can see the destination IP and domain but not the content of the request or response. This matters for form data, authentication tokens, and anything else worth stealing. It’s also the foundation of web authentication approaches that rely on session cookies and tokens being confidential in transit.
Authentication. The certificate ties the server’s public key to a domain. Without it, a network attacker can impersonate the server and intercept traffic without either side knowing. HTTPS removes that class of attack, though it doesn’t prevent every vulnerability. The wider picture is covered in our website security basics guide.
Integrity. TLS applies a message authentication code to every record. A tampered byte fails the check and kills the connection. HTTP has no equivalent; a network intermediary can silently modify content, inject ads, or change links without detection.
There are practical downstream effects too. HTTP/2 and HTTP/3 require TLS in every browser implementation. Service workers, geolocation, and push notifications are HTTPS-only. Google has factored HTTPS into rankings since 2014.
Where things break
Expired certificate. Browsers block the page with a hard error, not a soft warning visitors can dismiss easily. Certificate renewal should be automated. Any site on manual renewal will eventually miss a cycle, especially one that doesn’t get regular attention after launch. Expiry is exactly the kind of detail that falls through the cracks without a structured post-launch maintenance routine.
Mixed content. An HTTPS page that loads assets over plain HTTP. Browsers block active mixed content (scripts, iframes) outright and warn on passive mixed content (images). The usual source is hardcoded http:// URLs left over from a migration. Fix by switching to https:// or protocol-relative URLs, and check with browser DevTools after any significant content change.
Wrong domain scope. The certificate covers example.com but visitors land on www.example.com, or a subdomain was added after the cert was issued. Either add the missing name as a Subject Alternative Name or redirect to the domain the certificate covers.
Outdated TLS configuration. TLS 1.0 and 1.1 are deprecated and vulnerable to known attacks. Most managed hosts disable them by default, but self-managed servers may not. The SSL Labs Server Test reports exactly what your server negotiates; run it once and record the expected configuration so any regression is visible.
How Strynal approaches HTTPS and TLS
Every site built through Strynal’s websites and apps practice leaves pre-launch with TLS configured correctly: DV certificates via Let’s Encrypt with automated renewal, TLS 1.2 and 1.3 only, HTTP-to-HTTPS redirects in place, and mixed content cleared. Subdomain scope and cipher suite configuration get checked before handover, not after a browser complaint surfaces.
Certificate health stays on the post-launch checklist. An expired cert is not a one-off incident; it is a sign that automation was never set up, or broke quietly. As the in-house studio for Global Digital Platforms, we treat the security baseline as something that stays in place rather than something reset at every launch.
If your current HTTPS setup has gaps and you want a clear picture of what needs fixing, that assessment is a standard part of the site review we do before any rebuild or migration project.