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.
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
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.
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.
The main admin user on my 10.9 VM is also part of both those groups, so I guess it's normal.
Tests-Mac:~ test$ id
uid=501(test) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),401(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),398(com.apple.access_screensharing),399(com.apple.access_ssh)
Membership in the com.apple.access_screensharing group seems to correspond to the user (or a group it's a member of) being included in this list:
When I created a new standard account, it was not a member of the com.apple.access_screensharing group by default, but after I added the account to the list above, it became a member of the group.
Similarly, membership in the com.apple.access_ssh group seems to correspond to the user being included in the list in the Remote Login section.
Best Answer
Basically certificates are used so that you can say "I got this information from an otherwise untrusted source, but because it has this associated certificate, I'm going to put some trust in it". This is possible because "someone" has done some sort of vetting of these sources.
In practice, a lot of times this means for example a company wanting to open a web shop goes to a certificate vendor (such as GoDaddy you mentioned) and buys a certificate. The certificate vendor will then do some kind of checking before they issue the certificate.
Depending on the type of certificate it might be that they check that the company controls the domain of their web site (such as my-web-shop.com), that they control e-mail addresses (such as postmaster@my-web-shop.com) - or even checking company registration papers, ensuring that the postal address is correct, etc.
This makes it possible for ordinary users to visit a web site and be somewhat sure that the data they received comes from the intended source.
You might notice that something is missing here - how are the vetters vetted?
This is done by operating system and browser vendors such as Microsoft, Apple, Google, Mozilla, etc. They basically keep a list of certificate vendors that their software will trust by default.
Apple will for example make changes to that list when you update macOS to ensure that it keeps being valid. In addition, you yourself can make your own decisions on adding or removing vendors from the list by changing the trust levels.
Whether it is "safe" or not to remove the trust is a matter of your preference. If you remove the trust of a specific vendor, you will be prompted when accessing web sites that bought certificates from that vendor - stating that the site is not secure. You can usually override that on a site per site basis, but not always.
Note: When I say "bought from a vendor" it doesn't necessarily mean that money was exchanged. Some certificate issuers do not charge (such as Let's Encrypt) and some service providers provide certificates for free with other services.