Block additional DigiNotar certificate issuer names listed in Fox-IT September 25th draft report




Security: PSM
7 years ago
6 years ago


(Reporter: briansmith, Assigned: briansmith)



Firefox Tracking Flags

(firefox6- wontfix, firefox7+ wontfix, firefox8+ wontfix, firefox9+ wontfix, blocking1.9.2 .23+, status1.9.2 wontfix, blocking1.9.1 -)


(Whiteboard: [sg:high])


(2 attachments)

Created attachment 558376 [details]
Fox-IT Interim report: DigiNotar Certificate Authority breach “Operation Black Tulip” September 5, 2011

Fox-IT listed the following as CAs as being compromised.


Evidence was found that the following CAs were misused by the attacker(s):

- DigiNotar Cyber CA
- DigiNotar Extended Validation CA
- DigiNotar Public CA - G2
- DigiNotar Public CA 2025
- Koninklijke Notariele Beroepsorganisatie CA
- Stichting TTP Infos CA

The security of the following CAs was compromised, but no evidence of misuse was found (this list is incomplete):

- Algemene Relatie Services System CA
- DigiNotar PKIoverheid CA Organisatie - G2
- DigiNotar PKIoverheid CA Overheid en Bedrijven
- DigiNotar Qualified CA
- DigiNotar Root CA
- DigiNotar Root CA Administrative CA
- DigiNotar Root CA G2
- DigiNotar Root CA System CA
- DigiNotar Services 1024 CA
- DigiNotar Services CA
- EASEE-gas CA
- Hypotrust CA
- MinIenM Autonome Apparaten CA - G2
- MinIenM Organisatie CA - G2
- Ministerie van Justitie JEP1 CA
- Nederlandse Orde van Advocaten - Dutch Bar Association
- Orde van Advocaten SubCA Administrative CA
- Orde van Advocaten SubCA System CA
- Renault Nissan Nederland CA
- TenneT CA 2011
- TRIAL DigiNotar PKIoverheid Organisatie TEST CA - G2
- TU Delft CA

For some of these CAs extra security measures were in place (like the CCV CA). This makes it more unlikely they were misused.


We have seen requests for unknown serials that cannot be matched against a known certificate. It‟s possible that these serials belong to a “rogue” certiticate or are just bogus OCSP requests, for instance done by security researchers. It‟s still possible other unknown rogue certificates have been produced.

I requested more information by email regarding these CAs. I have not received useful responses yet. So, it seems like we will have to implement any blocks by using only the information we have available above--which is basically a list of (probably) substrings of the CA certificates' subject distinguished names.

-- BEGIN QUOTED EMAIL from me to Fox-IT and the Dutch officials --

1. Do any of these rogue certificates have the CA bit set in their basic constraints?

2. Where can I get the certificates for

   "Koninklijke Notariele Beroepsorganisatie CA"
   "Stichting TTP Infos CA"

   Could you please send them to me?


-- BEGIN QUOTED EMAIL from Fox-IT & Dutch officials to me --

1) We do not know for sure because we don't have the actual rogue certificates in question, what I do know is that the RSA KEON logging logs a different string if it signs a CA certificate. For all the rogue certificates that we know of were NOT signed as CA certificates.

2) I have also this request from Microsoft. We will try to find them today in the forensic images of the CA systems ASAP. I will get back to you when I know more.


-- BEGIN QUOTED EMAIL from me to Fox-IT and the Dutch officials --

Thanks. I have read your public interim report dated September 5. Do you have any additional information that you can share with us? I have some additional requests. It would be great if I could get this information soon as we may update our software (Firefox) once again in response to your report.

In the report you mention the following CAs and say the list is incomplete. Please send us a (more) complete list of CAs, beyond the "incomplete" list.

Could you please tell me what the certificate chains are for these? In particular, which ones chain to the DigiNotar Root CA certificate? And, more importantly, which ones don't.

Could you please send me a copy of each of these CA certificates? And/or please send any more information you have about them--especially the full subject distinguished name. Without this information, we are probably going to end up implementing a block which will be too general which would likely cause further difficulties in migrating Dutch government services to a new certificate hierarchy.


Since we don't have these certs, the NSS-level blocking we have now to protect non-SSL code paths is probably insufficient. We probably need to modify all code paths that call CERT_VerifyCert* to apply the additional DigiNotar blacklisting logic that we are currently applying for only SSL.

While we are at it, we should (temporarily) disable the ability to use libpkix for certificate path validation, as I believe that the blacklisting code will not work for libpkix mode.
Created attachment 558420 [details]
ComodoHacker's initial message on pastebin (, Striking_Back....txt)

Here is the message that was posted by user "ComodoHacker" on Pastebin. Saved here just in case Pastebin goes down (again).
Here is my ongoing effort to document the DigiNotar certificate hierarchy, and determine whether there are any certificate they controlled which would be missed by our current block:

With the help of GovCERT and my own investigations, I have now basically completed the document linked to in comment #4. There are several 'root' (self-signed) and intermediate certificates listed in the Fox-IT report which do not chain up to either the DigiNotar Root CA or the Staat der Nederlanden roots. However, none of them chain up to a different root which is trusted by default by NSS.

Do we need to take action against known-compromised certificates which do not chain up to a root trusted in Firefox by default? Surely that's a key management problem for the people distributing the roots to which they chain? No-one is blocking OCSP on the Dutch internet...



7 years ago
blocking1.9.1: ? → -
blocking1.9.2: ? → .23+
status-firefox6: affected → wontfix
tracking-firefox6: ? → -
tracking-firefox7: ? → +
tracking-firefox8: ? → +
tracking-firefox9: ? → +
Based on Gerv's analysis, there is nothing to do here.

> Do we need to take action against known-compromised certificates
> which do not chain up to a root trusted in Firefox by default?

No, we want, because there is an unbounded number of compromised (root) CA certificates.
Last Resolved: 7 years ago
Resolution: --- → WONTFIX


7 years ago
tracking-fennec: ? → ---
status1.9.2: --- → wontfix
status-firefox7: affected → wontfix
status-firefox8: affected → wontfix


6 years ago
status-firefox9: affected → wontfix
You need to log in before you can comment on or make changes to this bug.