8

Certificates issued by DigiNotar have been blacklisted today by Mozilla. Viewing websites with certificates issued by DigiNotar with a nightly build of Firefox will render warnings.

Instead of waiting for an update, for the certificates to be revoked on my own system, I removed the root certificates from my Keychain but Chrome still validates the website certificates and Safari isn't throwing any warnings.

Am i missing something?

Certificates removed:

  • DigiNotar Root CA
  • Staat der Nederlanden Root CA
  • Staat der Nederlanden Root CA - G2

Website tested: https://as.digid.nl/

Here's an alternate test site that shows the problem in Chrome 13.0.782.218: http://auth.pass.nl

I have deleted the DigiNotar root CA from my Keychain. Chrome has been restarted. But Chrome still says this site is valid and lists the DigiNotar root CA as the authority on the SSL for the site.

DigiNotar Root CA Trusted

Improve this question
4
  • same here. even opera. i guess rogue certs are so rare all the major browsers have buggy revocation handlers.
    – hsmiths
    Aug 31, 2011 at 2:36
  • Same problem here. I found this article from Mozilla that details manual removal: support.mozilla.com/en-US/kb/deleting-diginotar-ca-cert I imagine deleting from the keychain is essentially the same thing. Strange indeed.
    – user10355
    Aug 31, 2011 at 4:02
  • 1
    When I set the Staat der Nederlanden Root CA to untrusted I get the warning from Chrome that the site isn't using a trusted cert. I've already deleted the DigiNotar root CA.
    – Ian C.
    Aug 31, 2011 at 13:05
  • When setting the certificate to "Never Trust" i get the expected result from both Safari as Chrome. They both throws a warning.
    – Lars Wiegman
    Aug 31, 2011 at 21:11

5 Answers 5

Reset to default
4

Every site I check that I have manually set as untrusted shows a warning. Perhaps things are changing on the servers so rapidly, different people doing the same actions are seeing different results.

Let's set aside the concept of blacklisting in general and certificate revocation like (CRL) or online verification like OCSP and just pick apart the mechanism of SSL certificates in the browser. I will set aside Chrome/Firefox/other browsers and just focus on Safari and the Mac Keychain as that's trouble enough for this post.

The short answer is the site you list doesn't depend on the one certificate that was used in a way that has caused the press to run all the blacklist stories.

It was used to sign certificates that matched anything ending in google.com and they were spotted in use on sites that were certainly not google. This is a technological equivalent to someone constructing tunnels into a bank vault. Not plans to tunnel - but a working actual tunnel around a barrier everyone expected to be solid.

Now onto how to know why Safari didn't flag the site you listed as "bad".

I haven't deleted any certificates from the mac I'm on and just fired up the Keychain Assistant to use the Certificate Assistant (under the Keychain Access menu -> Certification Assistant -> Open...

In the small CA window, select continue, then View and Evaluate, then View and evaluate certificates, then continue.

enter image description here

As you can now see, https://as.digid.nl/ is serving up four certificates in the chain of trust:

  • cert name - type - SHA1 fingerprint - status
  • as.digid.nl - SSL - 2D F7 4E 54 00 90 80 08 01 0A 2F 3E 5A EE BE 36 5F EC 82 F3 - invalid due to host name mismatch (harmless error - the tool evaluates that cert for your mac and my mac isn't as.digid.nl)
  • DigiNotar PKIoverheid CA Overheid en Bedrijven - intermediate - 40 AA 38 73 1B D1 89 F9 CD B5 B9 DC 35 E2 13 6F 38 77 7A F4 - valid
  • Staat der Nederlanden Overheid CA - intermediate - 29 FC 35 D4 CD 2F 71 7C B7 32 7F 82 2A 56 0C C4 D2 E4 43 7C - valid
  • Staat der Nederlanden Root CA - root - 10 1D FA 3F D5 0B CB BB 9B B5 60 0C 19 55 A4 1A F4 73 3A 04 - valid

enter image description here

In your question you stated you deleted the root key - if so, your safari is either cacheing the old values or when you looked, that site had a SSL certificate different than the one I saw making this answer. You'll have to reproduce the steps I just took to see which was the case.

In my case, I only had to mark the Staat der Nederlanden Root CA root certificate as untrusted to get Safari to balk and show this message when you load the site.

enter image description here

enter image description here

Since all the press is specific about only the DigiNotar Root CA as being bad, I am going to undo my change to not trust the Staat der Nederlanden Root CA.

I am going to mark the DigiNotar Root CA as never to be trusted and wait and see what Apple does. If you are interested in this sort of thing, do monitor the Apple Security page.

Improve this answer
8
  • 2
    But the “Staat der Nederlanden Root CA” certificate isn’t untrusted (as far as I know). Merely the DigiNotar CA certificate should be revoked/deleted and that doesn’t work.
    – Konrad Rudolph
    Aug 31, 2011 at 10:46
  • I avoided the whole social aspect since the question was simply why chrome and safari were not throwing an error. Perhaps I should address that in my answer more clearly...
    – bmike ♦
    Aug 31, 2011 at 13:49
  • See my update to the OP: I can show you a site that does depend on the DigiNotar root CA that Chrome will happily display even though I've deleted their root CA from my Keychain.
    – Ian C.
    Aug 31, 2011 at 16:20
  • Awesome @Ian-C - I've been looking for a straw man to test. It's clear that chrome is not using the system keychain but instead it's own store. Safari correctly flags auth.pass.nl when the DigiNotar Root CA is untrusted or deleted. Thank you for that link!
    – bmike ♦
    Aug 31, 2011 at 16:29
  • Weird. Something screwy is up. Since posting that updated site both Chrome and Safari on my system have started flagging it. But while I was making that post neither of them were flagging it. It appears there's some delay in the propagation of Keychain info in to Chrome and Safari maybe? My Chrome version didn't change in that time frame. Freaky.
    – Ian C.
    Aug 31, 2011 at 16:35
2

It seems this is a serious bug in OS X.

Users can revoke a certificate using Keychain, but if they happen to visit a site that uses the more-secure Extended Validation Certificates, the Mac will accept the EV certificate even if it's been issued by a certificate authority marked as untrusted in Keychain.

Source: http://www.computerworld.com

Improve this answer
1

The website doesn’t use the DigiNotar CA Root certificate. The root certificate in the case of as.digid.nl is from the “Staat der Nederlanden root CA” – which is safe (presumably). True, there is a DigiNotar certificate in the website’s chain of certificates but this is not the root certificate – it is merely a link in the chain, and is a different certificate.

Improve this answer
1
  • True, but because the “Staat der Nederlanden root CA" was issued by the same company, DigiNotar, I decided to revoke it as well.
    – Lars Wiegman
    Aug 31, 2011 at 21:00
0

It's possible that the certs you are seeing are signed by multiple CAs (or intermediate CA certs are signed by multiple entities). You would have to identify and remove all the signing CAs involved.

Improve this answer
1
  • Revoking trust on one root cert worked for me in Safari. In this case, the intermediate certs are not stored in my keychain. Staat der Nederlanden Root CA SHA1 fingerprint of 10 1D FA 3F D5 0B CB BB 9B B5 60 0C 19 55 A4 1A F4 73 3A 04
    – bmike ♦
    Aug 31, 2011 at 4:55
0

As far as I know, some browsers (like Firefox) are not using the certificates in your keychain. Chrome is based on Webkit, so I assume it does use the keychain.

Restarting Safari was not necessary for me; marking the root cert as "untrusted" and reloading the page was sufficient.

Not that you can only mark the root (Staat der Nederlanden Root CA) as untrusted; the other certs are not in your keychain, but rather transmitted from the host every time you start an SSL session.

Could you post a screenshot of the certifcate window when you load as.digid.nl ? Maybe that can shed some light on the issue...

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .