What is SSL/TLS? How HTTPS Encryption and Certificates Work
SSL/TLS is the security layer behind HTTPS. It encrypts traffic between a browser and a website, verifies the server identity, and protects data such as passwords, cookies, forms, and payment details from being read or changed in transit.
Table of Contents
What is SSL/TLS?
SSL means Secure Sockets Layer. TLS means Transport Layer Security. TLS is the modern protocol, but many people still say SSL certificate out of habit.
When a site uses TLS, the URL begins with https://. The browser may show a padlock or security indicator, depending on the browser design.
TLS protects the connection, not the website content itself. A malicious website can still use HTTPS, so the padlock means the connection is encrypted and the certificate matches the domain, not that the business is automatically trustworthy.
SSL/TLS provides:
1. Encryption
Data is scrambled so eavesdroppers cannot read it.
2. Authentication
The certificate helps prove the server is the real site.
3. Integrity
The connection can detect tampering during transit.
Without HTTPS:
Browser -> "password123" -> Wi-Fi -> ISP -> Website
Anyone on the path may be able to read or alter traffic.
With HTTPS:
Browser -> encrypted TLS data -> Wi-Fi -> ISP -> Website
Interceptors see unreadable encrypted traffic.SSL vs TLS - What is the Difference?
SSL and TLS are often used as if they mean the same thing. Technically, SSL is obsolete and TLS is the protocol used by modern browsers and servers.
| Protocol | Year | Status | Notes |
|---|---|---|---|
| SSL 1.0 | 1994 | Never released | Had serious design problems |
| SSL 2.0 | 1995 | Deprecated | Insecure and vulnerable to multiple attacks |
| SSL 3.0 | 1996 | Deprecated | Broken by attacks such as POODLE |
| TLS 1.0 | 1999 | Deprecated | No longer acceptable for modern security |
| TLS 1.1 | 2006 | Deprecated | Replaced by newer TLS versions |
| TLS 1.2 | 2008 | Supported | Still widely used when configured securely |
| TLS 1.3 | 2018 | Recommended | Faster handshake and safer defaults |
How HTTPS Works
HTTPS is HTTP running inside TLS. The browser still sends normal HTTP requests, but those requests are encrypted before they leave your device.
The TLS Handshake Explained
Before encrypted web traffic begins, the browser and server perform a handshake. The handshake agrees on security settings, validates the certificate, and creates shared encryption keys.
Simplified TLS handshake:
1. ClientHello
Browser sends supported TLS versions, cipher suites, and random data.
2. ServerHello
Server chooses TLS settings and sends its certificate.
3. Certificate validation
Browser checks domain name, issuer, chain, signature, and expiration.
4. Key exchange
Browser and server agree on shared session keys.
5. Finished messages
Both sides confirm the handshake was not tampered with.
6. Encrypted HTTP
Normal HTTP requests and responses now travel inside TLS.SSL Certificates - What is Inside?
An SSL certificate is a digital document that binds a domain name to a public key and identifies the certificate issuer. Browsers use it to verify that the server presenting the certificate is allowed to represent that domain.
A certificate usually contains:
Subject: www.example.com
Issuer: Example Certificate Authority
Valid from: 2026-01-01
Valid until: 2026-04-01
Public key: RSA or ECDSA public key
SAN entries: example.com, www.example.com
Signature: CA signature over the certificate data
Serial number: Unique identifier from the CACertificate Types: DV, OV, and EV
Certificate types differ mostly by how much identity validation the certificate authority performs before issuance.
| Type | Validation | Common use |
|---|---|---|
| DV | Domain Validation: proves control of the domain | Blogs, apps, APIs, personal sites, most websites |
| OV | Organization Validation: checks domain and organization details | Companies that want organization information in the certificate |
| EV | Extended Validation: stricter organization validation | Some finance, enterprise, and compliance-focused sites |
| Wildcard | Covers one level of subdomains such as *.example.com | Many subdomains under the same domain |
| SAN / Multi-domain | Includes several names in one certificate | Multiple domains or hostnames on one service |
Certificate Chain of Trust
Browsers do not manually trust every website certificate. They trust root certificate authorities. A valid certificate chain links the website certificate back to a trusted root.
Certificate chain:
Root CA
-> Intermediate CA
-> Website certificate
Your browser already trusts many root CAs.
The website sends its certificate and usually the intermediate certificate.
The browser builds a chain back to a trusted root.How to Get an SSL Certificate
Most sites get certificates through a hosting provider, CDN, managed platform, or certificate authority. Many certificates are free through automated services such as Let’s Encrypt.
- Choose the domain names that need HTTPS, including www and non-www versions.
- Generate or request a certificate through your host, CDN, or certificate authority.
- Complete domain validation by DNS record, HTTP file, or email approval.
- Install the certificate and private key on the server or platform.
- Enable HTTPS redirects and renew the certificate before it expires.
Common SSL/TLS Errors
SSL/TLS errors usually mean the browser cannot safely validate the certificate or establish a secure connection.
| Error | Common cause | Fix |
|---|---|---|
| Certificate expired | The certificate validity date has passed | Renew and install a fresh certificate |
| Name mismatch | Certificate does not include the requested hostname | Issue a certificate with the correct SAN names |
| Untrusted issuer | Certificate chain does not lead to a trusted root | Install the intermediate certificate or use a trusted CA |
| Mixed content | HTTPS page loads images, scripts, or CSS over HTTP | Change resources to HTTPS URLs |
| Old TLS version | Server only supports deprecated protocols | Enable TLS 1.2 and TLS 1.3 |
| Clock wrong | Client device date/time is incorrect | Correct the system clock |
SSL/TLS Best Practices
A valid certificate is only one part of HTTPS security. Configuration matters too.
| Practice | Why it matters |
|---|---|
| Use TLS 1.2 and TLS 1.3 | Disable SSLv2, SSLv3, TLS 1.0, and TLS 1.1 |
| Automate renewal | Prevent outages caused by expired certificates |
| Redirect HTTP to HTTPS | Keep users on encrypted pages |
| Enable HSTS carefully | Tell browsers to always use HTTPS for your domain |
| Avoid mixed content | Load scripts, styles, fonts, images, and APIs over HTTPS |
| Protect private keys | Never commit keys to source control or share them casually |
Checking SSL Certificates
Checking a certificate helps confirm expiration dates, issuer, hostname coverage, chain validity, and supported TLS versions.
Check a certificate from the terminal:
openssl s_client -connect example.com:443 -servername example.com
Show certificate dates:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -dates -issuer -subjectCheck an SSL Certificate
Use our free SSL Checker to inspect certificate validity, issuer, expiration date, hostname coverage, and common HTTPS configuration issues.
Open SSL CheckerReferences
- RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
- RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
- CA/Browser Forum Baseline Requirements
- Mozilla Server Side TLS recommendations
- Let’s Encrypt documentation