The DigiNotar Hack, Black Tulips, Rogue Certificates and what You´re not Being Told about PKI and Risk

07.09.2011 by Joerg Resch

DigiNotar is a Dutch “Internet Trust Provider” running a Certificate Authority (CA),  selling SSL Certificates and digital signature solutions. DigiNotar had recently been bought by VASCO.  On August 30, 2011, DigiNotar/VASCO reported that DigiNotar detected on July 19th, 2011 an intrusion into their CA infrastructure, “… which resulted in the fraudulent issuance of public key certificate requests for a number of domains, including ” In the meantime we know that so far the known number of fraudulently created certificates is beyond 500 and it concerns domains like,, the Tor anonymization network, CIA and MI6. An interim report describing the first results of a forensic investigation conducted by the experts from Fox-IT, headed by it´s founder and CEO J.R. Prins and released on Sept. 5th, 2011, found out that many Certificate Authorities managed by DigiNotar, including the PKI CA Overheid, where the Certificates for the Dutch Government are created, had been penetrated by hackers with root permissions. Besides the already mentioned Overheid CA the Fox-IT report mentions the CAs of the Dutch Federal Ministry of Justice, the Koninklijke Notariele Beroepsorganisatie CA (maybe the CA where digital certificates for the Dutch Notaries have been issued?), Renault Nissan Nederlands, Technical University Delft and many others, which were compromised. DigiNotar now is under control of the Dutch Government.

So far, one rogue certificate issued for the domain has been misused by Iranian hackers to perform man-in-the-middle attacks mainly against co-patriots using Google Gmail to write and read emails. Note: the rogue certificate itself is not yet enough to run this kind of attack. The hackers additionally need access to the DNS system in order to deviate Internet traffic from the real Gmail server to a different one. In a country like Iran this of course is not a problem.

As each use of a certificate causes a verification call to the CA, which had released the certificate, the number of such attacks can be counted precisely (OCSP responder traffic). Between July 27 and August 29, 2011, 300,000 Google Gmail sessions had been hijacked. The very very sad thing about this information is that during the period of attack DigiNotar did know that they had been hacked, but they kept it secret. This is not the kind of trust a trust provider should provide. Considering that Iranian hackers may at least be supported by their government, as such hacking would provide the government with intelligence about the political opposition in their country, the trial to keep this “accident” private may cause Iranian dissidents to face sanctions from their governments.

Beyond the obvious aim of the attack to control Iranian internet outside Iran, there also may be some revenge involved, answering the virus attacks against the Iranian atomic plant in Bushher. A real cyberwar, so to say, with DigiNotar being a (indeed very weak) piece of the western world Internet security backbone called PKI. One more piece, as it has not been the first attack against PKI. In March this year Comodo, another Internet Trust Provider, had been victim of an attack, where somebody compromised a user account to create 9 rogue certificates. It seems that both attacks had been conducted by the same hacker or group of hackers, as he/they left the same message on the servers (“Janam Fadaye Rahbar” – which means something like “my life for the leader”). Furthermore, there just appeared a message on pastebin, which seems to have been posted by the hacker(s):

“You know, I have access to 4 more so HIGH profile CAs, which I can issue certs from them too which I will, I won’t name them, I also had access to StartCom CA, I hacked their server too with so sophisticated methods, he was lucky by being sitted in front of HSM for signing, I will name just one more which I still have access: GlobalSign, let me use these accesses and CAs, later I’ll talk about them too…”

So, there is more to come and we should now start to think about the consequences that can be drawn from the fact that CAs can be compromised at any time. Is PKI as secure as we have been made to believe, even from governments? Maybe, as a starter, have a look at this more than 10 years old article from well known security expert Bruce Schneier, which I kind of referenced in my headline: “Ten Risks of PKI: What You´re not Being Told about Public Key Infrastructure“. Much of what he wrote is still true, and some things have gone even worse. While Schneier had asked in his “Risk#1: Who do we trust, and for what?”,  who authorized the CA to behave like an authority in granting authorizations and while he found the term “trusted” to be misused in the case of CAs, today such authorizations are in place. By law. By legal document. In the case of DigiNotar, the Dutch government even used the hacked infrastructure to run that one root CA, which should be the last one to be hacked before a country loses its independence.

In his “Risk#9: How secure are the certificate practices?”, Bruce Schneier states:

“Certificates aren’t like some magic security elixir, where you can just add a drop to your system and it will become secure. Certificates must be used properly if you want security.”

PKI leaves plenty of space for insecure practices. Although there have been several incidents now suggesting that we have a serious problem with bad practices at trusted (sic!) third parties, it may be the vast majority that are safe and indeed trustworthy. Sure? It´s unfortunately not for us to decide, which CAs are trustworthy and which not. This decision is being taken fo example by the browser manufacturers, because it is them who manage the lists of trusted certificates, which are part of each browser. Wouldn´t it be better if the trust decisions are left to the users, without any influence? DigiNotar has now been deleted from all those lists, so that you will get a warning if a server uses a certificate issued by them. Comodo has not been deleted. What is it that makes the difference?

So, PKI seems to not be the trust model that will last forever, at least not without some fundamental renovation. But what can we do in the meantime? As a trust provider: don´t make the management part of your CA software available in the cloud. That would not be good for you. As a client, you should have a business continuity plan telling what to do if your Root CA is compromised, even or especially if that Root CA is managed by a 3rd party.

Venafi´s Calum MacLeod just sent out a mail proposing 4 steps to make you survive a compomised root CA:

  1. Have more than one, so that you can just throw away the compromised one.
  2. Organizations must have an accounting of all the CAs that they use as third party trust providers
  3. They must have a complete inventory of the owner and location for each certificate in the enterprise. This often numbers in the thousands and even tens of thousands or more in Global 2000 organizations.
  4. Every organization must have an actionable and comprehensive plan in place to recover from a CA compromise. The time to recover needs to be measured in hours, not weeks or months.

Even if these proposals come from a key and certificate management vendor – they aren´t wrong at all.



  • peter bachman

    I've been thinking about how to solve this ever since I read the EFF Observatory report regarding CAs and their complex multiple cross certified trust relationships.

    It's a multi-trillion dollar hang over from the dot com boom when the CAs decided to engineer their own approach to X.509v3 without a corresponding link to the verified identity of the certificate issuers in the X.500 Directory, i.e. self signed roots or "zombie roots" stored in browsers. If the CA is "too big to fail" then there's yet another problem, which won't be resolved by removing them from a trusted list for browsers.

    Not surprisingly, if one goes back and reads the actual documentation on X.509v3 the problem becomes clear. The certificate "subject" identity is established in the X.500 Directory, to support and verify the same subject attribute in the certificate issued by the CA. It would be pretty simple to determine that DigiNotar would not be authoritative for *, or in the case of the forged Comodo certificates earlier. Note there is a difference between a trusted certificate, falsely issued, or forged, and a stolen certificate.

    The certificate is an independent security object, portable, but the identity for the issuance of that is in the Directory, which case it can be listed under the PKICA object.

    If identity is verified in the Directory, and some funding for infrastructure is found similar to ICANN, then it's not too late. It still won't excuse sloppy security by a CA if they don't report a breach, especially when they see the OCSP requests, but it would be pretty simple to figure out who is responsible for * and query that CA to determine if the certificate is genuine. It's only part of the puzzle, but an important part that should be present. Right now the end user would is forced to look inside the certificate, and then add the OCSP server CRL endpoint to their browser configuration. I actually had Verisign refuse a certificate for the other day.

    • Joerg

      Dear Peter,
      thanks for your comment. Yes indeed, issuing certificates may be even more profitable than printing money, because you don´t need to buy paper. And yes, a fundamental weakness of the entire SSL PKI system lies in the fact, that _any_ CA can corrupt the whole infrastructure. On the other side, if the authorization to issue a certificate for a certain domain is limited to a certain CA, then the owner of that one domain should do a prayer every day that his certificate provider is a good one.

  • @netsociology

    "Wouldn´t it be better if the trust decisions are left to the users, without any influence?"

    Of course – if the user is able to make a good decision. But who is? Is this a model for the average user? One should be skeptical.

    • Joerg

      Yes, that´s the solution. And it is already invented: . It´s called Convergence and currently works as a browser plugin which lets you decide yourself which CAs to trust. If we add the upcoming DNS Security Extensions to this new kind of distributed trust, then we´re much closer to something more future-proof.

      • Frank Brückner

        Hmmm, is convergence really the solution ? I installed it in a test environment. There are 2 notaries configured: "" and "". Why should I trust them more than Comodo or DigiNotar ?

        There is exactly 1 CA where I know a little how they (and their Web-of-trust) operates. And that's CAcert. But they are not pre-installed in the browsers.

        BTW: It is worth to look at and… .


        • Joerg

          Thanks for your comment, Frank.
          Yes, the presentation of Moxie Marlinspike is very interesting, and Giovanni´s blog entry as well. I left the following message there:

          I still believe that convergence is a first step into the right direction. A small step technically, a big step regarding CA business models.
          Let´s have one more look at the DigiNotar case. Some hacker penetrated their whole infrastructure and issued over 500 rogue certificates. DigiNotar did not disclose this “incident” and therefore those rogue certificates were fully trusted ones. The hacker seems to live in Iran and support the regime there. Maybe more kind of self-employed than being a paid “digital soldier”. Nevertheless, Iran on the one hand wants to control communication of the political opposition and on the other hand would love to strike back as a revenge for the SCADA attack against their atomic program. We are facing a period with a high amount of “rogue energy”.
          SSL, DNSSEC and whatever else we currently do for Information security and privacy on the Internet is not designed to withstand this kind of attacks.
          Trust relationships need to be based on “crowd intelligence” and they need to be agile also in a way that trust levels appropriate to the protected process can be defined.

          Notaries for the Convergence system are not existing yet. The more participate, the better Convergence will be. The opposite to the CA system we have now: The more CAs the higher the risk.

  • robert

    Aren't humans almost every-time the weakest link ? Whatever scheme is created there will always be a weak spot.
    I hope that a combination of CA, DNSsec and DANE will prove a better alternative for the current situation. That would create three parallel checks. And somehow a second DNS check to confirm the validity of the main DNS server might also be a good thing. (I think)


    • Joerg Resch

      Thanks, Robert.
      I think we shouldn´t look at us humans to be the weakest link. We are more kind of the reason for security needs ;) Typical human behavior should be part of the security design, not one of it´s risks.

© 2015 Joerg Resch, KuppingerCole