Certificate Linting: The Check That Runs Before a Certificate Is Signed

What certificate linting is

Linting is a conformance check run by a program rather than a person. The Baseline Requirements define it as a process in which the content of signed data — a precertificate, a certificate, a CRL, an OCSP response — or of data-to-be-signed such as a tbsCertificate is checked for conformance with the profiles and requirements in those Requirements. A linter is a collection of small, independent rules. One checks that a required extension is present. Another checks that a DNS name parses. Another checks a key length.

The word is borrowed from software development, and the analogy holds up. A code linter reads your source and tells you which lines break the house rules before you ship them. A certificate linter reads a certificate and tells you which fields break the Baseline Requirements, RFC 5280, or a root program's policy before anyone trusts them.

What makes it necessary is the size of the rulebook. A publicly trusted TLS certificate has to satisfy the certificate profile in Section 7.1 of the Baseline Requirements, the X.509 profile in RFC 5280, and the policies of every root program that trusts the issuing CA. The Requirements say as much themselves: they introduce the linting section by citing the complexity involved in implementing conformant certificate profiles. This is a rule written by people who had watched CAs get it wrong.

When did certificate linting become mandatory?

For publicly trusted TLS certificates, on 15 March 2025. Section 4.3.1.2 of the TLS Baseline Requirements describes linting as best practice and then adds one sentence with teeth: effective 2025-03-15, the CA SHALL implement such a linting process. The rule arrived through Ballot SC-75, Pre-sign linting, adopted on 28 June 2024 and carried into Baseline Requirements v2.0.6 on 6 August 2024. The nine-month gap between the ballot and the effective date was the implementation window.

S/MIME followed a staged path of its own under ballot SMC09, and code signing did not follow at all. The table below is the current state across the three Baseline Requirements documents, as of September 2026.

That last row is worth a second look, because it is easy to assume the rule is universal. Version 3.11.0 of the Code Signing Baseline Requirements, dated 16 June 2026, does not mention linting anywhere. Code signing certificates are not exempt from being well-formed — they still have a profile to meet — but no ballot has yet made the check itself compulsory for them. Linters have run ahead of the rulebook here: zlint already ships a dedicated CABF_CS_BR rule source for code signing certificates, which CAs may use whether or not a document obliges them to.

Why does the check sit before the signature?

Because a signature is the point of no return. Before the CA signs, a malformed certificate is a draft and the worst outcome is a rejected order. After it signs, the certificate exists, a subscriber may deploy it, and the defect is a misissuance. The Baseline Requirements price that difference explicitly. Reason 12 in Section 4.9.1.1 covers a certificate the CA becomes aware was not issued in accordance with the Requirements, and the clock it starts is short: the CA should revoke within 24 hours and must revoke within 5 days.

Five days is not a long time to notify a subscriber, help them reissue, and replace a certificate on live infrastructure. It is the reason mass-revocation incidents have the shape they do: thousands of subscribers given a few days' notice because a single field in a single profile was wrong. Every one of those incidents is a case that pre-issuance linting is designed to catch while it is still cheap.

The asymmetry also explains why the Requirements treat the two directions so differently. Section 4.3.1.2 makes pre-issuance linting a SHALL. Section 4.3.1.3, linting of issued certificates, remains a MAY. Checking afterwards is useful for finding what you missed, and Section 8.7 recommends it for the quarterly self-audit sample, but it cannot prevent anything. Only the earlier check can.

One operational detail rarely gets mentioned and is worth knowing: linters themselves are moving targets. Section 6.6.1 says that a CA using third-party linting software should monitor for updates and plan to adopt them no later than three months after release. New rules appear in zlint and pkilint as ballots pass, so a CA running a year-old linter is checking against a year-old rulebook.

How do you lint a certificate that has not been signed yet?

You build a certificate-shaped object the linter can parse, without that object being trustworthy. This is the part of the requirement that sounds contradictory on first reading: linters take certificates as input, and the whole point of pre-issuance linting is that no certificate exists yet. The Baseline Requirements resolve it by naming two acceptable ways to manufacture a stand-in, and by carving out a third route through Certificate Transparency.

The first method signs the tbsCertificate with a dummy private key whose public key is not certified by any certificate chaining to a publicly trusted CA. The result parses as a certificate and fails any trust check, which is exactly what is wanted. The second specifies a static value for the signature field of the certificate's ASN.1 sequence — the structure is complete, the signature is a placeholder, and the CA's real signing key is never involved.

The third route is the precertificate, and it comes with a condition worth reading twice. Where a precertificate has already been linted, the corresponding to-be-signed certificate does not have to be linted again — provided the CA has a technical control that verifies the to-be-signed certificate corresponds to the to-be-signed precertificate in the manner described by RFC 6962 Section 3.2. Without that control, the exemption does not apply. The permission and its condition live in the same sentence, which is a detail that summaries of this rule routinely drop.

Which linters do certificate authorities actually run?

Four general-purpose linters do most of the work, and most CAs run more than one. The Baseline Requirements permit a CA to implement its own tooling but say it should use the linting tools widely adopted by the industry, pointing at the CA/Browser Forum's own tools page. The Requirements also encourage CAs to contribute back: writing new lints, reporting inaccurate results as bugs, and generating test certificates for specific rules.

Coverage differs between them, which is why running one is usually not enough. A rule implemented in pkilint may have no counterpart in zlint, and the reverse happens too. That is the problem pkimetal was built to solve. It runs certlint, pkilint, x509lint and zlint behind a single REST API, detects the intended profile of whatever you hand it, and normalises the findings into one response format. It also adds special-purpose checkers that the general linters do not include: Debian weak keys, ROCA keys, mojibake in text fields, and browser CT policy compliance in precertificates.

A caution the pkimetal maintainers publish themselves is worth repeating, because it is a good example of how far SC-75 reaches. Public hosted instances of the meta-linter exist, but they are not recommended for production use by a CA — because the ballot may cause an external linting service to be treated as a Delegated Third Party, with the audit obligations that carries. A CA is expected to run its own deployment. For a site owner checking a certificate they already hold, none of that applies.

How do you read a lint result?

Each rule returns a status rather than a simple pass or fail, and only two of the statuses mean the certificate is wrong. zlint reports seven: NA when the rule does not apply to this kind of certificate, NE when it is not yet effective, then Pass, Notice, Warn, Error and Fatal. Error means a rule was broken. Fatal means the lint itself could not complete.

NE, Not Effective, is the status most often misread. Rules in zlint carry an effective date and sometimes an ineffective date, and a certificate whose notBefore falls outside that range gets NE rather than Pass. It is the linter saying the rule did not exist yet for this certificate, which is not the same as the certificate satisfying it. When you lint an older certificate and see a wall of NE results, that is the Web PKI's rulebook growing, recorded one rule at a time.

The naming convention lets you predict severity before you run anything. A lint whose name begins with e_ may only return Error, never Warn; one beginning with w_ may only return Warn, never Error. So e_subject_common_name_not_from_san is a rule its authors consider a hard requirement, and a w_ rule is advice. What a CA does with each status is its own policy decision — the Baseline Requirements mandate that a linting process exists, not which findings must block issuance.

What certificate linting changes for you

Mostly it means fewer surprises, and one new kind of no. Linting is a control inside the CA, so on a normal order you will never see it run. Where it becomes visible is at the edges: a request that would once have been issued and quietly revoked weeks later now fails at submission instead, and the answer is final in a way it did not used to be. A CA cannot waive a lint failure as a favour, because issuing anyway would be the misissuance the check exists to prevent.

Three practical consequences follow. Organization details matter more than they did, because subject fields carrying a company name, locality and country are checked for internal consistency as well as accuracy — that mostly affects OV certificates, where verified organization data goes into the subject, and EV certificates, which add more fields still. Names in a CSR are checked for syntactic validity, so an internal hostname or an underscore that a private CA would accept will not survive. And a certificate profile your automation has produced happily for years can start failing after a ballot changes a rule, with nothing on your side having changed at all.

If you run your own internal CA, the tooling is worth borrowing regardless of whether any rule applies to you. zlint and pkilint are open source, both run locally against a certificate file, and pointing them at your internal issuance output is a cheap way to find profile mistakes that would otherwise surface as a client that refuses to connect. The public rulebook is stricter than most internal ones, so expect findings you can legitimately ignore — and read the NE results before you treat them as clean.