Module 2: Cryptography and PKI Foundations

Learning Objectives

• Understand symmetric vs asymmetric encryption
• Learn how PKI and certificate authorities work
• Master X.509 certificates and certificate chains
• Implement mutual TLS between services

Why This Matters

Every identity system in cloud-native infrastructure — mTLS, JWT authentication, certificate rotation, federation — is built on these cryptographic primitives. Without understanding PKI and certificate chains, SPIRE configurations feel like magic incantations. With this foundation, you will understand WHY SPIRE makes specific design choices and how to debug certificate failures in production.

Lesson Content

Before diving into SPIFFE and SPIRE, you need to understand the cryptographic primitives they are built on. This module covers the essential building blocks: encryption, certificates, PKI, and mutual TLS.

Cryptography Fundamentals

Symmetric Encryption

Both parties share the same secret key for encryption and decryption. Fast but has a key distribution problem — how do you securely share the key in the first place?

# AES-256 symmetric encryption
# Same key encrypts and decrypts
# Problem: how does Service B get the key securely?
plaintext -> [AES-256 + key] -> ciphertext -> [AES-256 + same key] -> plaintext

Asymmetric Encryption

Two mathematically linked keys: a public key (shared openly) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the private key. This solves the key distribution problem.

# RSA / ECDSA asymmetric encryption
# Public key encrypts, private key decrypts
# Anyone can encrypt, only the key holder can decrypt
plaintext -> [encrypt with public key] -> ciphertext -> [decrypt with private key] -> plaintext

# Digital signatures work in reverse:
# Private key signs, public key verifies
data -> [sign with private key] -> signature
(data + signature) -> [verify with public key] -> valid/invalid

Public Key Infrastructure (PKI)

PKI is the system of certificate authorities, certificates, and trust relationships that makes asymmetric encryption practical at scale.

• Root Certificate Authority (Root CA): The ultimate trust anchor. Its certificate is self-signed and pre-installed in trust stores.
• Intermediate CA: Signed by the Root CA. Issues certificates to end entities. Allows the Root CA to stay offline.
• End Entity Certificate: Issued to a service, server, or workload. Contains the public key, identity information, and the issuing CA’s signature.

X.509 Certificates Explained

X.509 is the standard format for public key certificates. Every HTTPS connection uses X.509 certificates. SPIFFE X.509-SVIDs are X.509 certificates with a SPIFFE ID in the URI SAN field.

# Key fields in an X.509 certificate:
Subject:     CN=service-a.example.com
Issuer:      CN=Intermediate CA
Not Before:  2026-04-28 00:00:00 UTC
Not After:   2026-04-29 00:00:00 UTC   # Short-lived!
Public Key:  EC P-256 (the service's public key)
SAN:         URI: spiffe://example.org/ns/default/sa/service-a
Signature:   (signed by the Intermediate CA's private key)

Mutual TLS (mTLS)

Regular TLS (HTTPS) only verifies the server. The client checks the server’s certificate but does not present one of its own. Mutual TLS requires both sides to present and verify certificates. This is the foundation of zero trust service-to-service communication.

Certificate Rotation

Long-lived certificates are a security risk. If a certificate is compromised, the attacker has access until it expires — which could be years. Short-lived certificates (1 hour or less) limit the blast radius. But short-lived certificates require automatic rotation, which is exactly what SPIRE provides.

JWT Fundamentals

JSON Web Tokens are an alternative identity format used when X.509 is impractical (like HTTP APIs without TLS termination control). A JWT-SVID contains the SPIFFE ID in the sub claim and is signed by the SPIRE server.

Real-World Use Cases

• Service-to-service mTLS in Kubernetes — encrypted and authenticated communication
• API gateway JWT verification — validating service identity at the edge
• Certificate rotation in production — preventing outages from expired certs
• Cross-cluster trust establishment — sharing CA trust bundles for federation

Production Notes

• Never use self-signed certificates for end-entity SVIDs in production. Always use a proper CA hierarchy with an offline Root CA and online Intermediate CA.
• Certificate TTL should be as short as your rotation mechanism supports. SPIRE defaults to 1 hour — this is a good production baseline.
• Always verify the full certificate chain, not just the end-entity certificate. Chain verification prevents man-in-the-middle attacks with rogue CAs.

Common Mistakes

• Using RSA-2048 when ECDSA P-256 is faster and equally secure for short-lived certificates
• Storing CA private keys on disk without hardware security module (HSM) protection
• Not monitoring certificate expiration — silent expiry causes sudden production outages
• Confusing certificate authentication with certificate authorization — a valid cert proves identity, not permissions

Design Tradeoffs

X.509-SVID

Pros

• Native mTLS support
• No extra headers needed
• Works at the transport layer
• Ecosystem compatible

Cons

• Certificate management complexity
• Heavier than JWTs
• Requires TLS termination control

JWT-SVID

Pros

• Lightweight token
• Easy to pass in HTTP headers
• Works with API gateways
• No TLS termination needed

Cons

• Weaker transport guarantees
• Requires token validation
• Clock synchronization dependency

Career Relevance

PKI and certificate management are foundational skills for security engineering, platform engineering, and SRE roles. Organizations running Kubernetes at scale need engineers who can debug certificate chain failures, design CA hierarchies, and implement automatic rotation. This module gives you that foundation.

Key Terms

PKI

Public Key Infrastructure — the system of CAs, certificates, and trust relationships

Root CA

The ultimate trust anchor with a self-signed certificate

Intermediate CA

Signed by Root CA, issues end-entity certificates

X.509

Standard format for public key certificates

SAN

Subject Alternative Name — field in X.509 containing SPIFFE ID

Certificate Chain

Sequence from end-entity cert through intermediates to root

Hands-On Labs

1. Creating a Root Certificate Authority

   Build a PKI hierarchy from scratch using OpenSSL.

   • Generate a Root CA private key and self-signed certificate
   • Generate an Intermediate CA key and CSR
   • Sign the Intermediate CA certificate with the Root CA
   • Verify the certificate chain

   View lab files on GitHub

2. Generating and Signing Certificates

   Issue end-entity certificates for services.

   • Generate a private key for a service
   • Create a CSR with SPIFFE ID in the SAN field
   • Sign the certificate with the Intermediate CA
   • Inspect the certificate with openssl x509 -text

   View lab files on GitHub

3. Establishing mTLS Between Services

   Configure two services to mutually authenticate with certificates.

   • Start a TLS server that requires client certificates
   • Start a TLS client that presents its certificate
   • Verify that both sides authenticate each other
   • Observe the connection failing with an invalid or missing certificate

   View lab files on GitHub

Key Takeaways

• Asymmetric encryption solves the key distribution problem
• PKI provides a scalable trust hierarchy for certificate management
• X.509 certificates bind a public key to an identity
• mTLS authenticates BOTH client and server — the foundation of zero trust
• Short-lived certificates limit blast radius but require automatic rotation
• SPIFFE uses X.509 and JWT as its two SVID formats