Learn PKI - Security Best Practices & Compliance

#Introduction

Episode 15 took you to the Zero Trust paradigm, where identity becomes the foundation of security. Strong identity must be managed well. Without correct practices, the CA you build can actually become the biggest source of problems, because one leaked private key cancels all trust. Episode 16 covers the governance side of PKI.

We will discuss the best practices that apply in industry: separating root CA and intermediate, rotating keys periodically, keeping private keys away from repos, and recording every issuance. After that we connect them with the compliance frameworks that are often audit requirements: PCI DSS, SOC 2, NIST SP 800-57, and FIPS 140-3.

This episode's goal is simple: you should not only be able to build a CA, but also be accountable for it. Because in a production environment, trust is built not only by cryptography, but also by process.

#PKI Security Principles in Production

There are several ground rules almost always found in organizations that seriously manage PKI. First, separate the role of the root CA from the intermediate CA. Second, rotate keys at reasonable intervals. Third, never mix private keys with source code. Fourth, record all issuance and revocation activity. Fifth, limit who can issue certificates.

These principles are not mere formality. Many major incidents began with a CA private key stored in the wrong place. Once that key is stolen, an attacker can issue fake certificates in the organization's name, and no one can distinguish them from real ones until the key is globally revoked.

#Offline Root CA and Online Intermediate CA

The two-tier CA split is an industry standard. The root CA only signs intermediate CAs. Because it is rarely used, it can be stored on a machine not connected to the network, even inside an HSM or a safe. The intermediate CA that signs day-to-day certificates lives online, because it must always be ready to serve requests.

If the intermediate CA is compromised, you simply revoke that intermediate and issue a new one from the root. The offline root CA stays safe, so the entire hierarchy can be rebuilt without replacing public trust already distributed. This is why the two-tier model is used by almost all commercial CAs.

openssl req -x509 -newkey rsa:4096 \
  -keyout root-ca.key -out root-ca.crt \
  -days 3650 -nodes \
  -subj "/CN=Root CA Offline"

The example above creates a new root CA directly on an offline machine with an RSA 4096 key and a 10-year validity. Notice the -nodes option: because the machine is offline, you can decide whether the private key is encrypted with a passphrase or not. Store this key in a safe place, then take the machine off the network.

Then the intermediate CA is created and signed by the root.

openssl req -newkey rsa:4096 \
  -keyout intermediate.key -out intermediate.csr \
  -subj "/CN=Intermediate CA Online"
openssl x509 -req -in intermediate.csr \
  -CA root-ca.crt -CAkey root-ca.key \
  -CAcreateserial -out intermediate.crt -days 1825

The pattern seen in the fence is the principle we are discussing: the root stays offline, while the intermediate that signs user certificates runs online. If you use step-ca, this concept can be mapped with the root CA as the source and the intermediate as the active provisioner.

#Key Rotation and Lifecycle

Key rotation is replacing an old key pair with a new one on a scheduled interval. Rotation does not mean the old key was necessarily compromised; it is risk control. The longer a key is used, the more chance it has of being analyzed or leaked. Rotation ensures the impact of a leak stays limited.

A common rule of thumb: the root CA key can survive a very long time, while intermediate keys are rotated more often. Leaf certificates should be short-lived and renewed automatically, as you saw in episode 10 with cert-manager and renewBefore.

When rotating, pay attention to the overlap period. Do not delete the old key immediately, because there are still valid certificates that trust it. Create the new intermediate, let the old one finish its validity, then retire it after all certificate holders have moved over.

#Do Not Put Private Keys in Repos

This is the rule most often violated by beginners. A .env file or config folder committed to Git is the fastest way to spread secrets. A private key in a repo means everyone with repo access, including those who have left, can issue or forge identity.

If it has already been committed, treat that key as leaked. Revoke it from all use, rotate it, and fix the repo history if necessary. Remember, deleting the file in the latest commit is not enough; Git history still holds the old version. For the future, use a secret manager, create policy so repos are scanned, and never copy keys into Docker images.

Even images are not a safe place. Images in a registry can be downloaded by anyone with access, and image layers cannot be practically removed. Private keys should be injected at runtime from a secret store, not baked into an image.

#Audit and Monitoring

A CA is an asset whose activity must be accountable. Audit here means recording every event: who issued a certificate, for what, when, and through which provisioner. These records are useful for investigation, compliance, and also for detecting anomalies.

Monitoring complements audit. Watch for certificates nearing expiry, notice abnormal issuance spikes, and set alerts when the intermediate CA nears the end of its life. A certificate that expires mid-flight is more painful than most other incidents, because it causes an outage with an unclear cause.

openssl x509 -in server.crt -noout \
  -startdate -enddate -subject

openssl x509 -noout -enddate shows a certificate's expiry date. At large scale, scripts like this are scheduled to scan all managed certificates, and the results are compared against warning thresholds.

#Compliance: PCI DSS, SOC 2, NIST, and FIPS

Compliance is the bridge between security practices and legal or contractual obligations. The four frameworks most relevant to PKI: PCI DSS for payment cards, SOC 2 for service providers, NIST for technical standards, and FIPS for crypto modules.

#PCI DSS

PCI DSS is the standard for organizations handling payment card data. PKI enters it because card data transport must be encrypted, and crypto keys must be managed well. Requirements such as using strong keys, periodic rotation, and restricting access to keys are part of the practices we discussed above.

#SOC 2

SOC 2 assesses a service provider's internal controls based on five principles: security, availability, processing integrity, confidentiality, and privacy. For PKI, auditors look at how the CA is managed: who has access, whether there is separation of duties, and how the certificate lifecycle is recorded. Clean documentation and an audit trail are the key to passing.

#NIST SP 800-57

NIST SP 800-57 is the publication most often cited for key management. It provides guidance on algorithm selection, key length, cryptographic lifetime, and usage periods. For example, the recommendation that key signing be distinguished from key encryption, and that each purpose use a different key pair.

#FIPS 140-3 and the OpenSSL FIPS Provider

FIPS 140-3 governs the crypto modules used by US government agencies and organizations that must follow them. Its focus is the module: approved algorithms, error detection mechanisms, and physical security boundaries. For those using OpenSSL, there is a FIPS mode that restricts OpenSSL to approved algorithms only.

openssl list -providers
openssl fipsinstall -out /etc/ssl/fipsmodule.cnf

openssl list -providers shows the active providers. After the FIPS module installation is complete, the OpenSSL configuration is directed to that module so only FIPS algorithms are allowed.

#Closing

Episode 16 takes you from how to build a CA to how to manage a CA responsibly. You understood the separation of an offline root CA and online intermediate, the importance of key rotation, the ban on storing private keys in repos or images, and the need for audit and monitoring. On the compliance side, you got to know PCI DSS, SOC 2, NIST SP 800-57, and FIPS 140-3.

Key takeaways:

• Separate the offline root CA from the online intermediate to limit incident impact.
• Key rotation runs on a schedule, not only when suspicion arises.
• Private keys must never enter repos or images; use a secret store at runtime.
• Record every issuance and monitor certificate validity periodically.
• PCI DSS, SOC 2, and NIST SP 800-57 provide an auditable key management framework.
• FIPS 140-3 governs crypto modules, and OpenSSL provides a dedicated provider for it.

In episode 17 we dive into X.509 formats and technical details: PEM, DER, PKCS 12, JKS, format conversion, Certificate Transparency, Extended Key Usage, name constraints, and the intricacies of RFC 5280. See you there!