Every time you see a padlock next to a web address, SSL is at work. It's the reason your card number travels safely to an online shop, and the reason your browser can tell you're really talking to your bank and not an impostor.
This guide explains what SSL is, what an SSL certificate actually contains, and what happens behind the padlock, without assuming any background in cryptography. It ends with the part that trips up even experienced teams: certificates expire, and they're expiring faster every year.
SSL in one sentence
SSL is the technology that encrypts the connection between a browser and a website, and proves the website is who it claims to be.
Those are two separate jobs, and both matter:
- Encryption keeps anyone between you and the site (on public Wi-Fi, at your internet provider, anywhere along the route) from reading or changing what you send and receive.
- Authentication proves you've reached the real
yourbank.com. Encryption alone isn't enough: a perfectly encrypted connection to a fake site would still hand your password to an attacker.
The certificate is what makes the second job possible, as we'll see below.
SSL or TLS? The name that stuck
Strictly speaking, nobody uses SSL any more. SSL (Secure Sockets Layer) was created by Netscape in the mid-1990s. Its successor, TLS (Transport Layer Security), arrived in 1999, and every version of SSL has since been retired because of security flaws.
| Version | Released | Status today |
|---|---|---|
| SSL 2.0 | 1995 | Prohibited since 2011 |
| SSL 3.0 | 1996 | Deprecated in 2015 |
| TLS 1.0 and 1.1 | 1999 and 2006 | Deprecated in 2021 |
| TLS 1.2 | 2008 | Widely used and still secure |
| TLS 1.3 | 2018 | Current: faster and more secure |
The name "SSL" simply stuck. People say "SSL certificate" and "SSL checker" even though the protocol underneath is TLS, so we do too. When you read either term, it means the same thing: the padlock.
What an SSL certificate is
An SSL certificate is a small data file that a website presents to every browser that connects. Think of it as the site's passport. It contains:
- The domain names it covers, such as
example.comandwww.example.com. A browser only accepts the certificate for those names. - A public key. This is half of a key pair; the matching private key stays secret on the web server. Only the holder of the private key can use the certificate.
- Who issued it: the certificate authority that checked the details and signed it.
- Validity dates: a "not before" and a "not after" date. Outside that window the certificate is invalid.
- A serial number, so the issuer can identify it later, for example to revoke it.
- The issuer's digital signature, which makes any tampering with the above detectable.
Certificates for organisations can also include the company's name and location, which the issuer verified before signing.
How HTTPS uses the certificate
When you open https://example.com, your browser and the server run a quick exchange called the TLS handshake before any page content is sent. Simplified, it goes like this:
- Hello. The browser connects and lists the TLS versions and encryption methods it supports.
- The server shows its certificate. Along with it, the server sends any intermediate certificates needed to link it to a trusted authority (more on that below).
- The browser checks it. Is it signed by an authority the browser trusts? Does it cover the name in the address bar? Is today within its validity dates? Has it been revoked?
- They agree on keys. Using the certificate's key to prove the server's identity, the two sides agree on fresh session keys that no one watching the connection can work out.
- Encrypted traffic flows. Everything after this, including the page itself, your form data and your cookies, is encrypted with those session keys.
With TLS 1.3 this takes a single round trip, so it adds only milliseconds. If any check in step 3 fails, the browser stops and shows a full-page warning instead of the site.
Who issues certificates: the chain of trust
Anyone can create a certificate, but browsers only trust certificates signed by a certificate authority (CA), an organisation audited to check that whoever requests a certificate really controls the domain. Well-known CAs include Let's Encrypt, DigiCert, Sectigo, GlobalSign and Google Trust Services.
Your browser and operating system ship with a list of trusted root certificates. CAs keep their root keys offline, so they sign your site's certificate with an intermediate certificate instead. That gives a chain:
Your site's certificate → signed by an intermediate → signed by a trusted root
The browser follows the chain up to a root it already trusts. This is also behind one of the most common configuration mistakes: if the server doesn't send the intermediate certificate, some browsers and most apps and API clients can't complete the chain and reject the connection, even though the certificate itself is fine.
Types of SSL certificates
Certificates differ in two ways: how thoroughly the CA checked who you are, and how many names they cover.
By validation level:
| Type | What the CA verifies | Typical use |
|---|---|---|
| Domain Validated (DV) | That you control the domain | Most websites, blogs, apps and APIs |
| Organization Validated (OV) | Domain control plus that your organisation exists | Business sites that want the company name in the certificate |
| Extended Validation (EV) | A stricter check of the organisation's legal identity | Banks and large enterprises |
All three encrypt equally well. The difference is only in what's verified about the owner. Browsers no longer highlight EV certificates in the address bar, which is why DV certificates, often free, are now the norm.
By coverage:
- Single-domain certificates cover one name, such as
www.example.com. - Wildcard certificates cover every subdomain at one level:
*.example.comcoversshop.example.comandmail.example.com, but notexample.comitself ora.b.example.com. - Multi-domain (SAN) certificates list several specific names, even across different domains.
Why certificates expire, and why it's happening more often
Every certificate has an expiry date, on purpose. Short lifetimes limit the damage if a private key is stolen, and they force the outdated details and weak settings out of circulation.
The industry body that sets the rules, the CA/Browser Forum, has agreed to cut the maximum lifetime of public certificates in stages:
| Certificates issued from | Maximum lifetime |
|---|---|
| Before 15 March 2026 | 398 days |
| 15 March 2026 | 200 days |
| 15 March 2027 | 100 days |
| 15 March 2029 | 47 days |
The 200-day limit already applies today. By 2029, a certificate will need replacing roughly every six weeks. Many sites already renew far more often: free Let's Encrypt certificates last 90 days.
That's manageable when renewal is automated, and the standard way to automate it is a protocol called ACME, supported by most hosting platforms and web servers. But automation fails quietly. A DNS change, a firewall rule, an expired API key or a server that never reloads the new certificate can each stop renewal without anyone noticing, until the old certificate runs out.
What happens when a certificate expires
Nothing gradual: the moment the "not after" date passes, browsers refuse the connection and show a warning such as "Your connection is not private". Most visitors leave. Apps and API clients usually fail outright, which can break integrations, payments and logins far from the website itself.
It happens to the biggest names. In February 2020, Microsoft Teams went down for hours because a certificate expired. The fix took minutes once someone noticed; the outage was about nobody noticing in time.
When a certificate is revoked
A certificate can also stop being valid before it expires. If a private key leaks, or a certificate was issued by mistake, the CA revokes it and publishes that fact, either through an online lookup service (OCSP) or a downloadable certificate revocation list (CRL). Let's Encrypt, for example, now publishes revocation lists only.
A revoked certificate is a serious warning sign: it means the issuer no longer stands behind it. The fix is the same as for an expired one: install a new certificate.
How to check a website's certificate
In your browser: click the padlock (or the site-settings icon) next to the address, then look for the connection or certificate details. You'll see who it was issued to, who issued it and when it expires.
With a checker: our free SSL checker goes further, with no sign-up. Enter any domain and it shows the expiry date, issuer and full chain, whether the hostname matches, which TLS versions the server accepts and whether the certificate has been revoked, summed up as a grade from A to F.
How to never get caught by an expired certificate
- Automate renewal wherever you can, with ACME or your hosting provider's built-in certificates.
- Keep an inventory of every certificate you depend on: main sites, subdomains, APIs, mail servers and anything on a non-standard port.
- Monitor from the outside. Automation tells you it ran; only an outside check tells you the right certificate is actually being served. A monitor that checks your sites daily and emails you well before expiry catches the silent failures.
That last step is what CertHalo does. It watches your certificates and emails you 60, 30, 14, 7, 3 and 1 day before expiry, and whenever a certificate changes, stops matching its name or is revoked. You can monitor 3 certificates free, with no card needed.
Key takeaways
- SSL (today really TLS) encrypts the connection between browser and site and proves the site's identity.
- An SSL certificate binds a domain name to a public key, signed by a certificate authority the browser trusts.
- Every certificate expires, and lifetimes are shrinking: 200 days now, 47 days by 2029.
- An expired or revoked certificate means browser warnings and broken connections the moment it happens.
- Automate renewals, and monitor them, so a quiet failure never becomes an outage.