Certificates

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. ...