A rogue wildcard for google.com
On August 28, 2011, the contents of a wildcard certificate for *.google.com were posted publicly. The certificate had been issued by DigiNotar, a Dutch certificate authority, and it had not yet been revoked. According to the Fox-IT forensic report commissioned by DigiNotar and the Dutch Ministry of the Interior and Kingdom Relations, that certificate had been used for weeks in a man-in-the-middle attack on approximately 300,000 users, almost exclusively located in Iran. Traffic intended for Google subdomains was likely intercepted or redirected, potentially exposing the contents of the intercepted traffic and the Google credentials of affected users (Fox-IT, Black Tulip Report, management summary).
The incident is usually told as a story about one negligent CA. The forensic record supports a narrower and more useful reading: DigiNotar is a demonstration of a structural property of the Web PKI. Because browsers trusted every root for every name, the compromise of a single Dutch CA was sufficient to intercept Gmail for users in Iran. The response that followed — total revocation and removal from trust stores — was not an overreaction. It was the only remedy the architecture offered.
What the certificate path validation model actually promises
RFC 5280 profiles the X.509 v3 certificate and v2 CRL for the Internet and specifies an algorithm for certification path validation (RFC 5280). The algorithm is about building a chain from a leaf certificate to a trusted root and checking signatures, names, validity periods, and constraints along the way. It is a verification procedure, not a governance procedure. It says nothing about whether the root at the top of the chain is competent, honest, or independent of the state in which it operates.
In practice, the Web PKI added a second rule that RFC 5280 does not contain: any trusted root can vouch for any name. There is no name-constrained delegation in the default browser trust model that would have prevented DigiNotar from issuing for google.com. That is why the breach was not contained to DigiNotar’s customers. Every certificate the CA had issued, and every certificate it might have issued, became suspect at once.
The timeline the forensic record establishes
The Black Tulip report reconstructs the intrusion in detail. The outer limits of DigiNotar’s network were first breached on June 17, 2011. The intruder tunneled through compromised systems and reached the Secure-net segment containing the CA servers on July 1. The first attempts to create rogue certificates were made on July 2, and the first rogue certificate was successfully issued on July 10 (Fox-IT, investigative summary).
Detection came on July 19 during a routine security check, when the signing of 128 rogue certificates was found. More were discovered over the following days and revoked. On July 29, a *.google.com certificate was found that had not been revoked; it was revoked that day. DigiNotar believed the intrusion had been contained by the end of July. The public disclosure of the wildcard certificate on August 28 showed otherwise.
Two operational details from the report matter for how the incident was handled. First, the OCSP responder was changed on September 1 so that any unknown serial number it had authority over would be answered as revoked, effectively revoking all remaining rogue certificates issued by the intruder. Second, the report notes that the OCSP responder’s normal answer for an unknown serial would have been “good” — a detail worth sitting with, because it means the revocation mechanism depended on the CA’s own records being complete and trustworthy at exactly the moment they were not.
Why the response had to be total
The Fox-IT investigation found that all eight servers managing Certificate Authorities had been compromised. Log files were generally stored on the same servers that were compromised, and evidence was found that they had been tampered with. The report is explicit about the consequence: suspicious entries could support inconclusive observations, but the absence of suspicious entries could not be used to conclude that no unauthorized actions took place.
Serial numbers for certificates that did not match DigiNotar’s official records were recovered on multiple CA servers, including the Qualified-CA server used for accredited qualified and government certificates. The report also notes that the CA software may have been able to produce certificates with attributes identical to previously issued ones, differing only in public key and key identifier. The conclusion follows directly:
Since the possibility could not be excluded that the compromised CA servers had been abused to issue additional rogue certificates and since the rogue certificates may not be distinguishable from legitimate certificates in aspects that are relevant for the purpose of verification within a PKI, it was no longer possible to rely on the authenticity of any certificates that had been issued by the affected Certificate Authorities.
That sentence is the whole case for removing the root. It is not a judgment about DigiNotar’s intentions. It is a statement about the evidentiary limits of an audit trail that lived on the systems being audited. The report identifies a non-exhaustive list of 531 rogue certificates with 140 unique distinguished names and 53 unique common names — non-exhaustive precisely because the records could not be trusted to be complete.
DigiNotar’s own public statement, filed with the SEC, said the source of the requested validations strongly indicated the certificates were used to obtain confidential information of people in Iran, and that the company believed the hacking action was politically inspired (DigiNotar statement). The forensic report states that several traces independently point to a perpetrator located in Iran. Neither document establishes state sponsorship, and the record does not support going further than it goes.
What Certificate Transparency was designed to do — and not do
RFC 6962, published in June 2013 with B. Laurie, A. Langley, and E. Kasper of Google as authors, describes an experimental protocol for publicly logging TLS certificates as they are issued or observed, so that anyone can audit CA activity and notice the issuance of suspect certificates (RFC 6962). The design rationale is stated plainly in the document itself:
The logs do not themselves prevent misissue, but they ensure that interested parties (particularly those named in certificates) can detect such misissuance.
That distinction is the part most often lost in retellings. Certificate Transparency is a detection mechanism. It makes misissuance visible after the fact, to the parties named in the certificate and to anyone monitoring the logs. It does not stop a compromised CA from signing a fraudulent certificate, and it does not stop that certificate from being used in the interval before a monitor notices it.
The logs are also designed with the DigiNotar failure mode in mind. RFC 6962 specifies append-only Merkle trees with consistency proofs, so that a log cannot show different things to different people without detection. The logs are separate, publicly auditable services rather than records kept by the CA on its own infrastructure. That is a direct architectural answer to the problem Fox-IT documented: audit evidence is only as trustworthy as its independence from the system being audited.
The causal story is looser than the folklore
DigiNotar is frequently narrated as the origin story of Certificate Transparency. The retrieved record does not support that causal claim. RFC 6962 is dated June 2013, nearly two years after the breach, and its authors were at Google. The document frames CT as a general mechanism to mitigate misissued certificates, not as a response to a specific incident. The breach is better read as a vivid validation of the monitoring model than as its proximate cause. The honest version is that CT addresses the class of failure DigiNotar exemplifies; whether the breach accelerated work already underway is a question the primary artifacts here do not answer.
What the record does show is a governance asymmetry. Removing a root from a browser trust store is a unilateral decision a vendor can make quickly. The standards response — baseline requirements, ballots, multi-party consensus — moves more slowly by design. That is not a criticism of either process. It is a structural feature of Web PKI governance: emergency action is centralized in a small number of browser vendors, while durable rule-making is multilateral and slow. The DigiNotar case is a clean illustration of both halves of that arrangement operating at once.
What remains unresolved
Certificate Transparency narrows the window between misissuance and detection. It does not close it. A rogue certificate can be used from the moment it is issued until a monitor sees it in a log and someone acts. In the DigiNotar case, the gap between the first rogue certificate on July 10 and the public disclosure on August 28 was measured in weeks, and the certificate was in active use for much of that time.
The residual risk is borne by end users, who have no visibility into the logs and no practical way to know that a certificate presented to their browser was issued by a compromised CA. The operators who can act — browsers, monitors, the CAs themselves — act on their own timelines. The question DigiNotar leaves open is not whether the trust model can be made more auditable. CT answers that. The open question is who is responsible for the interval between issuance and detection, and what remedy exists for the users inside it. The forensic record documents the harm. It does not assign the residual risk to anyone in particular.
FAQ
Did DigiNotar’s breach cause Certificate Transparency to be created?
The retrieved sources do not establish that. RFC 6962 is dated June 2013 and describes CT as a general mechanism for detecting misissued certificates. It is accurate to say CT addresses the class of failure DigiNotar exemplifies; it is not accurate, on this record, to say the breach caused CT.
Why couldn’t DigiNotar simply revoke the fraudulent certificates and continue operating?
Because the forensic investigation could not establish the full set of certificates that had been issued. Logs were stored on compromised servers and had been tampered with, and serial numbers not matching official records were found on multiple CA servers. The Black Tulip report concluded it was no longer possible to rely on the authenticity of any certificates issued by the affected CAs.
Does Certificate Transparency prevent a compromised CA from issuing a fraudulent certificate?
No. RFC 6962 states that the logs do not themselves prevent misissue; they ensure that interested parties can detect it. CT is a detection and audit mechanism, not a prevention mechanism.
How many users were affected?
The Fox-IT report describes a MITM attack on approximately 300,000 users, almost exclusively located in Iran, based on OCSP responder logs for the rogue *.google.com certificate. The report identifies a non-exhaustive list of 531 rogue certificates, so the full scope of issuance is not known.