PKI and Certificate Glossary: CA, CSR, OCSP Terms

Certificate outages, failed audits and AD CS compromises often start with a misunderstanding of one term, such as treating "revoked" and "expired" as the same thing or not knowing which extension makes a certificate a CA. This glossary gives precise, practical definitions of the public key infrastructure (PKI) and certificate vocabulary that platform, security and identity teams meet when running TLS, mutual TLS, code signing, device certificates and workload identity. Definitions follow the IETF standards (RFC 5280 for X.509 certificates and CRLs, RFC 6960 for OCSP, RFC 8555 for ACME) and the CA/Browser Forum Baseline Requirements where they apply, and each entry says why the term matters operationally. It is for engineers, architects, auditors and anyone managing machine identities. For a narrative introduction read the PKI Basics Guide; broader identity and non-human identity terms are in the NHI and IAM Glossary.

A

ACME (Automatic Certificate Management Environment): The protocol defined in RFC 8555 that lets a client prove control of a domain name and obtain a certificate without manual steps. The client registers an account key, places an order for identifiers, completes a challenge for each authorisation, then finalises the order by submitting a CSR. Requests are signed JSON Web Signature objects with a server-issued nonce to stop replay. ACME is the main way organisations prepare for shorter TLS certificate lifetimes. See the ACME and Automated Certificate Management Guide.
ACME challenge (http-01, dns-01): The proof of control a client completes for an ACME authorisation. RFC 8555 defines http-01, where the client places a token at a well-known path on the web server, and dns-01, where it publishes a TXT record under the _acme-challenge name. Both use a key authorisation that combines the token with a thumbprint of the account key. dns-01 is the only one of the two that supports wildcard names, and it means the ACME client needs DNS write credentials, which are themselves a sensitive non-human credential to scope and protect.
AD CS (Active Directory Certificate Services): The Microsoft Windows Server role that runs an enterprise CA integrated with Active Directory, issuing certificates from templates for users, computers, domain controllers and services. Because AD CS certificates can be used to authenticate to the domain, misconfigured templates and CA permissions are a common route to domain compromise (MITRE ATT&CK T1649 Steal or Forge Authentication Certificates). See the AD CS Security Guide.
Authority Information Access (AIA): A non-critical X.509 extension (RFC 5280 section 4.2.2.1) that tells relying parties where to find information about the issuer: the issuing CA's certificate (the caIssuers access method) and the OCSP responder (the ocsp access method). Clients use the caIssuers URL to fetch a missing intermediate. Unreachable AIA URLs cause intermittent chain-building failures that are hard to diagnose.
Authority Key Identifier (AKI): An extension identifying the public key that corresponds to the private key used to sign a certificate or CRL. RFC 5280 requires conforming CAs to include the keyIdentifier field (self-signed certificates may omit it) and to mark the extension non-critical. Matching a certificate's AKI to its issuer's Subject Key Identifier helps clients choose the right issuer when a CA has renewed its key.

B to C

Basic constraints: The extension that says whether a certificate's subject is a CA. If the cA flag is not asserted, the keyCertSign key usage bit must not be set (RFC 5280 section 4.2.1.9). The optional pathLenConstraint limits how many non-self-issued intermediate CA certificates may follow in a path; zero means the CA may issue only end-entity certificates. A leaf certificate wrongly marked as a CA is a serious misissuance, because it can sign other certificates.
CAA (Certification Authority Authorization): A DNS record type, defined in RFC 8659 (which obsoletes RFC 6844), that names the CAs allowed to issue certificates for a domain. The issue tag authorises a CA, issuewild applies only to wildcard requests, and iodef gives a reporting address. A CA climbs from the requested name towards the parent domains and uses the first CAA record set it finds; if none exists, issuance is unrestricted. CAA is checked by CAs at issuance, not by browsers. The Baseline Requirements made CAA checking mandatory in 2017 and require DNSSEC validation of CAA lookups from 15 March 2026.
CA/Browser Forum: The industry body of certificate authorities and browser and operating system vendors that publishes the Baseline Requirements for publicly trusted TLS server certificates, plus separate requirements for code signing and S/MIME. Changes are made through numbered ballots. Version 2.3.1 of the TLS Baseline Requirements was effective from 4 October 2026 when checked in November 2026. See the CA/Browser Forum Baseline Requirements Guide.
Certificate authority (CA): An entity that signs certificates, binding a public key to a name and attributes after checking the request. A CA's trustworthiness rests on protecting its private key, usually in an HSM, and on following its published policy and practice statement. Public CAs are trusted by browsers and operating systems; private CAs are trusted only where an organisation distributes their root. See the Private CA Design and Operations Guide.
Certificate chain (certification path): The ordered list of certificates from an end-entity certificate through one or more intermediates to a trust anchor. Servers should send the leaf and intermediates, not the root. Many "works in the browser, fails in the API client" problems are missing intermediates: browsers may fetch them through AIA while libraries and appliances often do not.
Certificate lifecycle management (CLM): The discipline and tooling for discovering, requesting, issuing, deploying, renewing, revoking and retiring certificates across an estate, with an owner for each. CLM tooling holds powerful credentials for CAs and deployment targets, so it is itself a high-value system. See the Machine Identity, PKI and Certificate Lifecycle Guide and the certificate lifecycle manager compromise playbook.
Certificate pinning: Configuring a client to accept only a specific certificate, public key or issuer for a service, rather than any certificate that chains to a trusted root. Pinning reduces exposure to misissued certificates but makes rotation and CA changes risky: a pinned mobile app can break when a provider changes CA. Pin to keys you control, include backups, and avoid pinning to public leaf certificates with short lifetimes. See the Certificate Pinning guide.
Certificate policy (CP): A named set of rules saying what a certificate may be used for and under what assurance, identified by an object identifier carried in the certificatePolicies extension. RFC 5280 defines the anyPolicy OID 2.5.29.32.0 and the CPS pointer and user notice qualifiers. Public TLS certificates carry policy OIDs that show the validation level.
Certificate practice statement (CPS): The CA's document describing how it actually meets its certificate policy: identity checks, key protection, revocation, audit and personnel controls. Private CAs benefit from a short CPS too, because it forces decisions on who may request which certificate and how keys are protected. See the ISO/IEC 27099 PKI Practices and Policy Framework Guide.
Certificate revocation list (CRL): A list, signed by the CA, of serial numbers of revoked certificates that have not yet expired, with a thisUpdate and nextUpdate time. RFC 5280 defines reason codes from unspecified (0) to aACompromise (10), with value 7 unused. Since ballot SC063 took effect on 15 March 2024, the Baseline Requirements require publicly trusted CAs to publish CRLs and make OCSP optional. See the Certificate Revocation Guide.
CRL distribution point (CDP): The X.509 extension that tells a relying party where to download the CRL covering a certificate, normally an HTTP URL pointing to a DER-encoded CRL. If the CDP host is unreachable and the client treats revocation checking as mandatory, connections fail, so CDP availability is part of PKI uptime.
Certificate signing request (CSR): A request for a certificate, usually in the PKCS #10 format defined in RFC 2986. It contains a version, the requested subject name, the public key and optional attributes (requested extensions go in the extensionRequest attribute), signed with the matching private key. That signature proves the requester holds the private key, so the private key never leaves the requester. A CA should not trust any requested name or extension in a CSR without validating it: blindly honouring requested subject names is the root of several AD CS template weaknesses. See How to audit AD CS certificate templates.
Certificate template: In AD CS, the object that defines what a certificate issued from it will contain and who may enrol: key usage, extended key usage, validity, subject name source and approval requirements. Templates that allow a requester to supply the subject name and include client authentication are a well-documented escalation path.
Certificate Transparency (CT): A system of public, append-only logs of issued TLS certificates, so domain owners and browsers can detect misissuance. Logs are Merkle trees that support inclusion proofs (a certificate is in the log) and consistency proofs (the log has only been appended to). CT version 2.0 is RFC 9162, an Experimental RFC that obsoletes RFC 6962. Monitoring CT logs for your domains finds certificates you did not request. See the Certificate Transparency Monitoring Guide for Web Teams.
Code signing certificate: A certificate with the codeSigning extended key usage, used to sign software so that operating systems and users can verify the publisher and detect tampering. Theft of a code signing key lets attackers sign malware as a trusted publisher, which is why the private key should live in an HSM with signing gated by a pipeline. See the Code Signing Security Guide.
Common name (CN): An attribute of the subject distinguished name, historically used to carry a server's hostname. Modern clients match hostnames against the subject alternative name extension instead, and a certificate with the name only in the CN fails in many current libraries.
Cross-certificate (cross-signing): A certificate issued by one CA to another CA's public key, so certificates from the second CA can chain to the first CA's root. New public roots use cross-signs to be trusted on older devices before their own root is distributed. Cross-signs create alternative chains, which can surprise clients when one path expires.
Crypto-agility: The ability to change algorithms, key sizes, CAs and certificates quickly without redesigning systems. For PKI it depends on an accurate inventory, automation and avoiding hard-coded algorithms or pins. It is the practical foundation for post-quantum migration. See the Crypto-Agility Guide.
Cryptoperiod: The time span during which a specific key is authorised for use. NIST SP 800-57 Part 1 Rev. 5 gives guidance on setting cryptoperiods by key type. For certificates, the certificate's validity should not exceed the cryptoperiod of its key, and CA keys typically have far longer cryptoperiods than leaf keys, which is why CA key protection matters so much.

D to H

DER and PEM: The two common encodings of certificates and keys. DER is the binary ASN.1 encoding; PEM is DER encoded in Base64 between header lines such as -----BEGIN CERTIFICATE-----. A file extension (.crt, .cer, .pem) does not reliably tell you the encoding, which causes many import errors. See the Certificate and Key File Formats guide.
Delta CRL: A CRL that lists only changes since a referenced base CRL, carrying a critical delta CRL indicator extension. The Freshest CRL extension in a certificate points to where delta CRLs are published. Delta CRLs keep downloads small for large CAs but add another URL that must stay available.
Distinguished name (DN): The structured X.500 name in a certificate's subject and issuer fields, made of attributes such as CN, O (organisation), OU and C (country). The issuer DN of a certificate must match the subject DN of its issuer for chain building.
Domain validation (DV): The lowest validation level for public TLS certificates: the CA checks only that the applicant controls the domain name, for example through an ACME challenge or a DNS record. Organisation validated (OV) and extended validation (EV) certificates add checks on the legal entity. The Baseline Requirements limit how long domain validation evidence may be reused: 200 days from 15 March 2026, 100 days from 15 March 2027 and 10 days from 15 March 2029.
EST (Enrolment over Secure Transport): An IETF protocol (RFC 7030) for devices and services to enrol for certificates over HTTPS, with optional TLS client authentication for re-enrolment. It is a more modern alternative to SCEP for network equipment and IoT devices. See the IoT and Device Certificate Provisioning (EST, SCEP) Guide.
EV certificate (extended validation): A public TLS certificate issued after the most extensive identity checks on the organisation. Browsers no longer show a distinctive EV indicator in the address bar, so EV now mainly matters for contractual or regulatory requirements rather than user trust signals.
Extended key usage (EKU): An extension listing the purposes a certificate's key may be used for, such as serverAuth, clientAuth, codeSigning, emailProtection, timeStamping and OCSPSigning. When both key usage and EKU are present, the certificate may be used only for purposes consistent with both (RFC 5280 section 4.2.1.12). The anyExtendedKeyUsage value removes the restriction, which is dangerous on CA or template configurations because the certificate can then be used for client authentication.
Hardware security module (HSM): A tamper-resistant device or cloud service that generates and stores private keys and performs signing inside a protected boundary, so keys are not exported in clear text. Root and issuing CA keys and code signing keys should be held in HSMs validated to FIPS 140-3 or an equivalent scheme. The HSM's administrator credentials and partition passwords are critical secrets in their own right. See the HSM Deployment and Operations Guide.

I to L

Intermediate CA (subordinate CA): A CA whose certificate is signed by a root or another intermediate and which issues certificates to end entities or further CAs. Keeping the root offline and issuing from intermediates limits the damage if an issuing key is compromised: the intermediate can be revoked without replacing the root in every trust store. See the Enterprise PKI Design and CA Hierarchy Guide.
Issuing CA: The CA that signs end-entity certificates. It is online by necessity, which makes its key, its enrolment interfaces and the accounts allowed to request certificates the most exposed part of a private PKI. See Securing the internal PKI and certificate authority itself.
Key ceremony: A scripted, witnessed and recorded procedure for generating or using a high-value key, typically a root CA key, with split knowledge across several custodians. The evidence (scripts, video, signed attendance) supports audits and later trust decisions.
Key escrow (key archival): Storing a copy of a private key with a trusted party so encrypted data can be recovered. It is appropriate for encryption keys, such as S/MIME decryption keys, but should not be used for signing or authentication keys, where a second copy undermines non-repudiation and widens the attack surface.
Key usage: The extension restricting the cryptographic operations a key may perform. RFC 5280 defines nine bits: digitalSignature, nonRepudiation (renamed contentCommitment), keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly and decipherOnly. keyCertSign and cRLSign belong only on CA certificates.

M to N

Machine identity: The credentials that let devices, workloads and software prove who they are to each other, most often X.509 certificates and keys, but also SSH keys and signed tokens. In this vocabulary, certificates are one kind of non-human identity credential, and they need the same owner, inventory and lifecycle discipline as API keys or service accounts. See Machine Identity vs Workload Identity vs NHI.
Mutual TLS (mTLS): TLS in which both sides present certificates, so the server authenticates the client as well as the reverse. It is widely used for service-to-service authentication, device access and service meshes. The hard parts are issuing, rotating and revoking large numbers of client certificates and mapping certificate identities to authorisation decisions. See the mTLS Guide.
Must-Staple: A certificate extension (the TLS Feature extension, RFC 7633) telling clients to expect a stapled OCSP response and to reject the connection if none is provided. With OCSP now optional for public CAs and some CAs ending OCSP services, check whether your CA still supports it before relying on it.
Name constraints: A critical extension, used only in CA certificates, that lists permitted and excluded name spaces for certificates further down the chain. Excluded subtrees take precedence over permitted ones. A DNS constraint of example.com matches the name and its subdomains. Name constraints let an organisation hold a subordinate CA that can issue only for its own domains, which limits the impact if that CA is misused.

O to P

OCSP (Online Certificate Status Protocol): The protocol in RFC 6960 for asking a responder whether one certificate is revoked. Responses are good, revoked or unknown, are signed by the CA or by a delegated responder holding a certificate with the OCSPSigning EKU, and carry thisUpdate and nextUpdate times. Requests run over HTTP. Because OCSP exposes which sites a client visits to the CA, and because the Baseline Requirements made it optional in 2024, some public CAs have announced the end of their OCSP services and rely on CRLs instead.
OCSP stapling: The server fetches a signed OCSP response for its own certificate and sends it during the TLS handshake, so clients do not contact the responder themselves. It improves privacy and performance; it fails silently if the server cannot refresh the response, so monitor staple freshness where it is used.
Path validation: The algorithm in RFC 5280 section 6 that a relying party runs to decide whether a certificate chain is acceptable: signatures, validity periods, basic constraints and path length, name constraints, policies, key usage and revocation status. A certificate that contains a critical extension the client does not recognise must be rejected. Disabling validation in code ("verify=false") is one of the most common and dangerous shortcuts in service-to-service code.
PKCS #12 (PFX): A password-protected container format that bundles a private key with its certificate and chain, commonly with a .pfx or .p12 extension. PKCS #12 files left on file shares, in repositories or in tickets are a frequent source of key exposure, and older files may use weak encryption. Treat them as secrets. See the Leaked TLS Private Key Response guide.
Post-quantum cryptography (PQC): Public key algorithms designed to resist attack by a large quantum computer, such as the NIST-standardised ML-KEM for key establishment and ML-DSA and SLH-DSA for signatures. For PKI, PQC means new key and signature types in certificates, larger certificates and chains, and a long transition that depends on crypto-agility. See the Post-Quantum Cryptography Migration Guide.
Precertificate: In Certificate Transparency, a signed statement of the CA's intent to issue a certificate, submitted to logs before the final certificate exists so the returned signed certificate timestamps can be embedded in it.
Private CA (private PKI): A CA whose root is trusted only by systems an organisation controls, used for internal TLS, mTLS, device, VPN, Wi-Fi and workload certificates. It is not bound by the Baseline Requirements, so the organisation sets its own lifetimes and profiles, and it must distribute its root to every relying system. See the Private CA Design and Operations Guide.
Private key: The secret half of a key pair. Whoever holds it can act as the certificate's subject until the certificate expires or is revoked, so the private key, not the certificate, is what must be protected. Generate keys where they will be used, mark them non-exportable where the platform allows, and never send them by email or chat.
Public CA: A CA whose roots are included in browser and operating system trust stores and which must follow the CA/Browser Forum requirements and root programme policies. Public certificates are logged in Certificate Transparency, so they reveal hostnames: avoid public certificates for internal-only names you do not want disclosed.
Public key infrastructure (PKI): The policies, roles, CAs, registration authorities, repositories, protocols and relying-party software that together issue, manage, validate and revoke certificates. A PKI is as strong as its weakest operational process, which is usually enrolment authorisation or key protection rather than cryptography. See the PKI Basics Guide.

R to S

Registration authority (RA): The function that verifies a requester's identity or entitlement before the CA issues a certificate. In automated environments the RA is often software, such as an ACME server's authorisation logic or an AD CS template's enrolment permissions, which means RA mistakes scale instantly.
Revocation: Declaring a certificate invalid before its expiry, for example after key compromise, misissuance or decommissioning, and publishing that status through CRLs or OCSP. Revocation only protects clients that check it; short certificate lifetimes reduce how long a revoked but unchecked certificate stays usable.
Root CA: The top CA in a hierarchy, with a self-signed certificate that relying parties hold as a trust anchor. Root keys are normally kept offline in an HSM and used only in key ceremonies to sign intermediates and CRLs. Replacing a root means redistributing trust to every relying system, which can take years for public roots. See Certificate trust stores and root CA management.
SCEP (Simple Certificate Enrolment Protocol): An older enrolment protocol, published as RFC 8894, widely used by mobile device management and network equipment. Enrolment is often authorised by a shared challenge password, which must be treated as a secret and scoped, because anyone holding it can request certificates.
Self-signed certificate: A certificate signed with its own private key, so the issuer and subject are the same. Roots are self-signed by design; self-signed leaf certificates on servers train users and code to skip validation and are hard to inventory or revoke.
Short-lived certificates: Certificates with lifetimes short enough that revocation matters less because they expire quickly, from minutes for workload certificates to days for public TLS. Public TLS lifetimes are falling under the Baseline Requirements: a maximum of 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Short lifetimes make automation mandatory. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
Signed certificate timestamp (SCT): A Certificate Transparency log's signed promise to include a submitted certificate or precertificate. SCTs are delivered embedded in the certificate, in a TLS extension or in a stapled OCSP response, and browsers that enforce CT require them for publicly trusted certificates.
SPIFFE ID and SVID: In the SPIFFE standard for workload identity, a SPIFFE ID is a URI of the form spiffe://trust-domain/workload-path, and an SVID (SPIFFE Verifiable Identity Document) is the document that proves it: an X.509-SVID certificate or a JWT-SVID token. Workloads obtain SVIDs and trust bundles from the Workload API, with keys rotated automatically, so no long-lived secret has to be placed in the workload. See the SPIFFE and SPIRE Guide.
Subject Key Identifier (SKI): An extension that identifies certificates containing a particular public key. RFC 5280 requires it in CA certificates and recommends it in end-entity certificates, and suggests deriving it from a SHA-1 hash of the public key.
Subject alternative name (SAN): The extension that binds identities to a certificate: DNS names, IP addresses, email addresses, URIs (as used for SPIFFE IDs) and other name forms. If the subject DN is empty the SAN must be present and critical. Hostname verification uses the SAN, and every name in it is equally trusted, so long multi-domain SAN lists widen the impact of one key compromise.

T to Z

TLS (Transport Layer Security): The protocol that encrypts and authenticates connections, using certificates for server (and in mTLS, client) authentication. TLS 1.3 is the current version; TLS 1.0 and 1.1 are deprecated. See the How TLS Works Guide.
Trust anchor: A public key and name, usually held as a root certificate, that a relying party trusts without further validation and uses as the starting point for path validation. Every trust anchor in a store can vouch for any name unless constrained, so unnecessary anchors are unnecessary risk.
Trust bundle: A set of CA certificates distributed to workloads so they can validate peers, as in SPIFFE trust bundles or Kubernetes ClusterTrustBundles. Bundles must be updated before a CA rotation completes, or workloads will reject newly issued certificates. See the Kubernetes Pod Certificates and ClusterTrustBundles Guide.
Trust store: The collection of trust anchors a system or application accepts. Operating systems, browsers, language runtimes such as Java, and container images often each have their own trust store, which is why adding a private root "everywhere" is harder than it sounds.
Wildcard certificate: A certificate for a name such as *.example.com, valid for any single label at that position. Convenient, but the same key is then deployed on many servers, so one compromised host exposes every service the wildcard covers. Prefer per-service certificates once issuance is automated.
Workload identity: An identity issued to a running piece of software, such as a container, function or virtual machine, based on attested properties of where it runs rather than a stored secret. X.509 certificates are a common carrier for workload identity in service meshes and SPIFFE deployments. See SPIFFE vs Cloud-Native Workload Identity.
X.509 certificate: The certificate format profiled for the internet in RFC 5280: a signed structure containing a version, serial number, signature algorithm, issuer, validity period, subject, subject public key and extensions. Serial numbers are positive integers unique per CA and no longer than 20 octets. Almost every term on this page describes a field, an extension or a process around this structure.

PKI and Certificate Glossary: CA, CSR, OCSP and Machine Identity Terms

A