Misissuance (Certificate misissuance)

Misissuance covers two broad kinds of problem. The serious kind is a certificate issued to someone who does not control the domain, for example because of a flawed DCV method or ignored CAA records. The more common kind is a certificate for the right owner that is still non-compliant: an invalid encoding, a forbidden extension, a validity period above the maximum, or a serial number with too little randomness. Both count, and a logged precertificate counts as issuance even if the final certificate never appeared.

Why it matters

Root programs expect a CA that finds or is told about misissuance to stop the cause, publish an incident report (Mozilla tracks these in its Bugzilla) and revoke the affected certificates within the Baseline Requirements deadline, generally 5 days for non-compliant certificates. Repeated incidents and slow or incomplete revocation are what lead to distrust. Certificate Transparency made misissuance detectable: researchers run certificate linters such as zlint and pkilint over CT logs, and domain owners can spot certificates they never requested.

Example

A CA discovers that a software change caused it to issue certificates with a malformed extension for a week. It must report the incident and revoke those certificates within 5 days. Affected site owners receive a notice and must replace their certificates quickly, which is why automated renewal, ideally driven by ACME Renewal Information, matters even for certificates that are nowhere near expiry.

Common misconceptions

• Misissuance means the certificate went to an attacker. Most cases are technical compliance errors for the legitimate owner, but they still require revocation.
• Small formatting errors do not matter. Strict parsers can reject malformed certificates, and the rules require revocation regardless of perceived risk.
• Certificate Transparency prevents misissuance. It only makes misissued certificates visible after the fact.