Public Key Infrastructure and Certificate Management

Introduction and Context

Public key cryptography solves an important problem in cybersecurity: how can two parties communicate securely when they have not previously shared a secret key? A public key may be distributed widely, while its corresponding private key is kept secret. However, public key cryptography alone does not prove that a public key belongs to the person, organization, server, or device claiming it.

Public Key Infrastructure (PKI) is the organizational, technical, and procedural system used to create, distribute, validate, protect, renew, suspend, and revoke digital certificates and their associated keys. PKI supports encrypted web connections, secure email, virtual private networks, code signing, identity badges, device authentication, and many enterprise access-control systems.

PKI is not simply a software product. It is a trust-management system. Its security depends on cryptographic algorithms, certificate profiles, operational procedures, identity verification, key protection, audit controls, incident response, and decisions about whom to trust.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the roles of public keys, private keys, certificates, and certificate authorities.
2. Describe the components and trust model of PKI.
3. Interpret a certificate chain and explain chain validation.
4. Describe certificate issuance, renewal, suspension, and revocation.
5. Compare Certificate Revocation Lists, Online Certificate Status Protocol, and certificate transparency.
6. Identify operational, governance, and security risks in PKI deployment.
7. Apply PKI concepts to an organizational scenario.

1. Public-Key Foundations

A public-key system uses a mathematically related key pair:

• The public key may be shared with other parties.
• The private key must remain confidential and under the control of its owner.

For confidentiality, a sender encrypts data using the recipient’s public key; only the recipient’s private key should be able to decrypt it. For digital signatures, the signer uses the private key and others verify the signature using the corresponding public key.

A digital signature provides three main properties:

• Integrity: evidence that signed data has not been altered.
• Authenticity: evidence that the holder of the private key created the signature.
• Non-repudiation, in a qualified sense: evidence that can support attribution, subject to key protection, legal rules, and organizational controls.

A digital signature does not automatically prove the real-world identity of the signer. That connection requires a trusted binding between an identity and a public key. A digital certificate provides this binding.

2. Digital Certificates

A digital certificate is a digitally signed data structure that associates an identity with a public key. Most Internet certificates use the X.509 certificate format, standardized through profiles developed by the Internet Engineering Task Force and related standards organizations.

An X.509 certificate commonly contains:

A certificate does not contain the subject’s private key. The private key is generated and protected separately, ideally by the subject or its hardware security module. Possession of a certificate is therefore not sufficient for authentication; the claimant must also demonstrate control of the corresponding private key.

Names and Certificate Scope

For a web server, the names that the certificate authenticates are normally placed in the Subject Alternative Name extension. A browser compares the requested hostname with these names. A certificate issued to portal.example.org should not automatically authenticate payments.example.org unless the latter name is also authorized by the certificate’s names and issuance policy.

Certificates may be issued for:

• Individual users
• Web servers and APIs
• Organizations
• Devices and machines
• Software publishers
• Email addresses
• Intermediate certificate authorities

The intended use is constrained by extensions such as Key Usage and Extended Key Usage. For example, a certificate intended for server authentication should not automatically be accepted for code signing.

3. The Main Components of PKI

Certificate Authority

A Certificate Authority (CA) is an entity trusted to issue and sign certificates. It verifies an applicant according to a defined policy before issuing a certificate. A CA may be operated by a commercial provider, a government, an industry consortium, or an organization for internal use.

A CA normally performs or oversees:

1. Applicant identification or authorization.
2. Public-key and certificate-request processing.
3. Certificate issuance and signing.
4. Publication of certificates and status information.
5. Renewal, replacement, suspension, and revocation.
6. Record keeping, auditing, and incident response.

Root CA and Intermediate CA

A root CA is a trust anchor. Its public key is distributed through operating systems, browsers, applications, or organizational configuration. A root certificate is commonly self-signed, but its trust comes from deliberate installation and governance rather than from its self-signature.

An intermediate CA is certified by a root CA or another higher-level CA. It issues end-entity certificates and reduces the need to use the root private key frequently. A typical hierarchy is:

Figure: A hierarchical certificate chain from a root CA to an end-entity certificate.

The root private key is highly sensitive. It is often kept offline or protected by strict multi-person controls. Intermediate CAs handle routine issuance, while the root is used less frequently.

Registration Authority

A Registration Authority (RA) performs identity verification and authorization on behalf of a CA. It may verify documents, confirm control of a domain, validate an employee’s status, or check that a device belongs to the organization. Separating registration from signing can improve operational control, although the CA remains responsible for its issuance system and policy.

Repository and Relying Party

A repository publishes certificates, certificate policies, and revocation information. A relying party is a user, device, application, or service that decides whether to trust a certificate. Browsers, operating systems, email applications, VPN gateways, and enterprise services can all act as relying parties.

4. Certificate Policies and Assurance

A certificate is meaningful only within a policy context. A Certificate Policy (CP) describes the requirements and intended assurance of a certificate type. A Certification Practice Statement (CPS) explains how the CA implements those requirements.

Different certificates may require different levels of verification. Domain validation may establish control over a domain name, but it does not necessarily establish the legal identity of an organization. Organization validation may include business-record checks, while individual certificates may require stronger identity proofing.

The principle of least trust is important: a relying party should accept only the certificate purposes, identities, and authorities necessary for the task. Trusting every certificate for every purpose increases the impact of a CA compromise or configuration error.

5. Certificate Issuance and Lifecycle Management

A typical lifecycle contains the following stages:

1. Key generation: The subject generates a key pair, preferably in a protected device or hardware security module.
2. Certificate signing request: The subject submits a request containing the public key, requested names, and other attributes. The request is signed using the private key to demonstrate possession.
3. Identity and authorization validation: The CA or RA verifies the request according to policy.
4. Issuance: The CA creates and signs the certificate.
5. Deployment: The certificate and certificate chain are installed in the relevant service.
6. Monitoring: Expiration dates, cryptographic algorithms, names, and status are monitored.
7. Renewal or replacement: A new certificate is issued before expiration or after a planned key rotation.
8. Revocation: The certificate is invalidated early if its private key is compromised, its information is incorrect, or its authorization ends.
9. Archiving and destruction: Records are retained as required, and obsolete private keys are securely destroyed when appropriate.

Automation is valuable because certificates are numerous and often short-lived. However, automation must be governed. A flawed automated process can issue certificates to unauthorized systems at machine speed.

Key Protection

The private key is the most critical asset associated with a certificate. Controls include:

• Hardware security modules for high-value CA keys.
• Trusted platform modules or secure elements for devices.
• Strong access control and separation of duties.
• Encrypted backups with controlled recovery procedures.
• Logging of key use and administrative actions.
• Secure destruction when keys are retired.

A certificate should be revoked when its private key may have been exposed, even if misuse has not yet been observed.

6. Certificate Chain Validation

A relying party does not merely check whether a certificate is signed. It constructs and validates a certification path. Important checks include:

1. Signature verification: Each certificate’s signature is verified using the issuer’s public key.
2. Chain construction: The issuer and subject relationships form a path to a configured trust anchor.
3. Validity time: The current time falls within the certificate’s validity interval, subject to clock accuracy and local rules.
4. Name matching: The requested identity matches the permitted names, commonly in Subject Alternative Name.
5. Basic constraints: A certificate is allowed to act as a CA only if the relevant extension permits it.
6. Path length constraints: Restrictions on the number of subordinate CA levels are respected where specified.
7. Key usage: The certificate is being used for an authorized purpose.
8. Revocation status: Available revocation information does not indicate that the certificate is revoked.
9. Algorithm and policy checks: The algorithms, key sizes, policies, and critical extensions meet the relying party’s requirements.

A chain can be cryptographically valid but still unacceptable. For example, it may contain a valid signature but authenticate the wrong hostname, use a prohibited algorithm, or terminate at a root that the organization does not trust.

Trust Stores

A trust store is a collection of trusted root certificates and related configuration. Trust stores differ between operating systems, browsers, programming libraries, containers, and enterprise appliances. Updating a trust store can add or remove trust across many services, so changes require testing and change control.

7. Revocation and Status Checking

Certificates have an expiration date, but expiration is not sufficient for all incidents. A certificate may need to be invalidated immediately because a private key was stolen, a domain changed ownership, an employee left an organization, or a CA issued the certificate incorrectly.

Certificate Revocation Lists

A Certificate Revocation List (CRL) is a signed list of revoked certificate serial numbers published by a CA. CRLs can be effective and auditable, but large lists may consume bandwidth and may not be retrieved frequently enough to reflect recent events.

Online Certificate Status Protocol

OCSP allows a relying party to query a responder about a certificate’s status. It can provide fresher and smaller responses than a CRL. Its limitations include responder availability, privacy concerns because the responder may learn which sites a user visits, and the risk that applications fail open or fail closed when the responder cannot be contacted.

OCSP stapling allows a server to obtain a signed status response and send it to clients during a secure connection. This reduces direct client queries and can improve privacy and performance, but it requires correct server operation and timely response renewal.

Revocation Failure Policies

A fail-open implementation continues to trust a certificate when status information cannot be obtained. This improves availability but can weaken security. A fail-closed implementation rejects the certificate when status cannot be checked. This improves protection against unknown revocation but can cause outages. The appropriate choice depends on the service, threat model, and availability requirements.

8. Certificate Transparency

Certificate Transparency (CT) is a public accountability system for publicly trusted certificates. Participating CAs submit certificates or precertificates to append-only, cryptographically verifiable logs. Monitoring systems can search these logs for unexpected certificates issued for an organization’s domains.

CT does not itself decide whether a certificate is valid, and it does not replace revocation. Its purpose is to make public issuance observable and to help detect misissuance. A domain owner should monitor CT logs, investigate unauthorized certificates, and maintain a documented response process.

The principal benefits are:

• Visibility into certificates issued for organizational domains.
• Public detection of CA mistakes and abuse.
• Greater accountability for publicly trusted CAs.
• Evidence that supports investigation and incident response.

CT has boundaries. It is mainly associated with publicly trusted certificates, and detection does not automatically prevent exploitation. An organization must still discover, assess, and respond to suspicious entries.

9. Operational and Security Risks

PKI failures often result from operations rather than from broken cryptographic mathematics.

Common Risks

• Private-key compromise: Attackers can impersonate the certificate subject until detection and revocation.
• Root CA compromise: A compromised root can undermine a large trust domain and require emergency trust-store changes.
• Incorrect issuance: Weak domain or identity validation can produce certificates for unauthorized parties.
• Certificate expiration: An expired certificate can interrupt websites, APIs, VPNs, and automated processes.
• Inaccurate inventories: Unknown certificates cannot be renewed or revoked reliably.
• Clock errors: Incorrect system time can make valid certificates appear expired or not yet valid.
• Weak algorithms: Obsolete algorithms or inadequate key sizes can reduce security.
• Misconfigured chains: Missing intermediate certificates or incorrect server configuration can cause client failures.
• Overly broad trust: Installing unnecessary roots increases the attack surface.
• Poor backup and recovery: Loss of CA keys or databases may prevent issuance, renewal, or validation services from operating.
• Inadequate separation of duties: One administrator who can approve identities, issue certificates, and alter logs represents excessive power.
• Third-party dependence: External CAs, cloud platforms, and managed services introduce supply-chain and availability risks.

Governance Controls

A mature PKI program should define ownership, certificate classes, approval requirements, key-generation standards, renewal windows, revocation authority, audit retention, incident playbooks, and exception handling. High-impact operations should require dual control or multi-person authorization.

Organizations should maintain a complete certificate inventory containing at least the subject names, issuing CA, owner, environment, expiration date, algorithm, key location, deployment points, and revocation contact. Discovery tools can help, but ownership data and business context still require governance.

10. Ethical, Legal, and Regulatory Considerations

Certificate issuance involves personal and organizational identity data. A CA or enterprise PKI should collect only information necessary for its stated purpose, protect registration records, restrict administrative access, and retain evidence according to applicable law and policy.

TLS interception systems, sometimes used for enterprise inspection, create additional ethical and security concerns. They terminate and re-encrypt connections, which means the organization can access sensitive content and becomes responsible for protecting new private keys and inspection logs. Such systems should have clear authorization, narrow scope, strong access controls, transparency where appropriate, and carefully defined exclusions for sensitive services.

Digital signatures may have legal significance, but technical evidence alone does not settle questions of intent, authority, or repudiation. Legal and compliance teams should define how certificates, signing keys, timestamps, and audit records are used as evidence.

11. Contemporary Developments

Modern PKI increasingly emphasizes automation, short certificate lifetimes, cloud-native workloads, and machine identities. Protocols such as ACME support automated certificate issuance and renewal for approved domains. Short-lived certificates can reduce the time available for misuse, but they make monitoring and automation essential.

Organizations are also adopting workload identity systems that issue certificates or tokens to services dynamically. These systems can reduce dependence on long-lived static credentials but introduce new control-plane risks. Strong authentication of workloads, secure bootstrap processes, policy enforcement, and reliable recovery remain necessary.

Post-quantum cryptography may eventually require changes to certificate algorithms and key formats. Migration planning should include cryptographic inventories, algorithm agility, testing, and awareness of certificate-size and performance effects. The existence of a future threat does not justify untested deployment of immature algorithms; it justifies preparation and controlled evaluation.

Artificial intelligence can assist with certificate discovery, anomaly detection, renewal forecasting, and identification of unusual issuance patterns. It should not receive unrestricted authority to issue certificates or alter trust anchors. Human accountability, approval policies, explainable alerts, and audit logs remain essential.

12. Illustrative Case: Hospital API Certificate Failure

Background

A regional hospital operates patient portals, laboratory APIs, medical devices, and remote-access services. Its public web certificates are managed by an external CA, while internal device certificates are issued by an enterprise CA.

Problem

A laboratory integration stops accepting results after a certificate expires. Investigation reveals that the certificate was owned by a contractor who had left the organization. The enterprise had no complete certificate inventory, and renewal notifications were sent to an inactive mailbox. In addition, a separate internal CA had issued device certificates without consistent revocation procedures.

Analysis

The immediate failure was expiration, but the underlying causes were governance failures: unclear ownership, weak asset inventory, dependence on manual reminders, and inconsistent lifecycle policy. The incident also demonstrated that certificate availability is part of clinical-service availability.

Approach and Solution

The hospital creates a central certificate inventory and assigns a business and technical owner to every certificate. Automated discovery scans public endpoints, internal services, containers, and device-management systems. Renewal automation is introduced for eligible services, with alerts at multiple intervals and escalation to service owners.

The hospital separates root and intermediate CA functions, places high-value CA keys in hardware security modules, and defines certificate profiles for servers, users, and devices. Device certificates receive shorter lifetimes and are revoked automatically when devices are retired. Change management requires testing of new chains and trust-store changes before production deployment.

The security team also monitors public CT logs for hospital domains and maintains an incident procedure for suspected misissuance or private-key compromise.

Outcome

The hospital reduces unexpected expirations, improves ownership visibility, and can revoke device certificates more consistently. It also identifies a limitation: automation cannot compensate for inaccurate service inventories or poorly defined authority to approve certificates.

Learning Points

1. Certificate management is an availability and governance issue, not only a cryptographic issue.
2. Every certificate needs an accountable owner and documented purpose.
3. Automation should be combined with approval controls, monitoring, and recovery procedures.
4. Root-key protection and separation of duties reduce the impact of compromise.
5. Revocation and CT monitoring require an operational response, not merely technical configuration.

13. PKI Deployment Best Practices

A practical PKI program should:

• Define certificate policies and intended assurance levels.
• Use strong, currently approved algorithms and plan for algorithm migration.
• Protect CA private keys with hardware-backed controls and multi-person authorization.
• Keep root CAs offline or otherwise strongly isolated when operationally appropriate.
• Use intermediate CAs for routine issuance.
• Maintain an accurate, continuously updated certificate inventory.
• Automate issuance and renewal while preserving approval and audit controls.
• Monitor expiration, failed renewals, unusual issuance, and trust-store changes.
• Test revocation, backup restoration, CA compromise response, and emergency replacement.
• Limit trust stores to required roots and review them periodically.
• Match names, key usage, and certificate policies to the actual service purpose.
• Document fail-open and fail-closed decisions for status checking.
• Monitor CT logs for public organizational domains.
• Train administrators and service owners in certificate lifecycle responsibilities.

Chapter Summary

Public Key Infrastructure establishes managed trust between identities and public keys. Digital certificates bind a subject to a public key through a CA’s signature, while certificate policies define the assurance and permitted uses of that binding. Root CAs act as trust anchors, intermediate CAs perform routine issuance, and relying parties validate certificate chains by checking signatures, names, validity periods, constraints, key usage, policies, and revocation status.

Certificate management extends throughout the lifecycle: key generation, identity verification, issuance, deployment, monitoring, renewal, revocation, archiving, and destruction. CRLs, OCSP, and OCSP stapling provide mechanisms for learning certificate status, while Certificate Transparency improves accountability for publicly trusted certificates. PKI deployment introduces operational risks involving private keys, expiration, inaccurate inventories, weak validation, excessive trust, poor recovery, and third-party dependence. Effective PKI therefore combines cryptography with governance, automation, monitoring, secure operations, and incident response.

Key Terms

Certificate Authority (CA): Trusted entity that issues and signs digital certificates.

Certificate Policy (CP): Document specifying certificate requirements and assurance objectives.

Certification Practice Statement (CPS): Description of how a CA implements its certificate policy.

Certificate Transparency (CT): Public logging and monitoring system for publicly trusted certificates.

Digital certificate: Signed data structure binding an identity to a public key.

Digital signature: Cryptographic value used to provide integrity and evidence of private-key control.

End-entity certificate: Certificate issued to a user, server, device, or other final subject.

Intermediate CA: CA certified by a higher CA and normally used for routine issuance.

Key Usage: Certificate extension restricting permitted cryptographic operations.

Online Certificate Status Protocol (OCSP): Protocol for querying the status of a certificate.

OCSP stapling: Method in which a server provides a signed OCSP response to clients.

Public Key Infrastructure (PKI): System of technologies, people, policies, and procedures for managing public-key trust.

Registration Authority (RA): Entity that performs identity or authorization checks for a CA.

Relying party: Entity that decides whether to trust and use a certificate.

Revocation: Early invalidation of a certificate before its normal expiration.

Root CA: Trust anchor at the top of a certificate hierarchy.

Trust store: Collection of trusted root certificates and related settings.

X.509: Standard certificate format widely used in Internet PKI.

Review Questions

Short Answer Questions

1. What relationship does a digital certificate establish?
2. Why is a root CA usually protected more strictly than an intermediate CA?
3. Name four checks performed during certificate-chain validation.
4. What is the purpose of certificate revocation?
5. What problem does Certificate Transparency address?

Long Answer Questions

1. Explain the roles of a CA, RA, relying party, root CA, and intermediate CA in a PKI.
2. Describe the complete lifecycle of a server certificate from key generation through retirement.
3. Compare CRLs, OCSP, and OCSP stapling, including their principal advantages and limitations.
4. Explain why a cryptographically valid certificate may still be rejected by a relying party.
5. Discuss the governance controls required to operate an enterprise PKI securely.

Analytical / Application Questions

1. An organization discovers an unauthorized certificate for one of its public domains in a CT log. What should it investigate and what immediate actions should it consider?
2. A business must choose between fail-open and fail-closed behavior when OCSP is unavailable for a critical service. Analyze the security and availability trade-off and recommend a decision process.
3. Design a high-level PKI lifecycle process for an organization with web servers, employee laptops, and medical or industrial devices. Identify where automation, human approval, key protection, and revocation should be applied.

Multiple Choice Questions with Answers

Question 1

What is the primary purpose of a digital certificate?

A. To store a subject’s private key

B. To bind an identity to a public key

C. To replace all network encryption

D. To generate random passwords

Correct Answer: B. To bind an identity to a public key

Question 2

Which PKI component commonly performs identity verification on behalf of a certificate authority?

A. Registration Authority

B. Trust store

C. Root certificate

D. OCSP cache

Correct Answer: A. Registration Authority

Question 3

What is the role of a root CA in a certificate hierarchy?

A. It is always an end-user certificate

B. It is a trust anchor for relying parties

C. It provides every OCSP response

D. It stores all subject private keys

Correct Answer: B. It is a trust anchor for relying parties

Question 4

Which certificate extension restricts the purposes for which a certificate may be used?

A. Key Usage

B. Serial Number

C. Issuer

D. Validity Period

Correct Answer: A. Key Usage

Question 5

What is the main purpose of certificate revocation?

A. To extend a certificate’s validity period

B. To invalidate a certificate before its normal expiration

C. To convert a public key into a private key

D. To create a new root trust store

Correct Answer: B. To invalidate a certificate before its normal expiration

Question 6

Which mechanism publishes revoked certificate serial numbers in a signed list?

A. CRL

B. CT log

C. CSR

D. HSM

Correct Answer: A. CRL

Question 7

What does Certificate Transparency primarily improve?

A. Private-key encryption speed

B. Visibility and accountability for public certificate issuance

C. The physical security of laptops

D. The confidentiality of OCSP queries

Correct Answer: B. Visibility and accountability for public certificate issuance

Question 8

Which statement about a certificate chain is correct?

A. Every certificate must be self-signed

B. An end-entity certificate is normally validated through issuing authorities to a trusted root

C. A chain is valid if the hostname is ignored

D. Intermediate CAs cannot issue certificates

Correct Answer: B. An end-entity certificate is normally validated through issuing authorities to a trusted root

Question 9

A server certificate is correctly signed but names api.example.org, while the client connects to payments.example.org. What validation issue is most likely?

A. Name mismatch

B. Incorrect CRL format

C. Excessive key length

D. Missing private-key generation

Correct Answer: A. Name mismatch

Question 10

Which control best reduces the risk of compromise of a high-value CA private key?

A. Sending the key by email to administrators

B. Storing it in a public repository

C. Using hardware-backed protection and multi-person authorization

D. Disabling certificate expiration

Correct Answer: C. Using hardware-backed protection and multi-person authorization