Certificate Policy and Practice Statement (CP/CPS)

A Certificate Policy (CP) is a document that states the rules and requirements for certificate issuance, management, and use within a PKI. A Certification Practice Statement (CPS) describes how a specific CA implements those rules — the actual procedures, controls, and technologies used. Think of the CP as the contract (“we will verify domain ownership before issuance”) and the CPS as the operations manual (“we verify domain ownership using HTTP-01 challenge validated from 3 geographic locations within 30 seconds”).

Why it matters

• Audit requirement — public CAs must pass annual WebTrust or ETSI audits against their published CPS. Failure means removal from browser trust stores. The CPS is the document auditors test against.
• Liability boundaries — the CP defines what the CA is responsible for and what it isn’t. If a certificate is mis-issued, the CP determines whether the CA violated its own policy (liability) or the subscriber misused the certificate (not the CA’s problem).
• Relying party decisions — when an organization decides whether to trust a CA, they review the CP/CPS. It tells them: what validation is performed, how keys are protected, what happens during compromise, and how long revocation takes.
• Incident response — when something goes wrong (mis-issuance, key compromise, operational failure), the CPS defines the response procedures. Without it, incident response is ad-hoc and inconsistent.
• Interoperability — when two organizations cross-certify or federate their PKIs, they compare CP/CPS documents to ensure compatible security levels. You don’t cross-certify with a CA whose practices are weaker than yours.

How it works

1. CP is written — defines certificate types, validation levels, key requirements, validity periods, revocation timelines, and subscriber obligations. Follows RFC 3647 framework (12 sections).
2. CPS implements the CP — maps each CP requirement to specific procedures, systems, and controls. Includes: physical security, key ceremony procedures, CA system architecture, personnel controls.
3. CA operates per CPS — all issuance, renewal, revocation, and key management follows documented procedures.
4. Auditors verify — annual audit (WebTrust for CAs, ETSI EN 319 411) tests whether actual operations match the CPS.
5. CP/CPS published — public CAs publish their CPS (usually as a PDF on their website). Private CAs distribute internally.
6. Updates versioned — changes to CP/CPS are versioned, dated, and (for public CAs) reviewed by the CA/Browser Forum community.

RFC 3647 framework sections:

• Introduction and scope
• Publication and repository responsibilities
• Identification and authentication
• Certificate lifecycle operational requirements
• Facility, management, and operational controls
• Technical security controls
• Certificate, CRL, and OCSP profiles
• Compliance audit and assessments
• Other business and legal matters

In real systems

Let’s Encrypt CPS (public CA):

• Published at: https://letsencrypt.org/repository/
• Validation: DV only (domain control via ACME challenges)
• Key protection: Root keys in offline HSMs, ceremony requires multiple key holders
• Revocation: within 24 hours of confirmed mis-issuance
• Certificate lifetime: 90 days maximum
• Audited annually against WebTrust for CAs

Enterprise private CA (Microsoft AD CS): Most enterprise CAs operate without a formal CP/CPS — this is a gap. A minimal enterprise CPS should document:

- Who can request certificates (enrollment permissions)
- What templates are available and their key requirements
- How the CA private key is protected (HSM? Software?)
- Who has admin access to the CA
- What happens if the CA key is compromised
- Certificate validity periods per template
- Revocation procedures and CRL publication schedule

CA/Browser Forum Baseline Requirements: The Baseline Requirements (BRs) function as a shared CP for all publicly-trusted CAs. Every public CA’s CPS must implement at least the BR requirements. BRs specify: maximum validity (398 days), required validation methods, key size minimums (RSA 2048+), and incident reporting timelines (24 hours for mis-issuance).

Where it breaks

CPS says one thing, operations do another — the CPS states “private keys are stored in FIPS 140-2 Level 3 HSMs.” In practice, a developer copied the CA key to a software keystore for testing and never removed it. The CPS is technically accurate for production, but the unprotected copy exists. Auditors test against the CPS — if they don’t discover the copy, the gap persists until exploitation. This is how DigiNotar was compromised: their CPS described strong controls, but actual implementation had critical gaps.

No CPS for enterprise CA — an organization runs Microsoft AD CS issuing certificates for 5,000 employees and 200 servers. There’s no CP/CPS document. When the CA server is compromised, there’s no documented incident response procedure. Nobody knows: which certificates were issued, what the blast radius is, whether the root key was exposed, or how to communicate the compromise to relying parties. Recovery is chaotic and incomplete.

CP/CPS not updated after architecture changes — the CPS describes a 2-tier hierarchy with an offline root. The team migrates to AWS Private CA (online root, cloud-managed). The CPS still describes the old architecture. During the next audit, the discrepancy is flagged — either the CPS must be updated or the architecture must revert. Keeping CP/CPS synchronized with actual infrastructure is ongoing work, not a one-time effort.

Operational insight

For private/enterprise CAs, the CP/CPS doesn’t need to be a 100-page legal document. A 5-10 page operational document covering: who can issue certificates, what key protections exist, how revocation works, and what happens during compromise is sufficient. The value isn’t in the document’s length — it’s in forcing the team to explicitly decide and document these answers before an incident requires them. Most enterprise PKI failures aren’t technical — they’re procedural gaps that a simple CPS would have prevented.

Related topics

• What is a Certificate Authority
• Root CA vs Intermediate CA
• PKI Trust Models
• CA/Browser Forum Baseline Requirements
• Public CA vs Private CA