Summary

  • DigiCert disclosed that some CNAME-based domain validations ran without the underscore prefix the method requires, a defect it says touched approximately 0.4% of applicable domain validations.
  • It then applied the CA/Browser Forum 24-hour revocation rule to itself, recalculated the deadline from a different starting event, and extended revocation by up to 120 hours to 3 August 2024 at 19:30 UTC — a deadline only it could move.

A certificate authority's domain control validation is the step where a request stops being a claim and becomes a certificate. The CA checks that the applicant really controls the name, and then signs. That check is code, so it can be written correctly, reviewed correctly, and still disagree with the method it is supposed to implement.

DigiCert's CNAME-based path disagreed. "Recently, we learned that we did not include the underscore prefix with the random value used in some CNAME-based validation cases," the company wrote on its own incident page (DigiCert incident page).

The underscore is not decoration. In CNAME-based validation the applicant publishes a random value in a DNS record under a prefixed label and the CA reads it back; leave the prefix out and the check as executed is not the check as specified. DigiCert puts the scope at approximately 0.4% of applicable domain validations (DigiCert incident page). That share is the operator's own published figure. No independent count of affected certificates or customers appears in the material reviewed here.

Now the part that makes this file worth keeping. Detection was DigiCert's. Disclosure was DigiCert's, on DigiCert's page, in DigiCert's words. And the rule enforcement that followed was DigiCert's too.

At 02:17 UTC on 29 July 2024 the company filed a preliminary incident report, and at 22:36 UTC the same day it sent the revocation notice, stating: "The 24-hour revocation rule applies in this circumstance as the issue impacts domain validation" (Mozilla Bugzilla 1910322). The CA/Browser Forum Baseline Requirements text for that rule was not retrieved in this reporting; the rule appears here only as DigiCert characterised it, and nothing below is a finding that the extension did or did not comply with it.

The next document is where the clock becomes visible, and where it becomes a decision. "The 24 hours expired at 22:36 - 24 hours from when we had the serial numbers" (Mozilla Bugzilla 1910805). That sentence fixes a deadline and, in the same breath, exposes that the deadline rests on a choice: which event starts the twenty-four hours. DigiCert's own report notes the ambiguity instead of settling it.

What followed was not a missed deadline. It was a moved one. The same report records a decision to delay revocation by up to 120 hours, taken after discussions concerning customer impact, legal action and exceptional circumstances (Mozilla Bugzilla 1910805). No outside party is recorded as approving, ordering or overturning that decision.

The replacement deadline landed on the status page: "All certificates impacted by this incident, regardless of circumstances, will be revoked no later than Saturday, August 3rd 2024, 19:30 UTC" (DigiCert Status). The same history records that identified TLS certificates were revoked on 3 August 2024 at approximately 19:30 UTC. Those are the operator's timestamps. Independent confirmation of revocation for affected serials was not obtained, and the revocation record here is therefore the obligated party's word about the obligated party's work.

One more artefact repays a second look, because it shows what a public incident page actually is. The page was published 29 July 2024 and is marked updated 4 August 2024, and it now tells affected customers to replace certificates by 9 August 2024 at 20:30 UTC (DigiCert incident page). That instruction is a later update, not the original deadline. Anyone reading it today sees the settled version of a document that was rewritten while the incident was live.

What a reader will not find in that record is an outside verdict. No Mozilla root-programme or browser-vendor enforcement action, ballot or follow-up consequence appears in the four documents reviewed for this briefing — DigiCert's incident page, its two Bugzilla reports and its status history — and this briefing asserts no enforcement outcome.

The dependable parts of this repair are real. A revoked serial is observable, an expired certificate fails to connect, and a replacement instruction can be followed. The parts that cannot be checked from outside are the ones that decided the schedule: which event began the clock, why the extension ran to five days rather than one, and whether anyone with authority over the rule agreed. DigiCert, Inc. keeps a directory entry in this publication's register; the entry records an institutional footprint, not a verdict on validation practice.

The record shows an operator that disclosed quickly, argued its case in public, and then met the deadline it had written for itself. It also shows that the deadline moved because the party under the obligation moved it.