1.Read each section in order — they build on each other.
2.Use "Listen to This Lesson" for audio narration while you read.
3.Review the PKI trust chain diagram in Section D.
4.Complete the knowledge check at the bottom.
5.Select Mark Lesson Complete when finished.
6.Continue to Lesson 1.2: Public and Private Keys.
Lesson Summary
Public Key Infrastructure, commonly called PKI, is the combination of people, processes, policies, systems, certificates, cryptographic keys, and trust relationships used to establish digital identity and secure communications.
Learning Objectives
Define PKI in practical enterprise terms.
Explain why organizations use digital certificates.
Identify the core components of a PKI.
Explain how PKI supports authentication, encryption, and digital signing.
Describe common enterprise PKI use cases.
A
PKI in Plain English
Think of PKI as a digital trust system. In the physical world, a government issues a passport that proves your identity to anyone who trusts that government. In the digital world, a Certificate Authority (CA) issues a digital certificate that proves the identity of a user, device, application, or service — to anyone who trusts that CA.
PKI does not refer to a single product or protocol. It is a framework — a combination of:
›People: PKI administrators, security officers, and certificate owners
›Processes: Certificate enrollment, renewal, revocation, and lifecycle management
›Policies: Certificate Practice Statements (CPS), Certificate Policies (CP), and security baselines
›Systems: Certificate Authorities, OCSP responders, CRL distribution points, and enrollment services
›Certificates: X.509 digital certificates binding public keys to identities
›Cryptographic keys: Asymmetric key pairs (public + private) used for signing and encryption
›Trust relationships: The chain of trust from Root CA through Issuing CAs to end entities
Key Concept
PKI is a framework, not a product
When someone says "we need to fix our PKI," they may mean the CA software, the certificate templates, the enrollment process, the revocation infrastructure, or all of the above. PKI is the entire system — not just the CA server.
B
Why Organizations Use PKI
Digital certificates solve a fundamental problem: how do you prove identity and establish secure communications in a network where you cannot physically verify who you are talking to? PKI is the answer enterprises have standardized on.
HTTPS / TLS
Server certificates authenticate web servers and encrypt traffic between clients and servers.
VPN & Remote Access
Machine and user certificates authenticate VPN clients without relying on passwords.
Wi-Fi / EAP-TLS
Certificates authenticate devices and users to 802.1X-protected wireless networks.
Smart Cards & PIV
Certificates on smart cards enable strong two-factor authentication for workstation logon.
Code Signing
Certificates allow software publishers to sign executables, scripts, and packages to prove authenticity.
S/MIME Email
Certificates enable email encryption and digital signing to protect message confidentiality and integrity.
Device Identity
Machine certificates establish device identity for zero-trust and NAC (Network Access Control) architectures.
Application & API Auth
Certificates authenticate services and APIs to each other without shared secrets or passwords.
Production Note
PKI is everywhere in a modern enterprise
In a well-configured enterprise, PKI certificates are used by laptops, servers, network devices, VPN gateways, Wi-Fi controllers, web applications, email clients, and code signing pipelines — often without end users being aware of it.
C
Core PKI Components
These are the building blocks you will encounter in every PKI deployment. Understand each one before moving to the next lesson.
Certificate Authority (CA)
The trusted entity that issues, signs, and manages digital certificates. The CA is the root of trust in a PKI.
Root CA
The top of the trust hierarchy. Self-signed certificate. Typically kept offline. Must be explicitly trusted by all clients.
Issuing CA
Subordinate to the Root CA. Directly issues certificates to end entities: users, devices, servers, and applications.
Digital Certificate
An X.509 structured data object that binds a public key to an identity and is signed by a CA.
Public Key
The shareable half of an asymmetric key pair. Embedded in the certificate. Used to encrypt data or verify signatures.
Private Key
The secret half of an asymmetric key pair. Never leaves the owner's control. Used to decrypt data or create digital signatures.
Certificate Template
In Microsoft ADCS, a template defines the properties, key usage, EKU, validity period, and enrollment permissions for a class of certificates.
Certificate Enrollment
The process by which an entity requests and receives a certificate from a CA. Can be manual, web-based, or automatic (auto-enrollment).
Certificate Revocation List (CRL)
A signed list published by the CA of certificates that have been revoked before their expiration date.
OCSP
Online Certificate Status Protocol — a real-time alternative to CRL for checking whether a specific certificate has been revoked.
CRL Distribution Point (CDP)
An extension in a certificate that tells clients where to download the CRL to check revocation status.
Authority Information Access (AIA)
An extension that tells clients where to find the issuing CA certificate and the OCSP responder URL.
Certificate Lifecycle Management
The end-to-end process of enrolling, renewing, revoking, and retiring certificates across their operational lifetime.
Common Mistake
Confusing the Root CA and Issuing CA roles
A common mistake is configuring the Root CA to directly issue end-entity certificates. In a properly designed PKI, the Root CA should only sign Issuing CA certificates — then go offline. End-entity certificates are issued by the Issuing CA. This protects the Root CA private key.
D
PKI Trust Chain
The trust chain is the sequence of certificates from an end-entity certificate up through the Issuing CA to the Root CA. Clients validate each link in the chain before trusting the presented certificate.
How validation works: When a client receives a certificate, it:
1.Checks that the certificate was issued by a CA it trusts (by validating the CA signature)
2.Walks up the chain to the Root CA, validating each CA certificate along the way
3.Checks that the Root CA certificate is in its trusted root store
4.Checks revocation status via CRL or OCSP
5.Verifies the certificate has not expired and the subject matches the expected identity
Security Consideration
The Root CA private key is the crown jewel
If the Root CA private key is compromised, an attacker can issue certificates that are trusted by every client in the enterprise. This is why Root CAs are kept offline, stored in physically secured environments, and their private keys are often protected by Hardware Security Modules (HSMs).
E
Enterprise Example: Northstar Manufacturing
Consider Northstar Manufacturing, a mid-size enterprise with 2,000 employees. Here is how PKI enables secure operations:
Northstar Manufacturing — PKI Flow
1
Employee laptop boots up
Machine certificate issued by Northstar Issuing CA is presented to the Wi-Fi controller
2
Wi-Fi authentication (EAP-TLS)
The Wi-Fi controller validates the machine certificate against the Northstar Root CA trust store
3
Network access granted
The laptop joins the corporate network — no password required, certificate proves identity
4
User opens internal web app
Browser validates the HTTPS certificate issued by Northstar Issuing CA for the internal app
5
Secure session established
TLS handshake completes — all traffic between laptop and app is encrypted
In this scenario, the Northstar PKI hierarchy looks like this:
Northstar Root CA (offline, stored in a vault)
└─ Northstar Issuing CA (online, issues machine and user certs)
├─ Machine certificate → laptop (Wi-Fi auth)
├─ User certificate → employee (smart card logon)
└─ Server certificate → internal web app (HTTPS)
F
Why It Matters in Production
PKI is critical infrastructure. When it fails — due to expired certificates, misconfigured revocation, or a compromised CA — the impact is immediate and broad:
Identity systems degrade — authentication becomes unreliable
Production Note
Certificate expiration is the most common PKI failure
The majority of PKI outages in enterprise environments are caused by expired certificates — not attacks. Implement certificate lifecycle monitoring and alerting before certificates expire. Many organizations use a 30/14/7-day alert cadence.
G
PKI Engineer Notes
Key Concept
PKI is a Tier 0 asset
In Microsoft's Enterprise Access Model (formerly the tiered administration model), the PKI infrastructure — especially the Root CA and Issuing CA — is classified as Tier 0. Compromise of the CA is equivalent to compromise of Active Directory. Treat it accordingly.
Common Mistake
Using the same CA for internal and public certificates
Internal enterprise CAs should not be used to issue publicly trusted certificates. Public trust requires compliance with CA/Browser Forum Baseline Requirements and annual audits. Keep internal PKI separate from any publicly trusted CA infrastructure.
Security Consideration
Private key protection is non-negotiable
A certificate is only as trustworthy as the security of its private key. For CA private keys, use Hardware Security Modules (HSMs). For end-entity certificates, use TPM-backed key storage where available. Never export private keys unless absolutely necessary — and audit every export.
Production Note
Document your PKI before you need to recover it
PKI recovery after a CA failure is extremely difficult without documentation. Record your CA configuration, key lengths, validity periods, CRL schedules, CDP/AIA URLs, and backup procedures before you go to production — not after an incident.
Key Terms Glossary
PKI
Public Key Infrastructure — the combination of people, processes, policies, systems, certificates, cryptographic keys, and trust relationships used to establish digital identity and secure communications.
Certificate Authority (CA)
A trusted entity that issues, signs, and manages digital certificates. The CA vouches for the binding between a public key and an identity.
Root CA
The top of the PKI trust hierarchy. Its certificate is self-signed and must be explicitly placed in client trust stores. Typically kept offline for security.
Issuing CA
A CA subordinate to the Root CA that directly issues certificates to end entities (users, devices, servers, applications).
Certificate
A structured data object (X.509 format) that binds a public key to an identity and is signed by a Certificate Authority.
Public Key
The shareable half of an asymmetric key pair. Embedded in a certificate and freely distributed. Used to encrypt data or verify signatures.
Private Key
The secret half of an asymmetric key pair. Must be kept secure by its owner. Used to decrypt data or create digital signatures.
Trust Chain
The sequence of certificates from an end-entity certificate up through the Issuing CA to the Root CA. Clients validate each link in the chain.
Revocation
The process of invalidating a certificate before its natural expiration. Published via CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol).
Knowledge Check
Question 1 of 5
Which of the following best describes PKI?
Question 2 of 5
What is the role of a Root CA in a PKI hierarchy?
Question 3 of 5
Which of the following is NOT a common enterprise PKI use case?
Question 4 of 5
What is the difference between a public key and a private key?
Question 5 of 5
What is the purpose of a CRL Distribution Point (CDP)?