PKI Basics Guide: Certificates, Certificate Authorities and Chains of Trust

Every TLS connection, signed binary and mTLS call depends on a public key infrastructure that most teams use daily but few can explain when it breaks. A public key infrastructure (PKI) is the set of certificate authorities, policies, certificates and trust stores that lets one system check that a public key really belongs to the name it claims. When the chain cannot be built, a root is distrusted or a revocation check fails, the result is an outage or, worse, a silent acceptance of a forged identity. This guide covers the fundamentals: what is inside an X.509 certificate, how roots and intermediates form a chain of trust, how validation and revocation work, and how to choose between public and private PKI. It is for security engineers, platform teams and auditors. Lifecycle automation, mTLS, AD CS and the 47-day schedule have their own guides, linked where relevant.

Key takeaways

• A certificate is a signed binding. An X.509 certificate (RFC 5280) binds a public key to a name and is signed by a CA; whoever holds the matching private key can prove that identity.
• Trust flows down from roots. Clients trust a small set of root CAs in their trust store, roots sign intermediates, and intermediates sign end-entity certificates; the server must send the intermediates.
• Validation is more than a signature check. Clients check each signature, validity dates, name (SAN, never CN), key usage, basic constraints and, where configured, revocation status.
• Revocation is moving to CRLs and short lifetimes. The CA/Browser Forum made OCSP optional and CRLs mandatory for public CAs, Let's Encrypt shut its OCSP responders in August 2025, and public lifetimes fall to 47 days by 2029.
• Private PKI is where most certificates live. Internal CAs issue the service, device and workload certificates that act as machine identities, and they need the same inventory, protection and automation as public certificates.

What PKI is made of

Public key cryptography gives every party a key pair: a private key kept secret and a public key shared freely. Anyone can verify a signature with the public key, but on its own a public key carries no name. PKI solves that by having a trusted third party, the certificate authority, vouch for the binding. See the Symmetric vs Asymmetric Encryption Guide for the underlying cryptography.

• Certificate authority (CA): signs certificates and revocation information. A root CA is self-signed and trusted directly; a subordinate (intermediate) CA is signed by a root or another intermediate.
• Registration authority (RA): checks that a requester is entitled to the identity, for example by domain validation (the ACME http-01 and dns-01 challenges in RFC 8555) or by an internal approval workflow.
• End-entity (leaf) certificate: issued to a server, client, user, device, workload or code signer. It cannot issue other certificates.
• Trust store: the list of root certificates a client accepts, such as the operating system store, the Mozilla NSS store used by many Linux distributions, the Java cacerts file or a container's CA bundle.
• Certificate policy and CPS: documents stating what the CA checks before issuing and how it protects its keys. Public CAs publish these and are audited against them.
• Revocation services: certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP) responders that announce certificates that must no longer be trusted.

Inside an X.509 certificate

RFC 5280 (May 2008) is the internet profile for X.509 version 3 certificates and CRLs. A certificate has three parts: tbsCertificate (the content to be signed), signatureAlgorithm and signatureValue. The CA hashes the content and signs the digest, which is why weak hashes such as SHA-1 undermined certificates; see the Hashing Guide. The fields and extensions below are the ones practitioners read most often, for example with openssl x509 -in cert.pem -noout -text.

Certificate authorities, roots and intermediates

A root CA key is the most valuable asset in a PKI: anyone who holds it can issue a certificate for any name that relying parties will accept. Good practice is to keep the root offline, its key in a hardware security module, and use it only to sign intermediate certificates and their revocation lists. Intermediates do the daily issuing, so if one is compromised it can be revoked and replaced without rebuilding every trust store.

• Two-tier hierarchy: offline root plus one or more online issuing CAs. Enough for most private PKIs.
• Three-tier hierarchy: root, policy or regional intermediates, then issuing CAs. Useful for large or regulated estates that need separate policies or legal entities, at the cost of more certificates to manage and longer chains.
• Technically constrained intermediates: the Mozilla Root Store Policy encourages intermediates that carry an EKU limited to their purpose (never anyExtendedKeyUsage) and, for TLS, name constraints. Unconstrained intermediates must be audited and disclosed in the CCADB within seven days of creation.
• Cross-signing: a new root can be signed by an established one so older clients that lack the new root still build a valid path.

Public CAs are governed by the CA/Browser Forum Baseline Requirements (version 2.3.1 at the time of writing) and by browser and operating system root programmes, which require annual WebTrust or ETSI audits. Root programmes can and do remove CAs: Chrome stopped trusting Entrust and AffirmTrust roots by default for certificates whose earliest Signed Certificate Timestamp was after 11 November 2024, citing a pattern of compliance failures. Organisations with Entrust certificates had to move CA within months, which is a strong argument for automation and for never hard-coding a single public CA. Certificate Transparency logs record every publicly trusted certificate; see the Certificate Transparency Guide.

How a chain of trust is validated

RFC 5280 section 6 defines path validation. In practice a TLS client does the following for the chain the server presents; the How TLS Works Guide places this inside the handshake.

1. Build the path: from the leaf, match each issuer name and authority key identifier to the next certificate, up to a root in the local trust store. Servers must send the leaf and all intermediates; browsers may fetch a missing intermediate through the AIA URL, but many API clients, Java and Go applications and IoT devices do not, which causes "works in the browser, fails in the app" incidents.
2. Check each signature: every certificate must verify against its issuer's public key using an acceptable algorithm.
3. Check validity dates: the current time must fall within notBefore and notAfter for every certificate.
4. Check constraints: each issuer must have cA=TRUE and keyCertSign, the path length must respect pathLenConstraint, and names must fall within any nameConstraints.
5. Check purpose and name: the leaf EKU must include the purpose (serverAuth for a TLS server) and the hostname must match a SAN dNSName entry, as RFC 9525 requires.
6. Check revocation: where the client is configured to, consult the CRL or OCSP for each certificate.

Disabling any of these checks, for example verify=False in Python requests or InsecureSkipVerify: true in Go, turns TLS into encryption with an unknown party, and such settings are a common finding in code reviews and in the TLS Inspection Guide context, where middleboxes re-sign traffic with their own CA.

Revocation: CRL, OCSP and short lifetimes

Revocation tells relying parties to stop trusting a certificate before it expires, typically after key compromise, mis-issuance or decommissioning. Each mechanism has trade-offs.

The direction is clear. Baseline Requirements ballot SC063 made OCSP optional and required CRLs. Let's Encrypt removed OCSP URLs from its certificates on 7 May 2025 and turned off its responders on 6 August 2025, citing the privacy of OCSP lookups, and warned that non-browser software such as VPN clients must work without an OCSP URL. Ballot SC-081v3 then cuts the maximum public TLS lifetime to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. The operational impact of that schedule is covered in the Certificate Expiry Outages and 47-Day TLS Certificates Guide and is not repeated here. For private PKI, decide deliberately whether clients hard-fail when revocation data is unreachable; soft-fail means an attacker who can block the CRL or OCSP URL can keep a revoked certificate working.

Public and private PKI

A public CA is trusted by default in browsers and operating systems, but it can only certify names you can prove control of on the public internet, it must log certificates to Certificate Transparency, and it follows lifetimes the CA/Browser Forum sets. A private CA is trusted only by clients whose trust stores you control, which lets you set your own lifetimes, naming (internal hostnames, SPIFFE URIs, device serials) and policies.

Small organisations are usually best served by a managed private CA service from their cloud provider or by the CA built into their service mesh, plus a public CA through ACME. Large organisations typically run several private CAs (AD CS, a cloud CA, a mesh CA) and need central inventory and policy across them. AD CS brings specific risks, such as misconfigured certificate templates that let a user request a certificate for a domain admin; see the AD CS Security Guide.

Where identity fits

Most certificates in an enterprise identify machines, not people: web servers, microservices, Kubernetes workloads, devices, robots and build systems. Each one is a non-human identity whose credential is the private key. That means the same governance questions apply as for API keys and service accounts: who owns it, what it can reach, where the key is stored, how quickly it can be rotated and revoked. Attackers know this: ATT&CK T1649 Steal or Forge Authentication Certificates covers theft of certificates and keys and abuse of CA templates, and T1553.004 Install Root Certificate covers adding a rogue root to a trust store so attacker-issued certificates are accepted. Full lifecycle management, from request to retirement, is covered in the Machine Identity, PKI and Certificate Lifecycle Guide, and certificate-based service authentication in the mTLS Guide.

Building or fixing a PKI

1. Discover: scan networks and cloud accounts for TLS endpoints, export CA databases (AD CS, cloud CAs, mesh CAs), and query Certificate Transparency for your public domains. Record issuer, SAN, expiry, key type, owner and where the key lives.
2. Map trust stores: list which roots each platform trusts (Windows GPO-distributed roots, Linux CA bundles, Java cacerts, container base images, mobile apps that pin). Remove roots you cannot justify.
3. Design the hierarchy: offline root in an HSM, constrained issuing intermediates per purpose (server, client, device, code signing), CRL publication schedule and reachable CDP and AIA URLs.
4. Write the policy: approved algorithms and key sizes, maximum lifetimes per certificate type, who may request what, and SAN naming rules.
5. Pilot with automation: issue through ACME, the mesh or auto-enrolment to one application team or one site first, and run old and new chains in parallel by distributing the new root before any leaf depends on it.
6. Test revocation and rollover: revoke a test certificate and confirm clients reject it; rehearse replacing an intermediate. Practise before you need it.
7. Roll back safely: keep the previous chain trusted until the new one has served traffic for a full renewal cycle, so reverting is a configuration change rather than a reissue.

Detection and measurement

• Log: CA issuance and revocation events (on AD CS, Windows Security events 4886 request received and 4887 certificate issued), changes to CA templates and trust stores, CT log entries for your domains from CAs you do not use, and TLS handshake failures by reason.
• Metric: percentage of certificates in a central inventory with a named owner (target above 95 percent).
• Metric: percentage of certificates renewed automatically, by environment.
• Metric: certificates expiring within 30 days without a renewal in progress (target zero).
• Metric: certificates using SHA-1 signatures, RSA under 2048 bits or CN-only names (target zero).
• Metric: time to replace all certificates from one issuing CA in a drill, the best predictor of how a real CA compromise or distrust will go.

Framework mapping

Common failure patterns

• Incomplete chains: servers that send only the leaf work in browsers that fetch intermediates but fail in API clients and devices.
• Trusting too much: applications that accept any certificate from any public CA for client authentication, or that disable verification in code, let anyone with a valid certificate in.
• Online or exportable root keys: a root on a domain-joined server with a software key turns one server compromise into the ability to impersonate everything.
• Unreachable revocation: CDP or AIA URLs that point to an internal host unreachable from cloud or partner networks, combined with soft-fail, so revocation never actually happens.
• Shared certificates across customers or systems: one wildcard or one vendor certificate used everywhere means one theft affects every relationship.
• Single-CA dependence: hard-coded CA pinning or manual processes that make an emergency CA change, such as the Entrust distrust, take months.

Lessons from incidents

The Mimecast certificate compromise shows the cost of a single shared certificate. Mimecast issued one certificate that customers used to connect its services to Microsoft 365 Exchange; attackers who entered through the SolarWinds Orion backdoor stole it and used it from outside Mimecast's network to reach a small number of tenants. Microsoft blocked the certificate on 18 January 2021, and every customer had to delete their connection and re-establish it with a replacement. The PKI lessons are direct: issue per-customer, least-privilege, short-lived credentials, restrict where a certificate can be used from, and make revoke-and-replace a rehearsed operation rather than an emergency project.

Practitioner checklist

• Keep every root CA offline with its key in an HSM, used only to sign intermediates and CRLs.
• Issue from purpose-specific, technically constrained intermediates (EKU and name constraints).
• Put all names in SAN, set cA=FALSE on leaves and separate server, client and code signing certificates.
• Configure every server to send the full chain, and test with a non-browser client.
• Publish CRLs on a fixed schedule at URLs reachable from every client network, and decide hard-fail or soft-fail per use case.
• Check that software using public certificates works without OCSP URLs.
• Maintain one inventory across public and private CAs with owner, expiry, key location and trust store dependencies.
• Automate issuance and renewal (ACME, mesh, auto-enrolment) and alert on any certificate within 30 days of expiry without a renewal.
• Monitor CT logs for your domains and alert on CA template and trust store changes.
• Rehearse replacing an intermediate and switching public CA at least once a year.

Standards and references

• IETF: RFC 5280 Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• IETF: RFC 6960 Online Certificate Status Protocol (OCSP)
• IETF: RFC 9525 Service Identity in TLS
• IETF: RFC 8555 Automatic Certificate Management Environment (ACME)
• CA/Browser Forum: Baseline Requirements for TLS Server Certificates
• Mozilla: Root Store Policy
• NIST NCCoE: SP 1800-16 TLS Server Certificate Management
• Let's Encrypt: Ending OCSP Support in 2025

Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · mTLS Guide · AD CS Security Guide · Certificate Expiry Outages and 47-Day TLS Certificates Guide · Certificate Transparency Guide