Every secure website you visit shows a small padlock in the address bar and an address that starts with https instead of http. Behind that padlock is a small data file called an SSL certificate, installed on the web server. It does two things: it proves the website’s identity, and it enables encrypted communication between the visitor’s browser and the server.
The name is slightly out of date — the technology we use today is actually TLS, not SSL — but the industry never dropped the old name. This guide explains what a certificate is, how the handshake works, the three validation levels, the coverage types, how to get one (often for free), and what the padlock does not guarantee.
SSL vs. TLS: the name problem
SSL stands for Secure Sockets Layer, an encryption protocol developed by Netscape in 1995. Its last version, SSL 3.0, was released in 1996 and is now obsolete, with known vulnerabilities that modern browsers no longer support. TLS (Transport Layer Security) replaced it — the first version came out in 1999 — and the versions accepted today are TLS 1.2 and TLS 1.3. TLS 1.0 and 1.1 have been formally deprecated.
Every certificate issued today technically runs on TLS, not old SSL. But “SSL certificate” is the name everyone still uses — hosts sell them, browsers describe them that way, and readers search for that phrase. When this article says “SSL certificate,” it means a TLS certificate, the way the industry does.
How a certificate works: the TLS handshake
When you visit an HTTPS site, a quick negotiation called the TLS handshake secures the connection in milliseconds, before the page even loads:
- Your browser contacts the server and requests a secure connection, sending the TLS versions and cipher suites it supports.
- The server sends its certificate, which contains the domain name, the certificate owner’s information, a public key, the issuing Certificate Authority (CA), the CA’s digital signature, and the validity period.
- The browser checks the certificate. It verifies the CA’s signature using the CA’s public key (which is pre-installed in the browser and operating system), checks that the certificate is not expired and has not been revoked, and confirms the domain in the certificate matches the domain you navigated to.
- A session key is agreed. Once verified, the browser generates a session key and encrypts it using the server’s public key. The server decrypts it with its matching private key.
- Everything after that is encrypted. Both sides now share a secret key, and every bit of data exchanged from that point on is encrypted — so anyone intercepting the traffic sees scrambled data, not passwords, card numbers, or page contents.
The whole system depends on a network of trusted Certificate Authorities — organisations such as DigiCert, Sectigo, GlobalSign, and the non-profit Let’s Encrypt — whose root certificates are pre-installed in operating systems and browsers. That chain of trust, from the root CA through any intermediate CAs to the certificate on the server, is called the certificate chain. If any check in the chain fails, the browser shows a warning instead of the page.
Think of the certificate as a digital ID card combined with a secret handshake: the ID card proves who the server claims to be, and the handshake sets up the encrypted conversation.
The three validation levels: DV, OV, and EV
Certificates differ in how thoroughly the CA verifies the certificate holder’s identity before issuing. The encryption is the same in all three — the difference is what identity information is embedded in the certificate.
| Type | What the CA checks | Typical issue time | Best for |
|---|---|---|---|
| DV — Domain Validated | Only that the applicant controls the domain, usually through an email, an HTTP file challenge, or a DNS record | Minutes | Blogs, personal sites, small businesses |
| OV — Organization Validated | Domain control plus business identity — legal name, address, and domain registration checked against business records | 1–3 days | Commercial websites, service businesses |
| EV — Extended Validation | The most thorough check: legal existence, physical address, operational status, and the applicant’s authority to request the certificate | 3–10 days | Banks, e-commerce platforms, high-trust sites |
A DV certificate is free from Let’s Encrypt and costs roughly $0–$100 a year from commercial CAs. OV certificates cost more, and EV certificates are the most expensive, roughly $150–$1,000+ a year. For most small websites, a DV certificate is entirely sufficient — the encryption is identical, and the visitor sees the same padlock.
One historical note: EV certificates used to make browsers show the organisation’s name in a green address bar. In 2019, Chrome and Firefox removed that visual distinction, so EV certificates are now largely indistinguishable from OV in the browser interface. That change is the main reason EV has become a niche choice rather than a default for commercial sites.
Coverage types: single, wildcard, and multi-domain
Beyond validation level, certificates also differ in how many domains they cover:
- Single-domain: covers exactly one domain, such as example.com. Whether it also covers www.example.com depends on the certificate — check before you buy.
- Wildcard: covers a domain and all of its first-level subdomains, such as *.example.com, which covers blog.example.com, shop.example.com, and any other subdomain you create later.
- Multi-domain (SAN): covers a list of specific domains on one certificate, useful when one server hosts several sites.
If you run one site, a single-domain DV certificate is usually all you need. If you run many subdomains, a wildcard saves you from managing a certificate for each one.
How to get a certificate
For most site owners, getting a certificate is a hosting task, not a shopping task:
- Check your host first. Most hosts now include a free certificate — often from Let’s Encrypt — and install it automatically, with automatic renewal. If your site is on a host that does this, you may already have HTTPS and not know it. Look for the padlock, or ask your host’s support.
- Use Let’s Encrypt if your host supports it. It is free, trusted by all major browsers, and serves more than 700 million websites. The trade-off is a short lifetime — 90 days by default, falling to 45 days by February 2028 — which is why automatic renewal matters.
- Buy from a commercial CA only if you need OV or EV, or if your host does not support Let’s Encrypt. The CA will ask you to prove domain control (DV) or business identity (OV/EV), then issue the certificate for you to install.
- Force HTTPS after installation. Having a certificate is not enough — the site must redirect all http traffic to https, or visitors can still reach the unencrypted version. Most hosts do this with one setting; in WordPress, the Site Address in Settings should start with https://.
Shorter certificate lifetimes: what changed in 2026
Certificate lifetimes are shrinking, by design. Under CA/Browser Forum rules, the industry maximum validity fell to 200 days in March 2026, drops to 100 days in March 2027, and reaches 47 days in March 2029. Let’s Encrypt already issues 90-day certificates and plans 45-day certificates by February 2028. The direction is clear: certificates are becoming short-lived and renewal is becoming automatic. If your site still relies on a manually renewed one-year certificate, plan for the change — the practical answer is automated renewal through your host or Let’s Encrypt, not a calendar reminder.
What the padlock does — and does not — prove
The padlock is widely misunderstood, and the misunderstanding is dangerous:
- It proves the connection is encrypted. Data between the browser and the server cannot be read or tampered with in transit.
- It proves the site controls the domain (for DV) or that a business identity was checked (for OV/EV). It does not prove the owner is honest.
- It does not mean the site is safe. A scam site can get a free DV certificate in minutes and show the same padlock as a legitimate bank. Our fake websites guide explains the checks that actually matter — the domain, the seller’s identity, the prices, the policies, and the payment methods — because the padlock alone proves none of them.
- It does not protect the site itself. A certificate encrypts traffic; it does not stop hacking, malware, or a weak admin password. Those need their own protections.
The shortest version: the padlock means the conversation is private, not that the person on the other end is trustworthy.
Common certificate errors
If you run a site, you will see these sooner or later:
- “Your connection is not private” / NET::ERR_CERT_DATE_INVALID: the certificate expired. Renew it — and set up automatic renewal so it does not happen again.
- Certificate name mismatch: the certificate was issued for a different domain than the one visitors are reaching. Check whether the www version is covered, or whether a subdomain needs its own certificate.
- Mixed content: the page loads over HTTPS but pulls in images, scripts, or styles over HTTP. Browsers block or warn about these. Fix the links to use HTTPS.
- Self-signed certificate: the site presents a certificate it signed itself, with no trusted CA behind it. Browsers warn, and visitors should not proceed unless they know exactly why.
If you are a visitor and you see a certificate warning, do not click through it to enter a password or a payment. A warning on a site you expected to be secure is a reason to stop, not a hurdle to clear.
The bottom line
An SSL certificate — really a TLS certificate — is a small file that proves a site’s identity and encrypts the connection, turning HTTP into HTTPS through a handshake that takes milliseconds. DV, OV, and EV differ in how much identity is verified, not in encryption strength, and most small sites are well served by a free DV certificate with automatic renewal. Lifetimes are shrinking toward 47 days by 2029, so automation is the future. And the padlock means the connection is private — it does not mean the site is honest, so check the site itself before you trust it with your money.
