An SSL certificate is a small, digitally signed file installed on a web server that does two jobs at once: it proves the site is who it claims to be, and it hands the browser a public key used to set up encryption for that visit. Together, those two things are what put the padlock in the address bar.
What it actually contains
Strip away the cryptography and a certificate is mostly plain data: the domain(s) it covers, who issued it, when it expires, and a public key. It's signed by a Certificate Authority (CA) — an organization your browser already trusts — which is what lets your browser trust the certificate by extension, without ever having met your server before.
How it secures a connection
When your browser connects to a site over HTTPS, the server presents its certificate during a brief negotiation called the TLS handshake. The browser checks the certificate is valid, unexpired, and issued for the exact domain being visited, then uses the public key inside it to help establish a shared encryption key with the server. From that point, everything sent — form data, cookies, page content — is encrypted in transit.
What it protects against
- Eavesdropping — anyone intercepting the traffic (a coffee shop Wi-Fi network, an ISP) sees only encrypted noise, not the actual content.
- Tampering — TLS includes integrity checks, so data altered in transit is detected rather than silently accepted.
- Impersonation — the certificate is tied to a specific domain, so a browser won't accept it for a different one, making it much harder to silently redirect visitors to a fake copy of your site.
What it doesn't protect against
A certificate says nothing about whether the site itself is trustworthy, well-built, or free of malware — it only confirms the connection to that specific domain is encrypted and that the domain is who it claims to be at the DNS level. Phishing sites can and do have valid certificates for their own look-alike domains.
The three main types, at a glance
All three encrypt a connection identically — the difference is purely in how thoroughly the certificate authority checked who was actually requesting it before issuing. A DV certificate, the kind most personal sites and small businesses use, only confirms you control the domain, typically through a DNS record or a file placed at a specific URL. OV and EV add progressively more rigorous checks into the business itself, useful mainly for compliance or specific industry expectations rather than for stronger encryption.
Where the certificate file actually lives on your server
In practice, installing a certificate means placing a small number of related files on your server: the certificate itself, a private key that never leaves the server, and a bundle of intermediate certificates connecting your certificate back to a root your visitor's browser already trusts. Your web server's configuration then points to these files, and the server presents them automatically during every new HTTPS connection — the certificate itself doesn't run any code or do any active work beyond being presented and verified.
Why certificates expire at all
Unlike a driver's license that might stay valid for a decade, certificates deliberately expire on a short cycle — anywhere from 90 days to about 13 months depending on the type. This isn't a sales tactic; it's a security control. A shorter validity window limits how much damage a compromised or mistakenly issued certificate can do, and forces periodic revalidation that a domain hasn't quietly changed hands or configuration since the certificate was first issued.
A quick way to see one for yourself
Click the padlock or the small icon to the left of any address bar on an HTTPS site, then look for "Certificate is valid" or similar wording — most browsers let you drill into the actual certificate details from there: who issued it, which exact hostnames it covers, and its expiry date. Doing this once on a familiar site is a good way to make the concept concrete rather than abstract.
The chain of trust, briefly
Your browser doesn't inherently trust every certificate authority in the world — it trusts a specific, curated list of root certificates built into the browser or operating system. Your certificate is signed by a CA, whose own certificate is in turn signed by one of those trusted roots (often through one intermediate step in between). This chain — root, intermediate, your certificate — is what lets a browser extend trust to a certificate it's never encountered before, issued by a company it's never dealt with, simply by tracing the signatures back to something it already trusts.
How this actually plays out for a typical small website
For most site owners, the practical experience of "getting a certificate" has become almost entirely invisible — a modern hosting account or platform (WordPress.com, Shopify, most shared hosting) provisions and renews a free certificate automatically, with no manual steps at all. The deeper mechanics described above still happen every time a visitor connects, but nobody involved needs to think about them directly unless something breaks or a more advanced setup (a custom server, a wildcard certificate, a specific vendor requirement) is involved.
Certificates versus the broader idea of 'website security'
It's worth being precise about scope: a certificate secures the connection and confirms domain identity, and that's genuinely valuable, but it says nothing about whether your server software is patched, whether your CMS has known vulnerabilities, or whether a contact form is properly validating input. Treating "I have HTTPS" as equivalent to "my site is secure" is a common and understandable oversimplification — HTTPS is one necessary layer among several, not a complete security posture on its own.
What actually happens if you skip it
A site without a certificate is served over plain HTTP, and every major browser today marks that explicitly as "Not Secure" in the address bar — for any page with a form, a login, or really any interactive element. Beyond the visible warning, the underlying risk is real: data submitted on an HTTP page, including passwords, can be intercepted by anyone positioned on the network path between the visitor and your server, which is a meaningfully lower bar for an attacker than compromising the server itself.
The handshake, in one paragraph
Every time a browser connects, it and the server briefly negotiate before any page content is exchanged: the browser checks the certificate's validity and hostname match, both sides agree on which encryption method to use, and they mathematically derive a shared secret key without ever transmitting that key across the network in a form an eavesdropper could extract. This entire negotiation typically completes in well under a second, and it's what's actually happening in the brief moment before a page starts loading on an HTTPS connection.
Free versus paid, revisited
Because this question comes up so often: a free certificate from Let's Encrypt and a paid certificate from a commercial vendor provide identical encryption strength at the same validation tier — there's no technical sense in which paying more makes a connection "more encrypted." What a paid certificate can add is a higher validation tier (OV or EV), a longer manual validity window, a CA warranty, and dedicated vendor support — none of which change the actual cryptography protecting the connection itself.
Where to go next
If this explained the concept but you're now wondering how to actually get one installed, our HTTPS Migration category walks through platform-specific steps, and our How-To category covers generating a CSR, installing a certificate manually, and renewing without downtime. If you want to go deeper on any single piece mentioned here — the handshake, the chain of trust, or the difference between certificate types — each has its own dedicated deep-dive elsewhere in this Basics category.
Every other article in this Basics category assumes you've internalized what's covered here — the certificate as a signed, verifiable statement of identity paired with a public key — so it's worth returning to this page any time a more advanced topic elsewhere references a concept that feels unfamiliar.
A quick closing checklist for confirming your own certificate is genuinely healthy
Confirm it's issued by a publicly trusted CA, covers every hostname you actually use, hasn't expired, and is backed by automated renewal — four checks covering the practical essentials this entire article has walked through.