Announcing Certificate Profile Validation in Infrared

Try it now. The certificate profile validator and Markdown CPS generator are live at https://infrared.turbolightsolutions.com/profile. Pick an example, press Validate, and see a profile mismatch caught before issuance.

In the past year, one CA revoked tens of millions of certificates for one reason. Those certificates passed every industry-standard linter, but they still disagreed with the CA’s own policy document. A second CA hit the same class of defect twice in one month. A third CA was called out for this error in its distrust announcement. The linters that CAs run check certificates against the public standards, such as RFC 5280 and the Baseline Requirements. None of them read the CA’s own policy document. So nothing caught these cases until a third-party researcher filed a report and the five-day revocation clock started.

Infrared now enforces that policy document, and it generates it from a single source of truth.

The two previous posts made an argument and then a design. The first, Certificate Profiles Need a Single Source of Truth, showed that the CPS is a second copy of a CA’s certificate profile. The Baseline Requirements make that copy normative, with a five-day revocation clock for any disagreement. The second, Designing a Certificate Profile Format Worth Adopting, laid out the format to fix it. That format is now real. The validator that enforces it is available online as a demo at https://infrared.turbolightsolutions.com/profile.

Paste a profile, paste a certificate, and press Validate. Press Write Markdown, and the same profile generates the CPS prose. Both outputs come from one input. If you just want to see it work, the page includes ready-made examples. Pick one and press Validate. The demo runs right away, with no profile or certificates of your own required.

The validator is exhaustive. Any certificate field that the profile does not explicitly disclose is flagged as a finding. Nothing passes unless the profile accounts for it. So a field the author forgot fails the check instead of slipping through.

The incidents this catches

All three motivating incidents were the same kind of failure. The certificate passed every industry-standard linter. It was mis-issued anyway, because it disagreed with the CA’s own policy document, and no industry-standard linter reads that document. One CA mis-issued more than 75 million valid certificates. Its CPS said the keyEncipherment key usage was absent, but issuance kept including it. Another CA did the same thing twice in one month, once on id-kp-clientAuth and once on the AIA OCSP URI. A third CA made an EV edit that applied to its OV profile by mistake.

The page provides examples that reproduce exactly this class of defect, so you do not have to build a profile or test certificates to see it. There is a clean profile that passes. Next to it are several violations: a forbidden keyEncipherment key usage bit, an errant CA-specific policy OID, a disallowed subject commonName, a clientAuth EKU the profile prohibits, too many streetAddress RDNs, and a wildcard dNSName. Each one is a certificate the industry-standard linters accept but the CA’s own profile rejects. That is the exact mismatch that today becomes a Bugzilla report and a five-day revocation clock. Here it is caught before issuance instead.

It is also the Chrome requirement

Validating certificates against the CA’s own profile is no longer only good practice. Chrome’s draft Quantum-resistant Root Program (CQRP) requires each Merkle Tree Certificate CA to publish a machine-readable profile. It also makes pre-issuance linting against that profile blocking from September 15, 2027. The page is a working instance of what that needs: a profile in a format a CA can author, and a validator that enforces it against real certificates.

The demo page runs the profile check on its own. It does not execute the other validators that cover requirements such as RFC 5280 and the CA/Browser Forum TLS Baseline Requirements. But the same Infrared engine also powers the CA/Browser Forum TLS checks behind the MTC TBSCertificateLogEntry validator. In a production deployment, the profile check and the standards checks run together in one pre-issuance call. That adds the missing CA-specific tests that no industry-standard linter has ever evaluated.

Single source of truth, on display

The profile is written in JSON5, so your existing tools work unchanged. JSON5 is JSON with comments and a few conveniences for authoring by hand. Plain JSON is a subset of it, so every existing parser, editor, and diff tool is usable. The format also comes with a JSON5 schema. An editor that reads the schema gives you syntax checking, autocomplete, and inline documentation as you write. This makes authoring a correct profile straightforward. (The demo asks you to inline everything. The $includes mechanism for sharing definitions across files is part of the full tool, not the demo page, for security reasons.)

The same profile drives the Markdown CPS output. This makes the single-source-of-truth claim concrete. The certificate check and the policy document are two outputs of one input, not two artifacts someone keeps in sync. A generated document can be wrong, but it cannot drift. And if the profile itself is wrong, the same pre-issuance validation catches the mismatch before it reaches an issued certificate.

Let’s talk about your CA

The demo runs on examples and certificates you paste. Turning it into a single source of truth for a production CA is the larger job. That means connecting the profile to your CA configuration, generating the CPS section into your publication pipeline, and wiring the validator into your pre-issuance path. If you want that, whether to meet the CQRP deadline or to stop trusting hand-kept profiles in your CPS, reach out. Let’s discuss how to integrate it into your workflow and eliminate profile drift for good.

• Webpki