How the certificate trust hierarchy works, the complete PKI lifecycle from issuance to revocation, cloud-native PKI services, and the key management practices that determine whether your encryption controls actually hold.
Sign in to mark this article as read and track your progress.
Encryption without rigorous key management is security theatre. A perfectly encrypted volume is worthless if the encryption key is:
Cloud key management services solve these problems at scale — but only if configured correctly.
PKI is the system that binds cryptographic public keys to verified identities through digital certificates (X.509 standard).
Root CA (Certificate Authority): The trust anchor. The root CA certificate is self-signed and pre-installed in operating systems and browsers. Kept offline in a hardware security module (HSM). Never directly issues end-entity certificates.
Intermediate CA: Signed by the Root CA. Issues certificates to end entities. If compromised, can be revoked without replacing the Root CA.
End-Entity Certificate: The certificate presented by your web server, your API endpoint, your email client. Signed by an Intermediate CA.
When a browser connects to https://yourcloud.app:
| Operation | Purpose | Cloud Tool |
|---|---|---|
| Issue | Generate and sign a new certificate | AWS ACM, Azure Key Vault, GCP Certificate Manager |
| Renew | Replace expiring certificate with fresh one | ACM auto-renewal; cert-manager for Kubernetes |
| Revoke | Invalidate a compromised certificate before expiry | CRL / OCSP; ACM revocation |
| Validate | Verify a certificate chain and revocation status | OCSP stapling; browser and SDK validation |
Certificate expiry is one of the most common causes of outages. AWS ACM auto-renews certificates for resources it manages (ALB, CloudFront). For self-managed certificates, set calendar reminders at 90, 30, and 7 days before expiry.
| Service | Provider | Use Case |
|---|---|---|
| AWS Certificate Manager (ACM) | AWS | Free TLS for ALB, CloudFront, API Gateway; auto-renewal |
| AWS Private CA | AWS | Internal PKI for microservices, IoT, VPN clients |
| Azure Key Vault Certificates | Azure | Certificate management integrated with Key Vault |
| Google Certificate Authority Service | GCP | Managed private CA for internal services |
Keys must be generated using a cryptographically secure random number generator (CSPRNG). Keys generated on HSM hardware never exist in plaintext outside the HSM.
Keys are shared using secure channels:
| Key Type | Rotation Frequency |
|---|---|
| Data encryption keys | Annually or per data set |
| Master keys (KMS CMKs) | Annually (AWS auto-rotation available) |
| API access keys | 90 days maximum |
| TLS certificates | Before expiry (90-day Let Encrypt standard) |
| SSH key pairs | When team composition changes |
Keys must be securely destroyed when no longer needed. NIST SP 800-88 provides guidelines for cryptographic key destruction. On HSMs, destruction is guaranteed — the key material never left hardware.
| Feature | AWS KMS | AWS CloudHSM |
|---|---|---|
| Key storage | Managed HSM fleet | Dedicated HSM hardware |
| Key types | Symmetric, asymmetric, HMAC | Full HSM capabilities |
| Management | Fully managed | Customer manages HSM software |
| Compliance | FIPS 140-2 Level 2 | FIPS 140-2 Level 3 |
| Cost | Per-call pricing ($0.03/10,000 calls) | $1.60/hour per HSM |
| Use case | General cloud encryption | PCI-DSS, eIDAS, custom CA root key |
PKI and key management are the operational side of encryption. Perfect algorithms fail when keys are mismanaged. Use cloud-native KMS services, enforce rotation, restrict key policies to least privilege, and audit every key operation through CloudTrail.
