When you see the padlock icon in your browser's address bar, it means the connection between your browser and the server is encrypted using TLS (Transport Layer Security). But what does that actually mean? How does your browser verify that it is really talking to google.com and not an attacker? And what do those certificate warnings actually mean?
This guide explains the entire system — from how the TLS handshake works to why Let's Encrypt changed the internet.
Need a VPS? Vultr (free credit), DigitalOcean ($200 free credit), or RackNerd (cheap annual deals).
SSL vs TLS — What is the Difference?
SSL (Secure Sockets Layer) is the original protocol, created by Netscape in the 1990s. It has been deprecated since 2015 due to security vulnerabilities. TLS (Transport Layer Security) is its successor.
| Version | Status |
|---|---|
| SSL 2.0 | Deprecated (insecure) |
| SSL 3.0 | Deprecated (POODLE vulnerability) |
| TLS 1.0 | Deprecated |
| TLS 1.1 | Deprecated |
| TLS 1.2 | Widely used, still secure |
| TLS 1.3 | Current standard, fastest and most secure |
Everyone still says "SSL certificate" out of habit, but the actual protocol in use is TLS. When someone says "SSL," they mean TLS.
How the TLS Handshake Works
When your browser connects to https://samnet.dev, a TLS handshake happens before any data is exchanged:
1. Client Hello Your browser sends a message to the server listing which TLS versions and cipher suites it supports, along with a random number.
2. Server Hello The server picks the best TLS version and cipher suite from the client's list, sends its own random number, and sends its SSL certificate.
3. Certificate Verification Your browser checks the certificate:
- Is it issued by a trusted Certificate Authority (CA)?
- Is the domain name on the certificate correct?
- Has it expired?
- Has it been revoked?
4. Key Exchange The certificate's public key authenticates the server (proves it is who it claims). A separate Diffie-Hellman key exchange creates the shared symmetric key. In TLS 1.3, the certificate is only for authentication, not key exchange.
5. Encrypted Connection Both sides now have the same symmetric key. All further communication is encrypted with this key. The handshake took about 1-2 round trips (TLS 1.3 does it in just 1).
The entire handshake takes 50-150 milliseconds. After that, every byte of data between your browser and the server is encrypted.
What is in an SSL Certificate?
An SSL certificate is a digital document that contains:
- Subject: The domain name(s) the certificate is valid for
- Issuer: The Certificate Authority that issued it
- Public Key: Used during the TLS handshake for key exchange
- Validity Period: Not Before and Not After dates
- Serial Number: Unique identifier
- Signature: The CA's cryptographic signature proving it issued this certificate
- SANs (Subject Alternative Names): Additional domains covered by the certificate
Certificate Types
By Validation Level
| Type | Validation | What CA Checks | Cost | Trust |
|---|---|---|---|---|
| DV (Domain Validated) | Automatic | You control the domain | Free–$10/yr | Basic |
| OV (Organization Validated) | Manual | Business identity verified | $50-200/yr | Medium |
| EV (Extended Validation) | Thorough | Legal entity, physical address | $100-500/yr | Highest |
DV certificates are by far the most common. Let's Encrypt issues them for free. They prove you control the domain, but nothing about your identity.
OV and EV certificates require the CA to verify your business. EV used to show a green bar with the company name, but browsers removed that in 2019. The security is the same regardless of type — the difference is identity verification.
By Coverage
| Type | Covers | Example |
|---|---|---|
| Single domain | One domain | samnet.dev |
| Wildcard | Domain + all subdomains | *.samnet.dev |
| Multi-domain (SAN) | Multiple specific domains | samnet.dev, www.samnet.dev, api.samnet.dev |
The Certificate Chain
Browsers do not trust individual certificates directly. They trust a set of root Certificate Authorities. The chain works like this:
Root CA (trusted by your browser/OS)
└── Intermediate CA (signed by Root CA)
└── Your certificate (signed by Intermediate CA)
When your server presents its certificate, it also sends the intermediate certificate(s). Your browser follows the chain up to a trusted root CA. If any link in the chain is missing or invalid, you get a certificate error.
Common misconfiguration: Forgetting to include the intermediate certificate in your server configuration. The browser has the root CA but cannot verify the chain because the middle link is missing. Some browsers cache intermediates and work anyway, others fail — this creates inconsistent "works for me" problems.
Let's Encrypt
Let's Encrypt is a free, automated Certificate Authority that has fundamentally changed the web. Before Let's Encrypt (launched 2015), SSL certificates cost $50-300/year and required manual setup. Now:
- Free DV certificates
- Automated —
certbothandles issuance and renewal - 90-day validity — short-lived certificates are more secure
- Auto-renewal — set it up once and forget it
# Install certbot and get a certificate
apt install certbot python3-certbot-nginx
certbot --nginx -d samnet.dev -d www.samnet.dev
# Auto-renewal is set up automatically
# Verify with:
certbot renew --dry-run
Let's Encrypt now secures over 300 million websites.
Common SSL Errors and Fixes
ERR_CERT_DATE_INVALID
The certificate has expired. Fix: renew the certificate.
certbot renew
ERR_CERT_AUTHORITY_INVALID
The certificate is self-signed or issued by an untrusted CA. Fix: use a certificate from a trusted CA (like Let's Encrypt).
ERR_CERT_COMMON_NAME_INVALID
The domain name does not match the certificate. You are visiting www.samnet.dev but the certificate is only valid for samnet.dev. Fix: add the www domain as a SAN, or use a wildcard certificate.
ERR_SSL_PROTOCOL_ERROR
The server and browser cannot agree on a TLS version. Usually means the server is configured with outdated TLS versions. Fix: enable TLS 1.2 and 1.3, disable older versions.
Mixed Content Warning
The page loads over HTTPS but includes resources (images, scripts, CSS) over HTTP. Fix: change all resource URLs to HTTPS or use protocol-relative URLs.
Testing Your SSL Configuration
A properly configured SSL setup should:
- Support TLS 1.2 and TLS 1.3
- Use strong cipher suites
- Include the full certificate chain
- Have HSTS headers enabled
- Score A or A+ on an SSL test
- Have no mixed content
Use our free SSL Server Test to analyze your server's TLS configuration, certificate chain, protocol support, and cipher suites — modeled after SSL Labs with a detailed report.
You can also verify HTTPS redirects and HSTS preload readiness with our HTTPS Redirect Tester.