How to get rid of DigiNotar digital certificates from OS X (Updated)

Update 2: After a conversation with Seth Bromberger we have some new details. First, the reason you're unable to replicate this issue is that DigiNotar appears to have re-issued certificates. You can see Seth's screencast showing the issue here (you may need to go fullscreen to see the text). Further, DigiNotar appears to have chained their certificates to the Dutch government, we're not sure why.
But there's a larger problem here, and that involves how Keychain and Safari work to try and protect you from unsafe sites -- those signed by bad authorities. Essentially, the way this works in every other browser is that, if you take any certificate in Keychain and say "Never Trust" you will get a warning when visiting a site signed with that CA. In Safari, this doesn't happen. Instead, you must delete the certificate entirely. We're not sure why this is so, but Apple has apparently known about this for a while and done nothing to change what would seem like an obvious method for protecting users.
We're working on this story, stay tuned for a separate post. - Victor
After DigiNotar's servers were hacked last month and began issuing false digital certificates, some Mac users claimed they were finding that despite changing their security settings that sites from DigiNotar were still seen as trusted.
IDG News Service (via Computerworld) cited Seth Bromberger, who said after he removed revoked DigiNotar certificates from Keychain that he was still able to access material that should have been marked as untrusted. In other words, setting the certificates to "Never Trust" seemingly had no effect from Safari's viewpoint.
However, before panicking about unsafe digital certificates, the folks over at io101.org posted a how-to on getting the DigiNotar certificates off your Mac.
Update 3: According to Mr. Bromberger (who is actually a security specialist) now that DigiNotar has re-issued their certificates, the link Megan has below will not work as intended. As he says,
" this may have worked before DigiNotar reissued their certs, but now, that link WILL give you the warning she mentions regardless of whether you've deleted the certs or not. This will lead unsuspecting users to conclude that they've successfully mitigated the problem, when they haven't.
The reason this happens is because the link in the post gives you a different warning - it's a hostname mismatch as opposed to a "certificate not found/trusted" (or whatever the actual warning is). Only if you click "View certificate" will you see the difference."
First, test to see if your browser has DigiNotar SSL access by clicking this link. If there are no DigiNotar certificates on your Mac, you will get the following:

However, if you don't get a warning, then do the following:
- Open Keychain Access
- Search for DigiNotar

- Delete the certificate entirely or double-click to bring up options and change the trust setting to "Never Trust"
- Restart Safari
- Check the above link again to see if the certificate was blocked.
So, what about Bromberger's concerns? I replicated the steps above by first deleting the DigiNotar certificate entirely, then distrusting it. Both times, I received warnings from Safari that I was accessing an insecure site.

However, the key here is to restart Safari once the certificate changes are made. When I made the fixes without restarting Safari, I was still granted access to the site.
If you're able to replicate Bromberger's issues, we're interested in hearing from you in the comments.
Update: Rachel's provided a couple other test links for the certificate, which io101 did as well. Thanks, Rachel!
Share
Categories
Update 2: After a conversation with Seth Bromberger we have some new details. First, the reason you're unable to replicate this issue...
Hi all, as the (most recent) discoverer of this bug, let me offer a few additional details:
The flaw is in the way OSX handles Extended Validation certs - that is, it appears that if an EV cert is anywhere in the certificate chain, OSX will only check to see whether there are valid signatures - it will not check the inherited trust. This means that any EV cert that chains to any root certificate on which you've modified the trust settings will not reflect your intended trust settings.
As someone mentioned, the URL I used to test (https://www.diginotar.nl/Portals/7/EVSSL1.gif) is now being chained to a different root CA. You can see the results of my testing, though, here: http://dl.dropbox.com/u/30348/sr4.2.mov .
Add a Comment
Ryan Sleevi, the researcher who confirmed the bug in Apple's source code, points to the following web page and indicates that these steps worked for him: http://ps-enable.com/articles/diginotar-revoke-trust. I haven't tried it myself but trust Ryan's assessment. Note that deleting the certificates via Keychain does not confer adequate protection. From Ryan:
"Simply /deleting/ the certificate actually does nothing for
malicious attacks - a server (or MITM agent) can be easily configured
to include an additional certificate, which will then cause the
original Apple-supplied "I trust this root for everything" to come
into play. By deleting the certificate, however, it actually triggers
the code to no longer think that an EV certificate is at play, which
means after it has built the chain, it /will/ evaluate trust settings.
So by interjecting an admin Deny setting (which has a higher priority
than the System Trust setting), it works."
sudo security delete-certificate -Z C060ED44CBD881BD0EF86C0BA287DDCF8167478C /System/Library/Keychains/SystemRootCertificates.keychain
For those of you Terminal-ly inclined.
I updated to Firefox 6.0.1. Do I need to do anything else?
September 02 2011 at 8:31 AM Report abuse Permalink rate up rate down ReplyI'm confused about these instructions in this article. I get the certificate message with the first link provided in the article and Safari won't connect to the second link with an error page. But I checked my keychain and I DO have 1 DigiNotar certificate and 3 DigiCert all certified as valid.
Keychain: System Roots
1) DigiNotar Root CA - expires mar 31, 2025 ...
2) DigiCert High Assurance EV Root CA - expires nov 9, 2031 ...
3) DigiCert Global Root CA - expires nov 9, 2031 ...
4) DigiCert Assured ID Root CA - expires nov 9, 2031 ...
Do I STILL need to change anything or whatever or am I fine? Is DigiCert related to DigiNotar?
@cowicide:
Safest thing to do is to delete the DigiNotar (NOT the DigiCert; it's a different company entirely) certificate from your keychain. Highlight it from the search results, then right-click and choose "Delete".
Hi all, as the (most recent) discoverer of this bug, let me offer a few additional details:
The flaw is in the way OSX handles Extended Validation certs - that is, it appears that if an EV cert is anywhere in the certificate chain, OSX will only check to see whether there are valid signatures - it will not check the inherited trust. This means that any EV cert that chains to any root certificate on which you've modified the trust settings will not reflect your intended trust settings.
As someone mentioned, the URL I used to test (https://www.diginotar.nl/Portals/7/EVSSL1.gif) is now being chained to a different root CA. You can see the results of my testing, though, here: http://dl.dropbox.com/u/30348/sr4.2.mov .
Sorry Rachel, but https://service.diginotar.nl/files/DigiNotar%20Root%20CA.crt just came up as a 404.
Furthermore, using the http or https links threw the errror, EVEN THOUGH I had a 'valid' Diginotar cert in my Keychain dated from March of these year expiring in 2025.
FWIW, I think users should just zap the DigiNotar cert and be done with it.
First off, you link to https://diginotar.com/ which doesn't work, as the certificate is for https://www.diginotar.com/ -- the link on this page is guaranteed to fail, even if you do still trust the Diginotar root CA.
HOWEVER, they're no longer even using their own root certificate to sign their website's https anyway; they're now signed by the Staat de Nederlanden Root CA, which is a separate (and still valid, non-hacked) CA which signed Diginotar's new second-level certificate. So if you correct the hostname and go to https://www.diginotar.com/ you'll have no issue (though they currently redirect you to the non-SSL version of the site once you connect), even if you distrust the old root certificate.
To test whether you've revoked the original certificate properly, use the https://service.diginotar.nl/files/DigiNotar%20Root%20CA.crt URL instead of the test link above. If you've killed the original Diginotar root CA, that will pop up a warning to that effect, about the service.diginotar.nl site not being properly signed. This should work as a test for now. A quick check shows that io101 noticed this as well and updated their original post.
Hope that helps. :)
Hot Apps on TUAW
Deals of the Day
more deals- Used Apple iPhone 3G 8GB for AT&T for $108 + $5 s&h
- Apple Mac Pro Xeon 6-Core 3.3GHz Desktop w/ 12GB RAM for $3,899 + $28 s&h
- Apple MacBook Pro Core i7 Quad 2.2GHz 15" SSD Laptop for $2,447 + $13 s&h
- Apple Earphones with Remote and Mic for $6 + $2 s&h
- PC Micro Store sale: Up to 50 off
- USB MP3 Player FM Transmitter with remote for $6 + free shipping
Software Updates
more updates- EFI Firmware Update brings Lion Internet Recovery to 2010-model Macs
- OS X Lion 10.7.3 released with Safari 5.1.3, Wi-Fi bug fix
- Aperture updated to 3.2.2, addresses Photo Stream issue
- Apple updates Keynote to address Lion issues
- Google Search app gets new look on iPad
- Apple releases Apple TV Software Update 4.4.3



Featured Comments