Meerkat Multi-Linter: Run Every X.509 Linter in One Place

The Problem with Post-Issuance Certificate Errors

Certificate issuance is one of the most rule-dense operations in software. A single TLS end-entity certificate must simultaneously satisfy RFC 5280, the CA/Browser Forum Baseline Requirements, the issuing CA's CPS, and — depending on the certificate type — S/MIME BRs, ETSI EN 319 412, or CT log acceptance policies. No single tool covers all of these, and the rules change with every quarterly CABF ballot.

The practical consequence: errors slip through. A certificate can pass one linter and fail another. A profile that was valid last quarter may have a new MUST requirement today. Revocation infrastructure can be structurally sound on paper but return malformed OCSP responses at runtime.

The Meerkat Multi-Linter runs all major linters against a single certificate in one session, adds live revocation validation, and surfaces the results in a unified interface — without copying PEMs across tabs.

What the Tool Runs

Each linting engine has a different lineage, rule set, and blind spot. Running one is not enough.

OpenSSL chain verification is also available in two modes: against the system trust store, and against a supplied issuer certificate. This confirms whether the chain builds correctly end-to-end, independent of the lint rules.

Revocation Deep Validation

Certificate linters check the PEM. Revocation validators check what is actually running. These are different questions.

Once a certificate is pasted and parsed, the tool detects whether it carries an OCSP URL (AIA extension), a CRL distribution point, or a Delta CRL pointer. For each one present, a revocation check button becomes active:

• OCSP Deep Validator — fetches the live OCSP response for the certificate, decodes it, and lints it against RFC 6960 and CABF requirements. Validates the responder signature, the thisUpdate / nextUpdate window, and the response status.
• CRL Deep Validator — downloads the CRL from the certificate's CDP extension, parses the entry list, and verifies the CRL signature and validity period.
• Delta CRL Deep Validator — same as above for the delta CRL referenced in the Freshest CRL extension.

pkilint and pkimetal also expose their own revocation validators, which run the same live fetches through their respective lint engines for a second opinion.

How It Differs from crt.sh and Other Online Tools

The tool links to crt.sh for complementary searches — CT log discovery, certificate history, and monitor subscriptions. These are distinct functions. crt.sh is the right tool when you want to find certificates; this tool is the right tool when you want to lint one.

Where they overlap is in linting, and the differences are architectural:

• Execution environment. crt.sh lintcert delegates to Sectigo's infrastructure. The multi-linter here runs linters installed on this server and executes revocation fetches from this server's network — which matters when you are testing internal or staging infrastructure that is not publicly reachable.
• Revocation validation. crt.sh shows lint findings on the certificate PEM. This tool additionally fetches and lints the live OCSP response and CRL — validating what the revocation infrastructure actually returns at runtime.
• Profile-aware linting. The profile selector (autodetect, TLS, S/MIME, ETSI) allows pkilint to apply the correct rule set for the certificate type, avoiding false positives from cross-profile validation.
• CT compliance linting. ctlint validates the embedded SCT list against current CT policy requirements — something crt.sh does not surface in its lintcert endpoint.
• CCADB integration. Certificates found through the CCADB Browser can be sent directly to the linter with the chain pre-loaded. No copy-paste required.

Profile Selection

The profile selector controls how linters interpret the certificate's intended use:

• Autodetect — the tool infers the profile from the certificate's EKUs, SAN types, and extension values. Correct for most cases.
• TLS / serverAuth — applies CA/B Forum TLS Baseline Requirements. Use this when autodetect misidentifies a TLS certificate.
• S/MIME — applies CA/B Forum S/MIME Baseline Requirements. Required for email-validated certificates.
• ETSI — applies ETSI EN 319 412 profiles for qualified and regulated EU certificates.

How to Use It

Option 1: Paste a PEM

1. Paste the end-entity certificate PEM into the End-Entity Certificate field.
2. Optionally paste the issuing CA certificate PEM into the Issuer / Root CA Certificate field. Some linters (pkilint signer/signee, OCSP validator) require it; others work without it.
3. Select a profile or leave it on Autodetect.
4. Click any linter button. Results appear below the form. Run multiple linters in sequence to compare findings.
5. If the certificate has OCSP or CRL extensions, revocation validator buttons will appear. Click them to fetch and lint the live revocation data.

Option 2: Fetch from a domain

1. Type a hostname (e.g. example.com) into the domain field and click Fetch Certificate →.
2. The tool connects to port 443, extracts the end-entity certificate and the first chain certificate, and populates both PEM fields automatically.
3. Proceed with linting as above.

Who This Is For

• CA operators running post-issuance checks before delivery: confirm the certificate passes all relevant linters and that the revocation infrastructure responds correctly for it.
• PKI engineers integrating new certificate profiles: catch profile violations early, before the certificate reaches a root program review or a relying party with strict linting in their pipeline.
• Auditors spot-checking a CA's issuance quality: fetch a live certificate, run all linters, and validate the OCSP response — in one session, without installing tooling locally.
• Security researchers analysing certificates from CT logs: paste the PEM from crt.sh, run the full linter set, and drill into revocation status without switching tools.