Public Key Infrastructure (PKI): Certificates, CAs, and Trust Chains

What Is Public Key Infrastructure (PKI)?

Public Key Infrastructure (PKI) is a framework of technologies, policies, processes and trusted entities used to create, manage, validate, distribute and revoke digital certificates and public keys.

PKI helps organizations establish trust when communicating over networks that cannot automatically be trusted. It is especially important for secure web connections, enterprise authentication, VPNs, email security, digital signatures and other systems that rely on public-key cryptography.

Why Is PKI Needed?

Public-key cryptography allows parties to use a public/private key pair, but cryptography alone does not answer an important question: Who actually owns this public key?

A digital certificate helps solve this identity problem by binding information about an entity to its public key. A trusted certificate authority can provide a mechanism for other systems to validate that binding.

What Is a Digital Certificate?

A digital certificate is an electronic credential that associates identity information with a public key. It contains information that allows relying systems to evaluate who the certificate represents and whether it can be trusted.

Certificates commonly use the X.509 standard. An X.509 certificate can contain the subject, issuer, public key, validity period, serial number, extensions and the issuer’s digital signature.

What Is a Certificate Authority (CA)?

A Certificate Authority (CA) is a trusted entity that issues and manages digital certificates. The CA evaluates certificate requests under its policies, signs approved certificates and may publish or support certificate status information.

In a PKI environment, the CA is part of the chain of trust. A certificate is not automatically trustworthy merely because a CA signed it; the client must also validate the chain, identity, validity, usage, revocation status and applicable policy.

Root CA vs. Intermediate CA

PKI often uses a hierarchy of certificate authorities instead of having one CA issue every certificate directly.

Root CA

The root CA is the highest authority in a CA hierarchy. Its certificate is commonly self-signed and may serve as a trust anchor when it is already trusted by the relying system.

Intermediate CA

An intermediate CA sits below the root CA. It can issue certificates to subordinate CAs or end entities according to its constraints and policies.

What Is a Certificate Chain?

A certificate chain, also called a chain of trust, is the sequence of certificates that connects an end-entity certificate to a trusted root CA or another accepted trust anchor.

During validation, the relying system checks certificate signatures and issuer relationships throughout the chain. It ultimately relies on a root certificate or other trust-anchor information that it already accepts.

Trust Anchor and Root of Trust

A trust anchor is trusted information—commonly a root CA certificate—that provides the starting point for certificate-chain validation. Operating systems, browsers and applications may maintain trusted root certificates in a trust store.

The phrase root of trust describes a foundational trusted component or information on which a security verification process relies. In PKI scenarios, look for the trusted root certificate or public key. In hardware and platform security, a root of trust may instead begin with a protected hardware or firmware component.

Self-Signed vs. Third-Party CA-Issued Certificates

Certificates differ in who signs them and how relying systems establish trust. A signature alone does not guarantee that a certificate is safe or suitable for every use.

Wildcard Certificates and Subject Alternative Names

A wildcard certificate uses a wildcard in a domain name to cover matching subdomains at the applicable label level. For example, *.example.com can cover shop.example.com and mail.example.com, subject to certificate and client matching rules.

A wildcard does not automatically cover unrelated domains, every deeper nested subdomain or the base name example.com unless that name is also included. The Subject Alternative Name (SAN) extension can list additional identities, including DNS hostnames or IP addresses.

Certificate Signing Request (CSR)

A Certificate Signing Request (CSR) is submitted to a CA when an entity needs a certificate. It commonly contains the requester’s public key, requested identity information and a signature made with the corresponding private key to demonstrate control of that key.

The private key itself must never be sent in the CSR. It remains under the requester’s control and must be stored using appropriate protection.

Key Escrow and Controlled Recovery

Key escrow means placing a controlled copy of a selected cryptographic key with an authorized escrow agent or system so that recovery can occur under defined conditions. Organizations may use escrow for certain encryption keys when losing the original key would make business data inaccessible or when an approved operational process requires recovery.

Key escrow is not a reason to make every private key recoverable. Signing keys and other identity-sensitive keys may have different recovery requirements. Follow the organization’s cryptographic policy and the key’s intended use. See the Cryptography Basics lesson for related key-management concepts.

PKI Certificate Lifecycle

Certificates have a lifecycle. Understanding each stage is important for operational security and Security+ scenario questions.

Certificate Revocation

A certificate can become untrusted before its expiration date. This may occur if the private key is compromised, the certificate was issued incorrectly, the subject is no longer authorized or another policy-defined revocation condition is met.

Revocation is different from expiration. Expiration occurs at the end of the certificate’s validity period. Revocation is an administrative or policy-driven action that invalidates the certificate before that normal end date.

Certificate Revocation List (CRL)

A Certificate Revocation List (CRL) is a published list of certificates revoked by a CA. A client can retrieve the relevant CRL and check whether a certificate’s serial number appears on it.

Online Certificate Status Protocol (OCSP)

OCSP allows a client to query an OCSP responder about the status of a particular certificate rather than downloading an entire revocation list. It can reduce the amount of status information that a client needs to retrieve compared with traditional CRL-based checking.

How Certificate Validation Works

A relying system does not simply check whether a certificate exists. Certificate validation can involve several checks:

• Is the certificate within its validity period?
• Is its issuer trusted under the client’s trust configuration?
• Does the certificate chain terminate at an accepted trust anchor?
• Are the certificate signatures valid?
• Does the certificate match the intended identity or hostname when applicable?
• Has the certificate been revoked, and what is the configured status-checking behavior?
• Are the key usage, extended key usage and other constraints appropriate?
• Do the algorithms and key parameters meet the applicable policy?

Certificate Algorithms and Key Length

Certificate validation also depends on the algorithms and key parameters used for the public key and certificate signature. A certificate that has not expired can still be unacceptable if it relies on a deprecated algorithm, a weak key or parameters that violate security policy.

PKI and TLS

PKI is closely associated with TLS and HTTPS. When a browser connects securely to a web server, the server can present a digital certificate containing its public key and identity information.

The client validates the certificate and its trust chain. Modern TLS then uses secure key-establishment mechanisms to establish session keys that protect application data.

PKI in Real-World Security

Other Common Uses of PKI

PKI Security Risks

PKI vs. Related Concepts

Security+ SY0-701 Exam Strategy for PKI