Every time you see "https://" at the start of a URL, your connection to that site is encrypted. But what does that actually mean? How does your browser and a server in a data center establish a private, encrypted connection in milliseconds without having met before? This guide explains the technology behind HTTPS — TLS, certificates, and the certificate authority system.
HTTP vs HTTPS
HTTP (HyperText Transfer Protocol)
- Transmits data in plain text
- Anyone between you and the server can read it
- No verification the server is who it claims to be
- Being phased out — browsers flag HTTP sites as "Not Secure"
HTTPS (HTTP Secure)
- Data encrypted with TLS
- Intercepted traffic is unreadable ciphertext
- Server identity verified by certificate
- Now used by 95%+ of web traffic
What is TLS?
TLS (Transport Layer Security) is the protocol that provides the encryption, authentication, and data integrity for HTTPS. It's the successor to SSL (Secure Sockets Layer), which is why you still hear the terms "SSL certificate" and "SSL/TLS" — they're used interchangeably in casual usage, though SSL is technically deprecated.
The current version, TLS 1.3 (2018), removed several legacy cryptographic options and simplified the handshake process, making it both more secure and faster than TLS 1.2.
The TLS handshake: establishing a secure connection
When you navigate to https://example.com, your browser and the server perform a TLS handshake — an automated negotiation that happens in milliseconds:
1. Client Hello
Your browser sends its TLS version, supported cipher suites (encryption algorithms), and a random value (client random).
2. Server Hello
The server responds with its chosen cipher suite, another random value (server random), and its TLS certificate.
3. Certificate verification
Your browser examines the certificate: Is it valid? Is it signed by a trusted Certificate Authority? Does the domain match? If any check fails, your browser shows a security warning.
4. Key exchange (Diffie-Hellman)
Browser and server use Elliptic Curve Diffie-Hellman (ECDH) to agree on a shared secret without transmitting it over the network. An eavesdropper who captures all the handshake traffic still cannot derive the shared secret.
5. Session keys derived
Both sides independently derive the same symmetric encryption keys from the shared secret, client random, and server random. These keys are used only for this session.
6. Encrypted communication
All subsequent data is encrypted with AES-256-GCM (or ChaCha20-Poly1305). The handshake is complete.
TLS certificates: proving identity
A TLS certificate is a digital document that binds a domain name to a public key. It contains:
- The domain name(s) it's valid for
- The server's public key
- The certificate's validity period (typically 1 year or less)
- A digital signature from a Certificate Authority
The certificate signature is what makes it trustworthy. Your browser ships with a list of trusted Certificate Authorities (CAs) — organizations like Let's Encrypt, DigiCert, Sectigo, and Google Trust Services. If a certificate is signed by one of these CAs, your browser trusts it.
Certificate Authorities (CAs)
A Certificate Authority is an organization trusted to verify the identity of domain owners and issue certificates. The CA system is hierarchical:
- Root CAs — Highest trust level, certificates embedded in browsers/OS. Their private keys are stored offline in air-gapped HSMs (Hardware Security Modules).
- Intermediate CAs — Signed by root CAs, used for day-to-day certificate issuance.
- End-entity certificates — Issued to websites, valid for 90–365 days.
Let's Encrypt revolutionized the CA landscape by offering free, automated certificates — driving HTTPS adoption from ~40% of web traffic in 2015 to 95%+ today.
What the padlock actually means
🔒 Padlock (closed)
The connection is encrypted and the certificate was signed by a trusted CA. The domain in the address bar matches the certificate. Your data is protected in transit.
⚠️ "Not Secure" (HTTP)
The connection is unencrypted. Avoid entering any information on HTTP sites. Modern browsers block form submissions on HTTP pages.
❌ Certificate warning
The certificate is invalid, expired, or doesn't match the domain. Do not proceed — you may be on a MITM-intercepted connection or a phishing site.
What HTTPS does NOT protect against
- Phishing — A phishing site can have a valid HTTPS certificate. The padlock only means the connection to that site is encrypted — it doesn't mean the site itself is legitimate.
- Malware on your device — If malware has a root certificate installed on your device, it can intercept HTTPS traffic by acting as a "trusted" MITM.
- Weak passwords — HTTPS protects your password in transit. A weak password is still vulnerable to guessing or brute force at the server.
- Data breaches at the server — Once your data arrives at the server, its security depends entirely on the server's practices.
Frequently asked questions
Is HTTPS completely secure?
HTTPS protects data in transit. It doesn't protect against phishing (fake sites can have valid HTTPS), malware on your device, weak passwords, or server-side breaches. HTTPS is a necessary but not sufficient condition for security.
Why do certificates expire?
Short certificate lifetimes (90 days is now common) limit the damage if a certificate's private key is compromised. If keys are rotated frequently, a stolen key becomes useless quickly. Let's Encrypt has pushed the industry toward 90-day certificates, with proposals for even shorter periods (47 days) under discussion.
What's the difference between DV, OV, and EV certificates?
Domain Validation (DV) — the CA verifies only that you control the domain. Organization Validation (OV) — the CA verifies your organization's legal existence. Extended Validation (EV) — the highest verification level, historically showing a green bar with the company name. Modern browsers have de-emphasized EV indicators as research showed users couldn't distinguish them anyway.