SSL/TLS Certificates Explained: How to Check and Read One
By Chris Morris, Senior Developer · Updated 2026-07-25An SSL/TLS certificate is a signed digital file that proves a website is who it claims to be and lets your browser encrypt the connection to it. When you see the padlock in the address bar, a certificate is doing two jobs at once: it binds a domain name to a public key, and it carries a trusted certificate authority's signature vouching that the binding is genuine. The certificate format itself is defined by RFC 5280.
The "SSL" in the name is historical. The encryption is actually handled by TLS, the modern protocol that replaced SSL years ago, which we cover in SSL vs TLS. Which TLS version a server will actually negotiate is a separate question from whether its certificate is valid, and it is the one that usually decides whether a connection is considered secure: see TLS versions explained for what is still acceptable and what browsers now refuse. This guide explains what a certificate contains and how to inspect one; the linked splinters go deep on each task.
You can inspect any site's live certificate in seconds with our SSL checker, which reports validity, issuer, expiry, and protocol in one view.
What a certificate actually proves
A certificate answers two questions a browser needs to trust before sending data:
- Identity. Is this really
example.com, or an impostor? The certificate lists the domains it is valid for, and the browser checks the one in the address bar against that list. - Trust. Who says so? The certificate is signed by a certificate authority (CA). Browsers ship with a list of trusted root CAs, and the certificate must trace back to one of them through its certificate chain.
A certificate does not prove the site is safe or honest. It proves the connection is encrypted and the domain is the one named. A phishing site can hold a perfectly valid certificate.
The fields in a certificate
| Field | What it means |
|---|---|
| Subject / Common Name | The primary domain the certificate is issued to |
| Subject Alternative Names (SAN) | All hostnames the certificate covers |
| Issuer | The certificate authority that signed it |
| Valid from / Valid to | The certificate's validity window |
| Serial number | Unique ID assigned by the CA |
| Signature algorithm | How the certificate is signed (for example SHA-256 with RSA) |
| Public key | The site's public key, used to set up encryption |
The names a certificate covers live in the Subject Alternative Names field, which is why a single certificate can secure both example.com and www.example.com, or an entire subdomain space with a wildcard. We compare the options in wildcard vs SAN certificates.
Validation levels: DV, OV, and EV
Certificates differ in how much the certificate authority verified before issuing, and this is the area where the marketing diverges most from the technical reality.
| Level | What the CA verified | Typical issue time |
|---|---|---|
| Domain Validated (DV) | Only that you control the domain, proved by a DNS record, an HTTP file, or an email challenge | Seconds to minutes |
| Organisation Validated (OV) | Domain control plus the existence of the legal organisation | Days |
| Extended Validation (EV) | Domain control plus a stricter vetting of the legal entity | Days to weeks |
The important point: the encryption is identical at every level. A free DV certificate from an ACME-based authority protects the connection exactly as well as an expensive EV one. What differs is the identity assertion recorded in the certificate, not the cryptography.
EV certificates were once rewarded with the green address bar showing the company name. Browsers removed that treatment years ago, after research showed users did not notice or understand it, so an EV certificate now looks the same as a DV certificate to a visitor unless they open the certificate viewer. For the overwhelming majority of sites, automated DV is the correct answer.
Why certificates keep getting shorter
Maximum certificate lifetimes have fallen steadily: five years, then three, then two, then 398 days in 2020. The industry has agreed to continue that reduction substantially further over the next few years.
The reasoning is that revocation has never worked reliably. Browsers cannot always check whether a certificate has been revoked, and they generally fail open rather than blocking the site, so a stolen key can remain useful until the certificate expires naturally. Shorter lifetimes shrink that window. They also force the automation that makes short lifetimes tolerable in the first place.
The practical consequence is simple. Manual renewal is no longer viable. Use ACME, verify that renewal actually runs unattended, and monitor expiry independently rather than trusting that the automation is working. A cron job that has been silently failing for two months looks exactly like one that is working, right up until the certificate expires. See SSL certificate expiration.
Certificate Transparency: every certificate is public
Since 2018, Chrome has required that publicly trusted certificates be logged to Certificate Transparency logs, which are append-only public records. Other major browsers apply similar requirements.
This has two consequences worth knowing. First, you can audit certificate issuance for your own domains, and detect a certificate that someone obtained without authorisation. Second, and less comfortably, CT logs are public, so every hostname you request a certificate for becomes a matter of public record. Requesting a certificate for staging-newproduct.example.com announces that hostname to anyone watching the logs, and people do watch them, including attackers looking for non-production hosts. Use a wildcard certificate for internal hostnames you would rather not publish.
CT logs are also how subdomain discovery works, including ours. That is the same mechanism, used constructively.
Checking and reading a certificate
You do not need OpenSSL to audit a site. Our SSL checker pulls the live certificate and shows the issuer, the validity dates, the days remaining, and the negotiated protocol. For a step-by-step walkthrough including browser and command-line methods, see how to check a website's SSL certificate.
Two things trip people up most often:
- Expiration. Certificates are short-lived by design and must be renewed. A lapsed certificate breaks the site for every visitor. See SSL certificate expiration.
- Errors. Name mismatches, incomplete chains, untrusted issuers, and self-signed certificates all produce browser warnings. See common SSL errors and self-signed certificates.
How certificates relate to DNS
Certificates and DNS work together. A CAA record in your DNS controls which certificate authorities are even allowed to issue a certificate for your domain, which is a useful security layer that ties the two systems together.
Once you can read a certificate, HTTPS stops being a black box. You can tell who issued it, what it covers, when it expires, and whether a warning is a real problem or a misconfiguration. Run a check on any site with our SSL checker, or have an agent fetch it through the ssl_certificate tool in our MCP server.
Frequently asked questions
What is an SSL certificate?
An SSL/TLS certificate is a digital file that binds a domain name to a cryptographic key pair and is signed by a trusted certificate authority. It lets a browser confirm it is talking to the real site and encrypt the connection. Despite the name, modern certificates are used with the TLS protocol, not the old SSL protocol.
How do I know if a site's certificate is valid?
A valid certificate is issued by a trusted certificate authority, covers the exact hostname you are visiting, is within its validity dates, and chains to a trusted root. Browsers check this automatically and show a warning if any check fails. You can inspect the details yourself with a certificate checker.
What is the difference between SSL and TLS?
TLS is the modern, secure successor to SSL. The SSL protocol versions are all deprecated and insecure. The word SSL has stuck around as a label for certificates and HTTPS, but the actual encryption is done by TLS.
Is a paid SSL certificate more secure than a free one?
No. The encryption is identical regardless of price or validation level. A free Domain Validated certificate from an ACME-based authority protects the connection exactly as well as an expensive Extended Validation one. What you pay for is a stronger identity assertion recorded in the certificate, plus support and warranty terms, not stronger cryptography.
What is the difference between DV, OV, and EV certificates?
They differ only in what the certificate authority verified before issuing. DV confirms you control the domain and issues in seconds. OV additionally verifies that the organisation legally exists. EV applies stricter entity vetting and takes longest. Browsers removed the special green address bar treatment for EV years ago, so to a visitor all three now look the same unless they open the certificate viewer.
Why do SSL certificates expire so quickly now?
Because certificate revocation has never worked reliably. Browsers cannot always check revocation status and generally fail open rather than blocking the site, so a stolen key stays useful until the certificate expires on its own. Shorter maximum lifetimes, now 398 days and falling further, shrink that exposure window and force the renewal automation that makes short lifetimes manageable.
Are the certificates I request public?
Yes. Publicly trusted certificates must be logged to Certificate Transparency logs, which are append-only and public, and browsers require this. That lets you audit issuance for your own domains and spot unauthorised certificates, but it also means every hostname you request a certificate for becomes public record. Use a wildcard certificate for internal or staging hostnames you would rather not announce.