Module 1: PKI Fundamentals
Lesson 1.2: Public and Private Keys
15–20 minutes
Reading + Quiz
Lesson 2 of 18Module 1 of 5
How to Use This Lesson
- 1.Read each section in order — they build on each other.
- 2.Use "Listen to This Lesson" for optional audio narration.
- 3.Review the key-pair and encryption/signature diagrams.
- 4.Complete the knowledge check at the bottom.
- 5.Mark the lesson complete.
- 6.Continue to Lesson 1.3: Hash Functions and Digital Signatures.
Lesson Summary
Public and private keys are mathematically related cryptographic keys used in asymmetric cryptography. The public key can be shared widely, while the private key must remain protected. Together, they support encryption, authentication, certificate requests, certificate validation, and digital signatures.
Learning Objectives
- Explain the difference between a public key and a private key.
- Describe why private key protection is critical.
- Explain how asymmetric cryptography supports certificates.
- Explain the basic difference between encryption and digital signing.
- Identify common enterprise risks related to private key loss, theft, exportability, or misuse.
A
Asymmetric Cryptography in Plain English
Symmetric cryptography uses a single shared secret key — both parties must have the same key to encrypt and decrypt. This creates a fundamental problem: how do you securely share that key in the first place?
Asymmetric cryptography solves this by using two mathematically related keys — a public key and a private key. These keys are generated together as a pair. What one key encrypts, only the other can decrypt. Knowing the public key does not allow you to derive the private key.
Public / Private Key Pair
Public Key
- ›Shared freely
- ›Embedded in certificate
- ›Encrypts data for owner
- ›Verifies owner's signatures
- ›Not confidential
Mathematically
linked
linked
Private Key
- ›Never shared
- ›Stays with owner
- ›Decrypts data from public key
- ›Creates digital signatures
- ›Must be protected
PKI relies on this relationship to establish trust without sharing secret keys across the network. A Certificate Authority can issue a certificate containing a public key, and the corresponding private key never needs to leave the owner's device.
Key Concept
Asymmetric cryptography is slower than symmetric
Asymmetric operations are computationally expensive. In practice, TLS uses asymmetric cryptography only to establish a session and exchange a symmetric session key — then switches to fast symmetric encryption for the bulk of the data transfer. PKI provides the trust framework; symmetric encryption provides the performance.
B
The Public Key
The public key is the half of the key pair that is designed to be shared. It is embedded in a digital certificate and can be distributed to anyone without compromising security.
Freely shareable
The public key is not confidential. Sharing it does not compromise the key pair.
Embedded in the certificate
The Subject Public Key Info field in an X.509 certificate contains the public key algorithm and the public key value.
Used to encrypt data for the owner
Anyone can encrypt data using the public key. Only the holder of the matching private key can decrypt it.
Used to verify the owner's signatures
When the owner signs data with their private key, anyone with the public key can verify that signature.
Must be tied to a trusted identity
A public key alone proves nothing. It must be bound to an identity through a certificate signed by a trusted CA.
Common Mistake
A public key without a certificate proves nothing
A raw public key has no identity attached to it. Without a CA-signed certificate binding that key to a verified identity, you cannot trust who it belongs to. This is why certificate validation — not just key exchange — is central to PKI.
C
The Private Key
The private key is the half of the key pair that must remain secret. It is the most sensitive asset associated with a certificate. If the private key is compromised, the certificate must be revoked immediately — and any data protected by it must be considered exposed.
Must remain confidential
The private key must never be shared, emailed, or stored in an unsecured location.
Creates digital signatures
The owner uses the private key to sign data. The signature can be verified by anyone with the matching public key.
Decrypts data
Data encrypted with the public key can only be decrypted with the matching private key.
Storage options vary by security level
Software key store, Windows certificate store, TPM, smart card, PIV credential, or HSM — each offers different protection levels.
Should not be casually exported
Exporting a private key creates a copy that can be stolen. Non-exportable key settings prevent this.
Security Consideration
Private key compromise requires immediate revocation
If a private key is stolen or suspected compromised, the associated certificate must be revoked immediately via the CA. Revocation publishes the certificate serial number to the CRL and OCSP. Clients that check revocation will stop trusting the certificate. Clients that do not check revocation will continue to trust it — which is why revocation checking must be enforced.
D
Encryption vs. Digital Signatures
Asymmetric cryptography supports two distinct operations. Understanding which key is used for each operation is fundamental to PKI.
EncryptionDigital Signature
PurposeConfidentialityIntegrity, authenticity, non-repudiation
Sender usesRecipient's public keySigner's private key
Recipient usesRecipient's private keySigner's public key
Who can encrypt/signAnyone with the public keyOnly the private key holder
Who can decrypt/verifyOnly the private key holderAnyone with the public key
Encryption Flow
1
Sender obtains recipient's certificate
Contains the recipient's public key
2
Sender encrypts data with recipient's public key
Anyone can encrypt — only the recipient can decrypt
3
Encrypted data is transmitted
Unreadable to anyone without the private key
4
Recipient decrypts with their private key
Only the private key holder can recover the plaintext
Enterprise example: An HR system encrypts a salary report PDF using the CFO's certificate public key. Only the CFO — who holds the matching private key — can open the file.
Digital Signature Flow
1
Signer computes a hash of the data
A fixed-size digest representing the content
2
Signer encrypts the hash with their private key
This encrypted hash is the digital signature
3
Signature is attached to the data
Recipient receives both the data and the signature
4
Recipient verifies using signer's public key
Decrypts the signature to recover the hash, computes their own hash, compares — if they match, the signature is valid
Enterprise example: A developer signs a PowerShell script with their code signing certificate. Windows verifies the signature before executing the script — confirming the script has not been tampered with and was signed by a trusted publisher.
E
How Keys Relate to Certificates
A certificate is not just a public key — it is a public key bound to an identity by a trusted CA. Understanding this relationship is essential.
Certificate + Private Key Relationship
Certificate (public)
Subject: CN=laptop01.northstar.local
Issuer: Northstar Issuing CA
Public Key: [RSA 2048-bit public key value]
CA Signature: [signed by Northstar Issuing CA]
Distributed freely — stored in certificate store, sent during TLS handshake
mathematically paired with
Private Key (secret)
Key: [RSA 2048-bit private key — never transmitted]
Storage: TPM chip on laptop01
Exportable: No
Never leaves the device — used to prove possession during EAP-TLS authentication
The certificate binds the public key to the subject identity — the CA signature vouches for this binding.
The matching private key stays with the certificate owner — it is never sent to the CA.
Certificate issuance does not mean the CA administrator can access the private key.
The CA must protect its own private key at a higher level — it signs certificates trusted by the entire enterprise.
Common Mistake
The CA does not hold your private key — unless key archival is configured
By default, when a certificate is issued, the CA signs the certificate but never receives the private key. Key archival is a separate, optional feature in Microsoft ADCS that allows the CA to store a copy of encryption private keys for recovery purposes. It must be explicitly configured and should only be enabled for encryption certificates — never for signing or authentication certificates.
F
Key Protection in Enterprise PKI
The security of a certificate is only as strong as the protection of its private key. Enterprise PKI deployments use a range of storage mechanisms depending on the sensitivity of the certificate.
Private Key Storage Options
Software key storeLow
Key stored in the file system or registry. Exportable by default. Lowest protection.
Windows certificate storeLow–Med
Integrated with Windows. Can be non-exportable. No hardware protection.
TPM-backed key storageHigh
Key generated and stored in the TPM chip. Non-exportable. Bound to the device.
Smart card / PIV credentialHigh
Key stored on a physical card. Never leaves the card. Requires PIN to use.
HSM (Hardware Security Module)Highest
Dedicated hardware for key generation and storage. Required for CA private keys.
Non-exportable keys
Configure certificate templates to mark private keys as non-exportable. This prevents the key from being extracted to a PFX file.
Key archival
For encryption certificates only — the CA stores a copy of the private key for data recovery. Never enable for signing or authentication certs.
Key escrow
A trusted third party holds a copy of the private key. Distinct from key archival. Requires strict access controls and audit logging.
Signing vs. encryption keys
Signing keys should never be archived — non-repudiation requires that only the signer could have created the signature. Encryption keys may be archived for data recovery.
Security Consideration
Non-exportable keys are not the same as TPM-protected keys
A non-exportable software key can still be extracted by an attacker with local admin rights using tools like Mimikatz. TPM-backed keys are hardware-protected — the private key material never leaves the TPM chip, even for an administrator. For high-value certificates, require TPM-backed key storage in the certificate template.
G
Enterprise Example: Northstar Manufacturing
Here is how public and private keys work in a real Northstar Manufacturing EAP-TLS Wi-Fi authentication scenario:
Northstar — Machine Certificate + EAP-TLS Flow
1
Auto-enrollment issues machine certificate
The Northstar Issuing CA issues a machine certificate to laptop01. The public key is embedded in the certificate. The private key is generated on the laptop and stored in the TPM — it never leaves the device.
2
Laptop connects to corporate Wi-Fi
The 802.1X supplicant presents the machine certificate to the Wi-Fi controller (RADIUS server) during EAP-TLS authentication.
3
RADIUS validates the certificate chain
The RADIUS server validates the certificate against the Northstar Root CA trust store and checks revocation via CRL or OCSP.
4
Laptop proves private key possession
The TLS handshake requires the laptop to sign a challenge with its private key. The RADIUS server verifies the signature using the public key in the certificate. This proves the laptop holds the matching private key.
5
Network access granted
Authentication succeeds. No password was used — the certificate and private key proved the laptop's identity.
H
Why It Matters in Production
Private key failures are among the most serious PKI security incidents. Here are the real-world risks:
Exportable private keys — silently copied and used on attacker-controlled devices
Private key compromise — all certificates using that key must be revoked immediately
Lost smart card or token — private key may be accessible without the PIN if not properly protected
Weak private key password handling — PFX files with weak passwords are easily cracked
Uncontrolled certificate export — PFX files emailed or stored on file shares
Code signing key theft — malware signed with a stolen key appears legitimate to Windows
CA private key compromise — attacker can issue fraudulent certificates trusted by the enterprise
Failure to revoke compromised certificates — clients continue to trust revoked certificates
No key archival for encryption certs — encrypted data permanently lost if key is destroyed
I
PKI Engineer Notes
Key Concept
Key length matters — but so does algorithm choice
RSA 2048-bit is the current minimum for enterprise PKI. RSA 4096-bit provides a higher security margin but is slower. ECDSA P-256 and P-384 provide equivalent or better security with shorter keys and faster operations. For new PKI deployments, consider ECDSA P-384 for CA keys and P-256 for end-entity certificates.
Common Mistake
Configuring certificate templates with exportable private keys by default
Many ADCS certificate templates are configured with exportable private keys out of habit or for convenience. This is a significant security risk. Audit your certificate templates and disable key export unless there is a documented business requirement. For user certificates, non-exportable TPM-backed keys should be the default.
Security Consideration
CA private keys must be protected by HSMs in production
For any production PKI, the Root CA and Issuing CA private keys must be protected by Hardware Security Modules. Software-stored CA private keys can be extracted by an attacker with access to the CA server. An HSM ensures the private key never exists in software memory and cannot be exported.
Production Note
Document your key recovery procedures before you need them
Key archival for encryption certificates must be planned before deployment. If a user's encryption private key is lost and no archival was configured, any data encrypted to that key is permanently unrecoverable. Define your key archival policy, test recovery procedures, and document them before issuing encryption certificates at scale.
Key Terms Glossary
Asymmetric Cryptography
A cryptographic system using a mathematically related key pair — a public key and a private key — where one key encrypts or signs and the other decrypts or verifies.
Public Key
The shareable half of a key pair. Embedded in a digital certificate. Used by others to encrypt data for the key owner or to verify the owner's digital signature.
Private Key
The secret half of a key pair. Must remain with its owner. Used to decrypt data encrypted with the matching public key, or to create digital signatures.
Key Pair
A mathematically linked public key and private key generated together. What one key encrypts, only the other can decrypt.
Encryption
The process of transforming data into an unreadable form using a key. In asymmetric encryption, the recipient's public key encrypts; the recipient's private key decrypts.
Digital Signature
A cryptographic value created by signing data with a private key. Verified using the matching public key. Proves authenticity, integrity, and supports non-repudiation.
Key Exportability
Whether a private key can be extracted from its storage location (e.g., exported to a PFX file). Non-exportable keys are bound to the device or TPM and cannot be copied.
TPM
Trusted Platform Module — a hardware chip on a device that provides secure key generation and storage. TPM-backed keys cannot be exported from the device.
HSM
Hardware Security Module — a dedicated hardware device for generating, storing, and protecting cryptographic keys. Required for CA private keys in high-security deployments.
Smart Card
A physical card containing a chip that stores a private key. The private key never leaves the card. Used for strong two-factor authentication and smart card logon.
Key Archival
The process of securely storing a copy of an encryption private key so that encrypted data can be recovered if the original key is lost. Applies to encryption keys only — not signing keys.
Key Escrow
A key management practice where a copy of a private key is held by a trusted third party for recovery purposes. Distinct from key archival in that a third party holds the key.
Knowledge Check
Question 1 of 5
Which statement correctly describes the difference between a public key and a private key?
Question 2 of 5
An employee wants to send an encrypted message to a colleague so only that colleague can read it. Which key does the sender use to encrypt the message?
Question 3 of 5
A developer signs a PowerShell script with a code signing certificate. Which key is used to create the signature?
Question 4 of 5
A certificate template is configured to allow private key export. Why is this a security risk?
Question 5 of 5
Why do CA private keys require stronger protection controls than end-entity private keys?
Downloads
Public and Private Key Quick Reference
How public/private key pairs support certificates, encryption, digital signatures, and enterprise key protection.
Coming Soon
Module 1 Lessons
Your Progress
Not yet complete
1 of 18 lessons complete (est.)