Hey, I’m Chris

Post-quantum cryptography is no longer a standards exercise. ML-KEM key exchange is the default in every major browser and in OpenSSH. RHEL 10 ships with post-quantum TLS and SSH enabled out of the box. DigiCert is issuing ML-DSA certificates today. But “available” and “deployed” are not the same thing. Key exchange is largely solved. Authentication — the part where certificates, signatures, and trust chains live — is not. The gap between what the standards define and what production systems can actually verify is where most of the engineering work remains. ...

Every X.509 certificate, every CRL, every OCSP response, every CSR is encoded in ASN.1 DER. If you are building PKI software in Rust, ASN.1 encoding and decoding is the foundation everything else rests on. Get it wrong, and certificates parse incorrectly. Get it slow, and your CA cannot keep up with issuance. Get it fragmented across multiple libraries, and you spend more time managing dependencies than building features. PKI.Next was using six ASN.1 crates simultaneously. We replaced all of them with synta in a single commit. This post explains why, how, and what we gained. ...

Dogtag PKI has been Red Hat’s Certificate Authority since 2005. It started as Netscape Certificate Management System, became Red Hat Certificate System, was open-sourced as Dogtag, and is now the CA backend for FreeIPA — Red Hat’s identity management platform that manages certificates, Kerberos, DNS, and SUDO for enterprise Linux environments. Dogtag works. It has passed Common Criteria evaluations. It runs in government agencies, financial institutions, and large enterprises. It has issued millions of certificates in production. ...

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

Every CA operation is an audit event. Certificate issued. Certificate revoked. CRL generated. User created. Profile modified. If you cannot prove that the audit log is complete and unmodified, you cannot prove that the CA has been operated correctly. This is not a theoretical concern — it is a certification requirement. Common Criteria Protection Profile for Certification Authorities (PP_CA v2.1) includes requirement FAU_STG.2: the CA must detect modification of stored audit records. PKI.Next implements this through HMAC-based hash chaining, where every audit record includes a cryptographic hash that depends on the previous record, creating a tamper-evident chain that detects insertion, deletion, or modification of any record. ...

A Certificate Authority has a unique constraint that most software does not: the cryptographic backend is not just a library choice, it is a compliance decision. Government customers require FIPS 140-3 validated modules. Financial institutions require hardware security modules. Development teams need fast builds without hardware dependencies. These are three different backends with three different dependencies, build processes, and runtime characteristics — and the CA business logic should not care which one is active. ...

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