Architecture guide

Reference PKI

From root trust to everyday operations: public key infrastructure (PKI) connects root trust, certificate issuance and operational ownership. Walk through the parts and the controls that connect them.

Why this matters. A hierarchy is only as strong as its root custody and the checks relying systems perform. The walkthrough shows where each control belongs.

Key terms 6

PKI: Public key infrastructure: the policies, systems and roles that issue, manage and revoke digital certificates.
Certificate authority (CA): An entity that issues certificates binding a public key to an identity.
CP/CPS: Certificate policy and certification practice statement: documents that set and describe how a CA issues and manages certificates.
Offline root: A root CA whose key is kept on a device with no network connection and used only to sign subordinate CAs or revocation lists.
Key ceremony: A scripted, witnessed procedure for generating or using a high-value key, often requiring several of a set of custodians (M of N) to be present.
Relying party: A system or person that accepts a certificate and must check it before trusting the identity it asserts.

Stage 1 of 5

Root trust

The root anchors the hierarchy. Its private key and signing process deserve explicit custody and recovery controls. Keeping the root offline, and bringing it online only in a witnessed ceremony to sign issuing authorities or revocation lists, limits how often that key is exposed.

Policy: Define certificate policy and responsibilities.
Key custody: Protect root key operations and record the ceremony.
Trust distribution: Distribute trust through an approved channel.

Read all PKI stages

Root trust
The root anchors the hierarchy. Its private key and signing process deserve explicit custody and recovery controls. Keeping the root offline, and bringing it online only in a witnessed ceremony to sign issuing authorities or revocation lists, limits how often that key is exposed.
- Define certificate policy and responsibilities.
- Protect root key operations and record the ceremony.
- Distribute trust through an approved channel.
Issuing authority
An issuing authority signs end-entity certificates under a constrained policy, keeping routine issuance separate from root operations. Name constraints and limited validity periods restrict what a compromised issuing authority could sign.
- Constrain issuance to intended identities and uses.
- Define enrolment authentication and approval.
- Monitor issuance and administrative changes.
Enrolment & renewal
Service owners request, deploy and renew certificates. Automation still needs clear ownership and failure handling.
- Map each certificate to an accountable service owner.
- Test renewal and deployment behaviour.
- Agree expiry alerts and recovery steps.
Relying-party checks
A relying party checks the chain, identity and applicable policy before accepting a certificate for its intended use.
- Check the chain against the intended trust anchor.
- Validate identity, validity period and allowed uses.
- Apply the system’s revocation requirements.
Operations & recovery
The hierarchy must remain understandable when a service fails, a key is replaced or trust needs to change.
- Maintain operational and incident runbooks.
- Test restore and key replacement processes.
- Review evidence and retire unused trust.

Start with the inventory

List trust anchors, issuing authorities, certificates, key stores and relying systems. Record an owner and a recovery path for each dependency.

Draft the engineering scope

Check the protocol details

The reference guide is deliberately general. Certificate profiles and path validation need the requirements of the actual protocols and relying parties.

RFC 5280: certificate and certificate revocation list profile

A reference, not a deployment claim

This guide does not represent a customer hierarchy, hardware partnership or certification. Review the intended controls and operational responsibilities before choosing a production design.