Learn
Certificate Atlas
Certificates are not one thing. Select a type to see who it identifies, who trusts it, how it is renewed, and what happens when it fails.
Public trust
Private trust
Specialized ecosystems
Public trust
TLS server
- Subject
- Hostname or IP address
- Issuer
- Publicly trusted intermediate CA
- Trust source
- Browser and OS root programs
- Key usage
- Digital signature, key encipherment
- Extended key usage
- serverAuth
- Typical validity
- ≤ 200 days today, 47 days from 2029
- Common protocols
- TLS 1.2 / 1.3, QUIC
- Deployment locations
- Load balancers, CDNs, web servers, API gateways, ingress controllers
- Renewal method
- ACME, CLM orchestration, occasionally manual
- Revocation method
- CRL, OCSP, short lifetime as primary mitigation
- Operational owner
- Platform / infrastructure teams
- Failure consequence
- Browser interstitial and full service outage
PQC implication
First place hybrid key exchange appears; signature migration follows.
Anatomy
What is actually inside the file
Identity fields
Subject and SAN say who is being identified. Modern clients ignore the legacy Common Name and match only against the Subject Alternative Name.
Constraint fields
Key usage, extended key usage, basic constraints and validity limit what the key may do and for how long. A certificate used outside these limits is a misissuance, not a convenience.
Evidence fields
AIA, CRL distribution points and embedded Certificate Transparency timestamps let a client fetch the issuer, check revocation, and prove the certificate was publicly logged.
Chain of trust
Three certificates, one decision
Root CA
Offline, in the trust store
10–25 years
Intermediate CA
Online issuing authority
5–10 years
Leaf certificate
Presented by your server
47–200 days
A client trusts the leaf only because it can build a path to a root it already has. Lifetimes shrink as you move down the chain: the root is protected by physical controls, the leaf by rotation.
Lifetimes
How long each certificate type lives
- Public trust
- Private trust
- Specialized ecosystems
Log scale — the range spans days to decades. Short lifetimes replace revocation; long lifetimes require hardware protection.
Comparison
Every type, side by side
| Certificate | Group | Identifies | Trust source | Validity | Renewal | Failure |
|---|---|---|---|---|---|---|
| TLS server | Public trust | Hostname or IP address | Browser and OS root programs | ≤ 200 days today, 47 days from 2029 | ACME, CLM orchestration, occasionally manual | Browser interstitial and full service outage |
| S/MIME | Public trust | Mailbox address and/or person | Mail client and OS trust stores | Typically 1–3 years by profile | Enrolment portal, MDM, CLM | Unverifiable signatures and unreadable encrypted mail |
| Code signing | Public trust | Legal organization identity | OS and platform verifiers | 1–3 years, with timestamping | Managed signing service or hardware token replacement | Blocked installs and reputational damage |
| Document signing | Public trust | Person or organization | Document reader trust lists, EUTL | 1–3 years | Identity re-verification plus reissue | Signatures fail validation on long-term documents |
| Internal TLS | Private trust | Internal hostname or service name | Organization-managed trust store distribution | Policy defined, hours to years | ACME, EST, SCEP, mesh-native issuance | Internal service-to-service failures that are hard to diagnose |
| Device identity | Private trust | Device serial, IMEI, or asset identifier | Network and MDM trust configuration | Months to device lifetime | MDM or enrolment protocol | Devices lose network or VPN access at scale |
| Workload identity | Private trust | SPIFFE ID or service account | Cluster trust bundle | Minutes to hours | Fully automated, continuous | Silent authorization failures across the mesh |
| IoT and OT | Specialized ecosystems | Device or module identity | Embedded trust anchors | Often the operational life of the device | Field update, sometimes impossible | Fleet-wide loss of trust with no remote fix |
| Payments | Specialized ecosystems | Merchant, terminal, or scheme participant | Payment scheme trust lists | Scheme-defined | Scheme-governed rotation events | Declined transactions and scheme penalties |
Foundations
How a certificate is actually trusted
A certificate is a signed statement
It binds a public key to an identity for a period of time, and is only meaningful because something you already trust signed it.
Trust comes from the root store
Clients ship a set of root CAs. Roots stay offline and sign intermediates; intermediates sign the leaf certificate your server presents.
Validation is a chain of checks
Path building, signature verification, validity dates, name matching, key usage, revocation status and — for public TLS — Certificate Transparency evidence.