A TLS certificate is a digitally signed X.509 document that binds a public key to an identity, usually one or more domain names, so that a client can verify it is talking to the genuine server before encrypting a connection with Transport Layer Security (TLS). In Internet trust, it is the credential that turns an anonymous encrypted channel into an authenticated one: encryption alone would protect data from eavesdroppers, but only the certificate proves that the other end really is the named website or service.
The older name SSL certificate is still common, although the SSL protocols themselves were deprecated long ago and every modern certificate is used with TLS 1.2 or TLS 1.3. The certificate format is the same in both cases; only the protocol that uses it has changed.
What a TLS certificate contains
A TLS certificate is a structured data record defined by the X.509 version 3 standard and encoded in DER, often shown in its Base64 PEM form. Its core purpose is to state who owns which public key and to carry the signature of a certificate authority (CA) that vouches for that statement.
| Field | Content | Why it matters |
|---|---|---|
| Subject Alternative Name | Domain names or IP addresses covered | The only name field browsers check today |
| Subject public key | RSA or ECDSA public key | Used to verify the server’s handshake signature |
| Issuer | Name of the signing CA | Points the client to the next link in the chain |
| Validity period | Not before and not after dates | Expired certificates are rejected |
| Key usage and extended key usage | Permitted purposes, such as server authentication | Prevents misuse of a certificate |
| Signature | CA signature over all fields | Proves the content was not altered |
The private key that matches the public key never appears in the certificate and should never leave the server or its hardware security module. Anyone may copy a certificate; only the holder of the private key can prove possession during the handshake.
How a client validates a certificate
During the TLS handshake, the server sends its certificate together with any intermediate CA certificates, and the client builds a certificate chain up to a root certificate that it already trusts. The root stores in operating systems and browsers contain a curated set of CA roots, and trust in any website flows from them.
- Check that each certificate’s signature verifies with the public key of the certificate above it.
- Confirm that the chain ends at a trusted root in the local trust store.
- Confirm that every certificate is within its validity period.
- Match the requested hostname against the Subject Alternative Name entries.
- Check constraints, key usage and, where supported, revocation status and Certificate Transparency proofs.
- Verify that the server signs the handshake with the matching private key.
If any step fails, a browser shows a full-page warning rather than loading the site. The most frequent real cause is not an attack but a missing intermediate certificate or an expired one on the server.
Validation levels and certificate types
Certificates differ in how thoroughly the CA verified the applicant and in how many names they cover. The cryptographic strength is the same for all validation levels; what changes is the identity information behind it.
| Level | What the CA verifies | Typical issuance time |
|---|---|---|
| Domain validated (DV) | Control of the domain only | Seconds to minutes, fully automated |
| Organization validated (OV) | Domain control plus the legal organization | One to several days |
| Extended validation (EV) | Stricter legal, physical and operational checks | Several days to weeks |
Browsers no longer give EV certificates a prominent visual indicator, so for most websites a DV certificate gives equivalent protection to visitors. By coverage, a certificate may be a single-name certificate, a multi-domain (SAN) certificate listing several names, or a wildcard certificate such as one for any first-level subdomain of a domain. A self-signed certificate is signed by its own key and is trusted only where it has been installed manually, which suits internal testing but not public services.
Lifetimes, renewal and automation
Certificate lifetimes have been shrinking steadily, because a short life limits the damage from a stolen key and reduces dependence on revocation. Industry rules set by the CA/Browser Forum cut the maximum public certificate lifetime from 398 days to 200 days in March 2026, with further steps planned toward 47 days by 2029. Free automated CAs already issue certificates valid for 90 days or less.
Such short lifetimes make manual renewal impractical. The ACME protocol lets a server request, validate and install certificates automatically, proving domain control through an HTTP file, a DNS TXT record or a TLS-ALPN response. The table below summarizes the choices administrators face.
| Situation | Recommended choice | Reason |
|---|---|---|
| Public website or API | DV certificate renewed through ACME | Free, automated and widely trusted |
| Many subdomains on one platform | Wildcard via DNS-01 challenge | One certificate covers new subdomains |
| Regulated organization | OV certificate with managed renewal | Identity details in the certificate |
| Internal services and devices | Private CA with short-lived certificates | Full control without public exposure |
| Service-to-service authentication | Mutual TLS with client certificates | Both sides prove their identity |
Revocation, transparency and common failures
A certificate can be revoked before it expires, for example when its private key leaks. CAs publish revocation through certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP), but browsers check revocation inconsistently, which is one reason the industry prefers short lifetimes. Certificate Transparency logs make every publicly trusted certificate visible, so domain owners can detect certificates issued without their consent.
| Error | Usual cause | Fix |
|---|---|---|
| Expired certificate | Renewal did not run or failed silently | Automate renewal and monitor expiry dates |
| Name mismatch | Hostname missing from the SAN list | Reissue with all required names |
| Untrusted issuer | Missing intermediate or self-signed certificate | Serve the full chain from a public CA |
| Key mismatch | Certificate installed with the wrong private key | Pair the certificate with its own key |
A frequent design mistake is certificate pinning in mobile apps or clients that hard-code a specific certificate. When the certificate is rotated, every pinned client breaks. Pinning to a CA or a backup key, or avoiding pinning entirely, is far less fragile.
The idea in brief
A TLS certificate works like an official ID card for a website. When your browser connects to a bank’s site, the site shows its card, which says which web address it belongs to and is stamped by a trusted issuer.
Your browser checks the stamp, the name and the expiry date. If everything matches, it sets up a private, encrypted connection and shows the page normally. If something is wrong, it warns you, because someone may be pretending to be that site.
A practical scenario
A small online retailer runs its shop on two web servers behind a load balancer. For years it bought a one-year OV certificate and renewed it by hand. One year the reminder email went to a former employee, the certificate expired on a Saturday, and customers saw security warnings for most of a weekend, which stopped almost all orders.
The operations team then moves to a DV certificate issued through ACME and installed on the load balancer. A renewal job runs twice a day, renews when fewer than thirty days remain, and alerts the team if renewal fails twice in a row. An external monitor also checks the live certificate’s expiry date. Since the change, renewals happen automatically every few weeks, and no expiry-related outage has occurred.