Certificates

Every conversation about post-quantum risk starts with the same story: adversaries are recording encrypted traffic today and will decrypt it when quantum computers arrive. That threat — Harvest Now, Decrypt Later (HNDL) — is real, and I covered it in detail in Encryption on Borrowed Time. But HNDL has a twin that gets far less attention, and it is the one that should set your migration calendar. Trust Now, Forge Later (TNFL) uses the same mathematics to attack a different target. Instead of breaking the key exchange that protects a recorded session, it breaks the signature that anchors trust. The result is not exposed data — it is forged identity. And unlike HNDL, there is no cleaning it up after the fact. ...

I gave this talk at PA TechCon 2026 in Harrisburg on August 13. The audience was Pennsylvania state and local government IT leaders — CIOs, CISOs, procurement officers, and the county IT directors who keep the lights on with two-person teams. The premise fits in one sentence: Pennsylvania’s data has a shelf life measured in decades, and the encryption protecting it has a shelf life measured in years. Nobody has done the subtraction. ...

In July and August 2026, a coordinated cyberattack struck water systems across more than twelve U.S. states. Over a single weekend, more than thirty Minnesota water utilities lost control of their programmable logic controllers. Operators were locked out of their own equipment. Safety alarms were silently disabled while displays continued to show normal operation. Boil-water advisories went out across multiple states, and facilities fell back to manual operations — dispatching personnel to physically operate pumps and valves. ...

Enterprise certificate enrollment has a tooling problem. Most organizations run a certificate authority — often Red Hat Certificate System (Dogtag), Microsoft AD CS, or EJBCA — but getting certificates onto devices, servers, and workloads still involves brittle SCEP integrations, custom scripts, or manual CSR submission. The enrollment layer is the weak link. EST (Enrollment over Secure Transport) was designed to fix this. Published as RFC 7030 in 2013, it replaces SCEP with a modern HTTPS-based protocol that supports mutual TLS, one-time passwords, and integration with existing CAs. But production-ready EST implementations remain scarce — especially ones that meet government and enterprise compliance requirements. ...

A Certificate Authority that only speaks one protocol is a CA that only serves one audience. Enterprise networks need EST for managed devices. DevOps teams expect ACME for automated renewal. IoT deployments require CoAP for constrained devices. Kubernetes clusters want SPIFFE for workload identity. HashiCorp shops need Vault integration. And existing Red Hat infrastructure needs Dogtag compatibility. PKI.Next serves all six from a single CA, using independent protocol server binaries that communicate with the CA through mTLS-authenticated API calls. This post explains the architecture, the protocol implementations, and why the Registration Authority pattern makes this possible without compromising security. ...

In August 2024, NIST published FIPS 204, finalizing ML-DSA (Module-Lattice Digital Signature Algorithm, formerly CRYSTALS-Dilithium) as the first post-quantum digital signature standard. Six months later, RFC 9881 defined how to encode ML-DSA keys and signatures in X.509 certificates. PKI.Next supports all three ML-DSA security levels today. This post explains what that means in practice, how the implementation works, and why the engineering is harder than just swapping an algorithm. The Quantum Threat to PKI Every X.509 certificate ever issued relies on one assumption: that certain mathematical problems are hard enough that an attacker cannot reverse a signature. RSA depends on integer factorization. ECDSA depends on the discrete logarithm problem in elliptic curve groups. Both problems are believed to be computationally infeasible with classical computers. ...

This is the first post in a series about PKI.Next, a Certificate Authority built from scratch in Rust. The series covers the architecture, the cryptographic decisions, and the operational features that make a CA trustworthy enough to replace systems that have been running for two decades. Why Build a New CA? I have spent years working with Dogtag PKI, Red Hat’s Java-based Certificate Authority that has been in production since the mid-2000s. Dogtag works. It issues certificates, it generates CRLs, it handles OCSP, and it has passed Common Criteria evaluations. But it carries twenty years of accumulated decisions that are increasingly difficult to change: ...

In the previous post, I covered event-driven certificate lifecycle management — how Ansible automates revocation when identity events fire. But revocation is only half the story. Before you can revoke a certificate, you have to issue one. And for IoT devices, issuance needs to be automated, constrained, and scalable. This post digs into the enrollment side: how to configure Dogtag PKI certificate profiles specifically for IoT devices, how to expose those profiles over the EST protocol for automated device enrollment, and how to manage it all with Ansible. ...

Certificate revocation is the part of PKI that everyone knows matters and nobody wants to think about. You issue a certificate. Sometime later, that certificate needs to stop being trusted — a key is compromised, an employee leaves, a device is decommissioned. The hard part is not recording the revocation. The hard part is telling everyone about it, fast, without drowning them in data. There are two dominant approaches: OCSP (Online Certificate Status Protocol) and CRLs (Certificate Revocation Lists). Each has well-documented trade-offs. But with the emergence of CRL sharding — partitioning a CRL into smaller segments — the calculus changes in ways that are worth measuring rather than assuming. ...

Every certificate has a lifecycle: issuance, renewal, and eventually revocation. In most organizations, that lifecycle is managed through tickets, spreadsheets, and manual intervention. When a device is compromised or an employee leaves, revoking their certificate takes hours or days. Meanwhile, the identity tied to that certificate remains trusted across the network. The industry is making this worse, not better. The CA/Browser Forum passed Ballot SC-081v3 in April 2025, mandating a reduction in public certificate validity to 200 days (March 2026), 100 days (March 2027), and 47 days (March 2029). At the same time, OCSP — the protocol most organizations rely on for real-time revocation checking — is being deprecated across the industry. Let’s Encrypt shut down its OCSP responders in August 2025 after handling 340 billion requests per month at peak. Firefox replaced OCSP with CRLite as of Firefox 137. HARICA is deprecating OCSP by March 2026. The safety nets are disappearing and the timelines are compressing. Manual certificate management is no longer just slow — it is structurally incompatible with where the industry is heading. ...