That padlock icon in your browser means something. It means the connection between you and the server is encrypted, authenticated, and trusted. Here's how SSL/TLS certificates make that happen.
What SSL Actually Means
SSL (Secure Sockets Layer) is the old name. TLS (Transport Layer Security) is the current protocol. Everyone still says "SSL certificate" but they mean TLS. The latest version is TLS 1.3.
When you see https:// in a URL, TLS is encrypting the connection. The "S" stands for secure.
The Three Problems SSL Solves
1. Encryption
Without encryption, data travels in plain text. Anyone on the network can read it.
// Without SSL (HTTP)
GET /login HTTP/1.1
Host: example.com
username=admin&password=secret123With SSL, that same request looks like random garbage to anyone intercepting it:
// With SSL (HTTPS)
çø†ˆµ§¶ª•¡‰¥€£¢¤§¶¨©ª«¬®¯°±²³´µ¶·2. Authentication
How do you know you're actually connected to yourbank.com and not a fake site? The SSL certificate contains verified identity information. Your browser checks this against the domain.
3. Data Integrity
SSL ensures data isn't modified in transit. Each message includes a cryptographic signature. If someone tampers with the data, the signature won't match and the connection fails.
The Handshake: How SSL Starts
Before any data transfers, client and server perform a handshake to establish the encrypted connection.
Client Server | | | 1. Hello (supported ciphers) | |---------------------------------------->| | | | 2. Hello (chosen cipher, certificate) | |<----------------------------------------| | | | 3. Key Exchange | |---------------------------------------->| | | | 4. Finished | |<----------------------------------------| | | [Encrypted communication begins]
Step 1: Client Hello
The client (browser) sends:
- Supported TLS versions (e.g., TLS 1.2, TLS 1.3)
- Supported cipher suites (encryption algorithms)
- A random number (for key generation)
Step 2: Server Hello
The server responds with:
- Chosen TLS version (highest both support)
- Chosen cipher suite (strongest both support)
- SSL certificate (containing public key)
- A random number
Step 3: Key Exchange
Using the server's public key from the certificate, the client generates a "pre-master secret" and encrypts it. Only the server (with its private key) can decrypt this.
Both sides use the pre-master secret and random numbers to generate symmetric session keys. These keys encrypt the actual data.
Step 4: Finished
Both sides send a "Finished" message encrypted with the session key. If decryption succeeds, the handshake is complete.
Why Symmetric Keys?
Asymmetric encryption (public/private keys) is slow. It's only used during the handshake to exchange symmetric keys. Once established, symmetric encryption (AES) handles the data — much faster.
Certificate Authorities: Chain of Trust
Your browser doesn't trust certificates randomly. It trusts specific Certificate Authorities (CAs) that verify domain ownership before issuing certificates.
The Chain
Root CA (built into browser)
↓ trusts
Intermediate CA (signed by root)
↓ trusts
Your Certificate (signed by intermediate)
Your browser has root CA certificates pre-installed. When it sees your certificate, it follows the chain up to a trusted root.
Types of Validation
Domain Validation (DV)
- Proves you control the domain
- Fast, automated verification
- Let's Encrypt provides DV certificates free
- Browser shows padlock, but no organization name
Organization Validation (OV)
- Verifies domain + organization identity
- CA checks business registration
- Browser shows organization name in certificate details
- Higher cost, takes days to issue
Extended Validation (EV)
- Most rigorous verification
- Extensive identity checks
- Browser used to show organization name in address bar (most browsers stopped this)
- Highest cost, takes weeks
What's in a Certificate?
An SSL certificate contains:
- Domain name — What the certificate is valid for
- Organization — Who owns it (for OV/EV)
- Public key — Used to encrypt data to the server
- Issuer — Which CA signed it
- Validity period — When it expires
- Signature — Cryptographic proof CA signed it
- Chain — Intermediate certificates leading to root
Why Certificates Expire
Certificates expire (usually after 90 days to 2 years) for security reasons:
- Limits damage if private key is compromised
- Forces regular verification of domain ownership
- Allows adoption of newer, stronger encryption
- Revokes certificates for defunct domains
Modern certificates auto-renew. Let's Encrypt requires renewal every 90 days but handles it automatically.
Self-Signed Certificates
You can create your own certificate without a CA. But browsers won't trust it because there's no chain to a trusted root.
Self-signed certificates are fine for:
- Internal development/testing
- Private networks (intranets)
- Non-production environments
Never use self-signed for public-facing services. Browsers show scary warnings that drive users away.
Common Errors
Certificate Expired
Solution: Renew the certificate. Set up auto-renewal.
Certificate Not Trusted
Usually means:
- Self-signed certificate (no CA chain)
- Missing intermediate certificate
- Certificate issued by untrusted CA
Domain Mismatch
Certificate is for example.com but you're accessing www.example.com or a different domain entirely.
Mixed Content
Page loaded over HTTPS but includes resources (images, scripts) over HTTP. Browser blocks the insecure content.
Summary
SSL/TLS provides encryption, authentication, and integrity. The handshake exchanges symmetric keys using asymmetric encryption. Certificates are verified by trusted CAs. Everything expires eventually.
For your server, the practical steps are:
- Get a certificate from a trusted CA (Let's Encrypt is free)
- Install it on your web server
- Set up auto-renewal
- Redirect HTTP to HTTPS
Our Let's Encrypt guide walks through the entire process step-by-step.