Skip to content. | Skip to navigation

Personal tools
Log in Register
You are here: Home Articles Protecting Your Mac From the Certificate Compromise

Protecting Your Mac From the Certificate Compromise

Steps to revoke the trust from the Mac OS X keychain.

These instructions in PDF form for printing or download here

Download a package that will delete the DigiNotar Root CA certificates and will revoke the trust on the two root certificates and the four DigiNotar intermediate certificates. The package is now at version 2.1. Please use this version instead of versions 1.0 and 2.0. 

Update (11-Sep-2011 9:35 PM EDT): Apple has finally released an official fix for Snow Leopard (Mac OS X 10.6) and Lion (Mac OS X 10.7). If you are running Leopard (Mac OS X 10.5) on PPC machines, the version 2.1 package has been tested and works with Leopard. Still no sign of an update for iOS, unfortunately. 

You do not need to remove my package if you want to install Apple's package; there is no conflict. (Although I don't recommend installing my package after the Apple update -- there will be errors.) If you do want to remove it, delete the six DigiNotar certificates in the System keychain. 

It appears that GlobalSign's web server was compromised, but not their CA architecture. We don't need to worry about fraudulent certificates from GlobalSign. 

What Happened? 

On July 10, 2011, (a Netherlands CA) issued a fraudulent SSL certificate for the domain *, which would be valid for all domains. DigiNotar has not been forthcoming about how the attackers were able to obtain the fraudulent certificate, releasing only a PR statement without any content. This means that more fraudulent certificates may have already been issued or may be issued in the future for * or other domains. The latest news is that there have been over 500 fraudulent certificates issued. While current indications are that it was used to snoop on G-Mail communications in Iran, no one knows what other places it might be used and for what other purposes.  

Why Do We Care?

Furthermore, due to the nature of the certificates system, until the registrar is completely secured and how the attack was conducted becomes publicly available, every SSL protected website and service in the world is vulnerable. 

DigiNotar has been very tight-lipped about the problem. They have issued only one press release about the situation, and what’s in the press release does not correspond to other observable facts, such as the content of their Certificate Revocation List. Swa Frantzen at SANS and Jonathan Nightingale from Mozilla have both written excellent explanations of why DigiNotar’s response has been lacking. 

Because so many fraudulent certificates for so many high-value domains were issued (such as for, and there doesn’t seem to be a trustworthy list of the fraudulent certificates, there is a high risk that other sites may have been compromised and the end user would not be able to tell. The biggest risk to most users is identity theft by phishing of passwords. This could then lead to other compromises and eventually financial losses. 

In addition, users in Iran and other countries with totalitarian governments should also be concerned that their communications may have been compromised. 

What Counter-steps Have Been Taken?

Microsoft IE, Google Chrome, and Mozilla Firefox already have or have announced plans to very shortly blacklist all certificates. If you are running IE (any version) on Vista, Windows 7, Server 2008, or Server 2008 R2; or an up to date version of Firefox or Chrome, you'll be OK in the near future. This is pretty much a death penalty for the DigiNotar CA. 

Apple has not yet updated Mac OS X and Safari as of this writing or made any announcements about its plans.  In addition, there is a bug on Apple systems with the handling of Extended Validation certificates. If an EV certificate is traced back to an invalid (as opposed to non-existent) root certificate, it will be treated as valid. This is undoubtedly slowing Apple’s response. 

Technical Details

DigiNotar has two root certificates. 

“C=NL,O=DigiNotar,CN=DigiNotar Root CA”,
“C=NL,O=DigiNotar,CN=DigiNotar Root CA G2”

Only the first one is in Mac OS X’s System Roots by default, but either is present it needs to be deleted for protection. After that, both certificates need to be imported into the System keychain (whether they were in the System Roots or not), and marked as "Not Trusted". 

In addition, DigiNotar uses two intermediate certificates (that were signed by an Entrust root certificate) to sign downstream certificates. 

“C=NL,O=DigiNotar,CN=DigiNotar Root CA”
“C=NL,O=DigiNotar,CN=DigiNotar Services 1024 CA”

That’s right — they have two different certificates with the same name! One that is signed by Entrust, one that is their own root. These need to be imported into the System keychain and marked as "Not Trusted". 

Lastly, DigiNotar has two intermediate certificates from the Dutch government CA that they use to sign downstream certificates for government agency websites. 

“C=NL,O=DigiNotar B.V.,CN=DigiNotar PKIoverheid CA Overheid en Bedrijven”
“C=NL,O=DigiNotar B.V.,CN=DigiNotar PKIoverheid CA Organisatie - G2”

These, too, need to be imported into the System keychain and marked as "Not Trusted".   

Links to download these certificates in PEM format:

Corrective Actions That You Can Do On a Mac

Until Apple releases a security update for this issue, you can protect yourself on an individual Mac computer by doing the following two actions. 

First, delete the “DigiNotar Root CA” certificate (and the “DigiNotar Root CA G2” certificate if you have it) from your trusted roots, such as in the System Roots key chain. (The actual file is /System/LibraryKeychains/SystemRootCertificates.keychain.) Second, import both root certificates into the System keychain, and mark them as "Not Trusted". Third, import all four of the intermediate certificates into the System keychain, and mark them as “Not Trusted”. If you are on Snow Leopard or Lion, there is an Installer package on my website that will do these steps for you. If you are on Leopard or earlier, please follow the step-by-step instructions below. 

A Serious Problem

All of this will be in vain if a user just clicks through the “invalid certificate” warning dialog box and marks the certificate as valid in his or her own personal keychain. All too many users are just conditioned to do this by now. 

I don’t see a good way of handling this. I’m going to work on an application that can be used to sweep for known invalid certificates in the user’s keychain, but that’s going to take some serious effort. All we can do at this point is try to educate users. 

iOS Note: Unfortunately there is no equivalent process available for iOS at this point. You can add your own trusted CA certificates via the iPhone Config Utility and Configuration Profiles, but you cannot remove or modify the trust levels for pre-installed system certificates. 


This is a selection of informative links on the compromise of the DigiNotar CA. It is by no means complete, and is not intended to be. If you have a link that you think should be added to the list, please e-mail it to me. 

Tor Project blog page with latest update:

Ed Marczak’s page:

Swa Frantzen from SANS:

Jonathan Nightingale from Mozilla:

DigiNotar's certificates:

Step-By-Step Instructions 

If you have a 10.5 or earlier system, please use the package installer. These step-by-step instructions will work, but they will only apply some of the settings for the current user. They can be done once on each machine and apply to all users. 

Delete the DigiNotar Root CA certificate

1. Go to the /Applications/Utilities folder and open Keychain Access. 
2. 4-Search-for-Diginotar.pngStill inside Keychain Access, click in the search box in the upper right-hand corner of the window and type "Diginotar". 
3. 5-Select-All-Items.pngIf necessary, select the All Items category in the sidebar on the left. 
4. 10-Select-DigiNotar-Root-CA.pngSelect the certificate named "DigiNotar Root CA". 
5. 11-Delete.pngGo to the Edit menu and select Delete.
6. 8-Admin-Auth.pngEnter your admin authentication when the Authorization Services dialog box pops up. 
NOTE: The certificate may not disappear from the Keychain access window immediately. It is in fact deleted from the system, however. To refresh the view, re-type “diginotar” into the search field at the top of the window. 

Import and Revoke Trust on the Six Certificates

1. Download the six certificate files from the links above. 
2. Quit and re-launch the Keychain Access application. 
3. 12-Import-to-System-keychain.pngDouble-click on the first file. You will get a dialog box asking for which keychain the certificate should be the destination. Make sure that you select the System keychain as the destination from the pop-up menu. 
4. 8-Admin-Auth.pngEnter your admin authentication when the Authorization Services dialog box pops up. 
NOTE: The certificate may not appear in the Keychain access window immediately. It is in fact imported, however. To refresh the view, re-type “diginotar” into the search field at the top of the window as in the step below. 
5. 4-Search-for-Diginotar.pngStill inside Keychain Access, click in the search box in the upper right-hand corner of the window and search for "Diginotar". 
6. Double-click on the certificate that you just imported. 
7. 6-Open-Trust.pngClick on the turn-down triangle next to the label "Trust". 
8. 7-Choose-Never-Trust.pngChange the trust setting from “Use System Defaults” to “Never Trust”, then close the window. 
9. 8-Admin-Auth.pngYou may be asked for admin authorization to make the change. 
10. 9-Untrusted.pngOnce you de-select the certificate and then select it again, it will be shown as not trusted for all users. 
11. Repeat steps 2-10 for each of the other five certificate files. 
Document Actions

Intermediate certificates

Avatar Posted by McBart at Sep 03, 2011 11:08 AM

Can you publish the list of intermediate certificates. As I am very pleased with your effort of making a package to the work. I prefer to delete / invalidate these certificates myself.

Re: Intermediate certificates

Avatar Posted by Paul Suh at Sep 03, 2011 11:12 AM
I just updated the PDF version of this article. The intermediates are in the Appendix in PEM format. I will be posting them separately and updating the HTML page shortly.

Re: Intermediate certificates

Avatar Posted by Paul Suh at Sep 03, 2011 11:20 AM
Link to original source of the DigiNotar certificates:[…]/Default.aspx

Are there additional root or intermediate certificates to distrust?

Avatar Posted by Richard at Sep 07, 2011 08:45 AM
As of Sep 7, 2011, this article lists six DigiNotar certificates. The previously-mentioned page at the DigiNotar site lists many more certificates as downloads go. (In addition, there is a page at[…]/Default.aspx which is probably to do with "historical" certificates.) As such, would it please be possible to look into whether there are additional root or intermediate certificates that should be indicated as being distrusted?

At the Tor project site, there is a "list of CA roots that should probably never be trusted again":[…]/diginotar-damage-disclosure

The following bug report regarding the fix for the Firefox browser may also be of interest when it comes to possible additional certificates:

Re: Are there additional root or intermediate certificates to distrust?

Avatar Posted by Paul Suh at Sep 07, 2011 08:59 AM
As far as I can analyze it, there are only the six certificates that need to be un-trusted. The two stand-alone roots, the two intermediates that trace back to Entrust, and the two intermediates that trace back to Staadt der Nederlands roots. All of the others trace back to one of these six somewhere along the way, and any Extended Validation certificates only trace back to one of the stand-alone roots.

Thanks for the links -- I've been tracking those as well.

Installer Link

Avatar Posted by Michael at Sep 03, 2011 08:28 PM
I'm trying to download the package above, but what actually downloads is a pdf file named
michael$ file PDF document, version 1.3

I'm using Firefox to download it.


Installer Link

Avatar Posted by Paul Suh at Sep 03, 2011 08:28 PM
Thanks. Fixed. Moral of the story -- don't upload files when you're exhausted.

visiting diginotar

Avatar Posted by Richard B at Sep 06, 2011 11:08 PM
A person at claims visiting the https site of diginotar gives a warning -- does this mean Apple came out with a quiet fix for the iPad / iPhone?

Re: visiting diginotar

Avatar Posted by Paul Suh at Sep 06, 2011 11:11 PM
There is a warning, but it has nothing to do with a fix. uses the certificate for, and that generates a domain name mis-match warning.

iOS devices?

Avatar Posted by Kurt L at Sep 07, 2011 02:24 PM
Is there any way to secure an iOS device from this problem? Or do we just have to wait for an update from Apple?

Re: iOS devices?

Avatar Posted by Paul Suh at Sep 07, 2011 02:28 PM
Unfortunately, there's nothing that we can do without an update from Apple. iOS has many fewer configurable settings than MacOS.

Also, this is a good time to remind folks that layered security matters. If you use encrypted authentication even inside your SSL-protected connections, you will be much less vulnerable than if you use cleartext authentication. For instance, use CRAM-MD5 instead of PLAIN or LOGIN for IMAP connections; or WebDAV-Digest instead of Basic for HTTP Realms.

No need to panic

Avatar Posted by John at Sep 07, 2011 09:22 PM
Neither Mac OS X or iOS are vulnerable to being duped by any fraudulently created SSL certificates. Apple use have very quickly (albeit very quietly) updated its security when this news broke out. How to prove this? Just go to you should see that Safari does not go to the page automatically and instead it puts up an notice asking you what to do (i.e. the Diginotar cert is not accepted), so don't panic, test it first. If for some reason you have, or had, purposefully or unintentionally manually added the Diginotar cert, then follow the instructions on this site to remove it and to distrust it.

If for any reason you feel the need to get inside your iPhone and mess with its internals, then Apple provides a way to do this via:
iPhone Configuration Utility for Mac OS X

Re: No need to panic

Avatar Posted by Paul Suh at Sep 07, 2011 09:28 PM
This is ABSOLUTELY NOT the case. There has been no security update to iOS that I am aware of as of this writing (2011-Sep-07 9:27 PM EDT). The reason there is a warning raised is that the site "" uses a certificate with the Subject identifier of "C=NL, O=DigiNotar B.V. (0034104947), OU=IT/serialNumber=00000003341049470000,". Since the CN attribute does not match the DNS name "" from the browser, and there is no Subject Alternative Name attribute that matches "", Safari correctly raises a warning. If you go to "", you will not get any kind of warning.

iPhone Configuration Utility

Avatar Posted by Marcel at Sep 08, 2011 02:56 PM
With the iPhone Configuration Utility you can add own certificates but (as far as I know you) can't distrust or delete certificates which are inside the iPhone/iPod/iPad by default, only Apple can handle this with a security-update. Also with a jailbreaked device this time I don't know a way because the security-command is not available in iOS (which you can use on Mac OS X if you like to untrust and delete certificates).

"not trusted" for all users vs. "not trusted" for active user

Avatar Posted by Marcel at Sep 08, 2011 02:57 PM

first thanks for all the detailed information here, great. :)

I've tested your step-by-step instructions yesterday on a PowerMac G5 with Mac OS X 10.5.8 Leopard.

1. Only two of the certificates (the "brown" ones, named "DigiNotar Root CA" and "DigiNotar Root CA G2") were "marked as not trusted for ALL users" and left in the System-Keychain.

2. The other four certificates (the "blue" ones, named "DigiNotar Services 1024 CA", "DigiNotar Root CA", "DigiNotar PKIoverheid CA Overheid en Bedrijven" and "DigiNotar PKIoverheid CA Organisatie - G2") not only left in the System-Keychain but also automatically copied into the Login-Keychain and were "marked as not trusted for the ACTIVE LOGGED IN user" only! (Because I use a german system I can't tell you the original english trust information here right now, sorry).

3. So I had to logout my "Administrator"-Account and login also with my personal "Marcel"-Account (a managed user account for my daily work WITHOUT administrative privileges). Here I had to start the Keychain Access and mark the four "blue" certificates as "not trusted" because otherwise they would stay as "trusted"! So you are warned now.

I don't know if this is a special situation on my 10.5 PPC Leopard system, this evening I will test this again on 10.6.8 with my MacBook (and there I use the american language as default and not the german, so I can hopefully better explain here) … ;)


Aware of issues with Lion & Leo

Avatar Posted by Paul Suh at Sep 08, 2011 03:04 PM
I'm aware of issues with Leo and Lion. Working on it but I'm traveling today so progress is slow.


Thanks Paul

Avatar Posted by Larry G at Sep 10, 2011 08:59 AM
Thanks for your efforts on this problem Paul. I first learned of this problem on Friday when Apple issued an update fix. I downloaded the Apple fix but haven't yet restarted my MacBook laptop with Mac OS X v10.6.8 to apply the fix. In the meantime I followed your instructions to manually never trust Diginotar. Hi Marcel. It's nice to see you posting from Germany I assume. I'm in the USA.

A root certificate already in the System Roots keychain

Avatar Posted by Richard at Sep 10, 2011 08:59 AM
From what one can tell, on a 10.5.8 installation, there is a "DigiNotar Root CA" certificate in the "System Roots" keychain (which is not the same thing as the "System" keychain.) For a certificate that is in the System Roots keychain, would it be sufficient to simply set such a certificate to "never trust" without removing the certificate? (It appears that the user cannot add certificates to the "System Roots" keychain, so removing one from this keychain might be difficult to reverse. On the other hand, it appears that the user can add certificates to the "System" keychain, and this keychain may be available to all users.)

Re: A root certificate already in the System Roots keychain

Avatar Posted by Paul Suh at Sep 10, 2011 09:03 AM
No, the "DigiNotar Root CA" in the System Roots keychain must be removed. If not, it triggers the bug where EV certificates are accepted even though they are not trusted. Then, the same root certificate needs to be added to the System keychain and marked as "Not Trusted" so that all other certificates coming from that root are cut off. Otherwise, the default trust settings for that root are still in effect (even though it's not in the System Roots), so when it is presented as part of a chain from the server the leaf certificate is still validated.

Avatar Posted by worksafe at Sep 08, 2011 02:57 PM
Downloaded and expanded the zip file. Tried to install it with and with out Keychain open. Both times got a Failed message on Lion.


Avatar Posted by MD at Sep 08, 2011 02:58 PM
Great initiative! So thanks for your effort to make the world a little safer again.

Outstanding work!

Avatar Posted by Pete at Sep 09, 2011 07:28 AM
First, thanks for all your hard work on this, really truly outstanding. Thanks!

Assuming there may be folks out there who have blown through the warnings, is there any way to determine if a user has been impacted? If users of Google Apps/Gmail etc were to change their passwords and run your DigiNotar clean up app can they reasonably assume they've reduced some of their exposure risk?

Apple released Security Update 2011-005

Avatar Posted by ivmodo at Sep 09, 2011 05:52 PM
Apple released a security update earlier today. seemingly suggests the EV defect is at least addressed for DigiNotar, although it does sound like an "EV exception for DigiNotar" instead of addressing the EV handling itself - I could be wrong...

DigiNotar on my Mac G5 w/Leopard

Avatar Posted by Dan D. at Mar 02, 2013 09:05 PM
I think I've done the above procedure correctly. I am now left with no DigiNotar anything in System Roots, but still have five DigiNotar certificates in my System keychain - all with a Never Trust designation. Is this where I should be? Thanks, and thank you for posting this fix.

Diginotar certificates on the login keychain vs. system keychain

Avatar Posted by 102512 commenter at Mar 02, 2013 09:06 PM
When complete should there be any not trusted DigiNotar certificates on the LOGIN keychain or should there only be 6 SYSTEM DigiNotar not trusted certificates anywhere on the keychain, for all user accounts?

Further, when the 6 DigiNotar certificates are imported for one user account on a computer are they accessible for all user accounts on the computer or must they be imported again for each user account?

Add comment

You can add a comment by filling out the form below. Plain text formatting.

Please enter your name.