Certificate Authorities are backbone of Trust system we use for "secure" online access. To see that "lock" icon in the browser when we visit a site with an SSL certificate, and even a green bar if the site has an Extended Validation SSL (EV SSL), may give us a sense of security, which unfortunately proving to be a "false sense of security" these days.
There are plenty of articles out there on what happened (even a Wiki), how it happened, who got involved and what Microsoft, Google, Mozilla, etc are doing to contain damage, even a Wiki about it but also what you should be aware of. Here is one from Windows Secrets that explains it in laymen terms. I personally liked the detailed account from Firefox folks.
If you are reading this blog, you are probably interested in an easier way to find whether you have a cert or not and PowerShell can come to the rescue:
PS C:\Users\Adil> gci certificate::LocalMachine\Root |?{$_.subject -match "DigiNotar"}
I do not have it on my machine, so I won't go further but you if you search only "Digi", you will see some results:
PS C:\Users\Adil> gci certificate::LocalMachine\Root |?{$_.subject -match "Digi"}
Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root
Thumbprint Subject
---------- -------
5557C0953FBD9F93745B214FB2483E9369B597F0 CN=DT Soft Ltd, OU=Digital ID Class 3 - Microsoft S
5FB7EE0633E259DBAD0C4C9AE6D38F1A61C7DC25 CN=DigiCert High Assurance EV Root CA, OU=www.digic
3E2BF7F2031B96F38CE6C4D8A85D3E2D58476A0F CN=StartCom Certification Authority, OU=Secure Digi
0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 CN=DigiCert Assured ID Root CA, OU=www.digicert.com
Unfortunately, Safari / OS X does not have a mechanism to detect Revoke Lists (RL) but Apple should be releasing an update soon to fix the chain. In the mean time you can open up 'Keychain Access' tool and remove the DigiNotarRoot Certificate from GUI but where is the fun in that?
If you double click the certificate, you get detailed information as shown below.
And what if you had to do this on multiple Macs in an enterprise environment? You would want to use command line to do it. The command for all certificate related work is named 'security'.
You can dump a pretty list of all Root CAs in OS X using 'dump-keychain' parameter of 'security' command, which, as we mentioned above, is used to manipulate Keychains from command line.
If we only wanted to display the Friendly names of certificates, which would be equivalent of what we see in 'Keychain Access' GUI, we can filter by 'labl'
adil$ security dump-keychain "/System/Library/Keychains/SystemRootCertificates.keychain" |grep labl "labl"<blob>="Prefectural Association For JPKI" "labl"<blob>="Entrust.net Certification Authority (2048)" "labl"<blob>="A-Trust-Qual-01" "labl"<blob>="A-Trust-Qual-02" "labl"<blob>="A-Trust-nQual-01" "labl"<blob>="A-Trust-nQual-03" "labl"<blob>="AOL Time Warner Root Certification Authority 1" "labl"<blob>="AOL Time Warner Root Certification Authority 2" ...
We can filter the results that start with 'D' and while at it, beautify it by getting rid of '=' and everything before it:
adil$ security dump-keychain "/System/Library/Keychains/SystemRootCertificates.keychain" |grep labl |awk -F '=' '{print $2}' |grep ^\"D
"DST Root CA X4"
"Deutsche Telekom Root CA 2"
"DigiCert Assured ID Root CA"
"DigiCert Global Root CA"
"DigiCert High Assurance EV Root CA"
"DigiNotar Root CA"
"DoD CLASS 3 Root CA"
"DoD Root CA 2"
"DST Root CA X3"
"DST ACES CA X6"
We can use also use find-certificate parameter to find the certificate and print all info. (-a for all keychains, not actually necessary here as we know this is a Root Certificate but good to be safe. If you happen to know the e-mail you could also use -e parameter)
adil$ security find-certificate -a -c "DigiNotar"/System/Library/Keychains/SystemRootCertificates.keychain keychain: "/System/Library/Keychains/SystemRootCertificates.keychain" class: 0x80001000 attributes: "alis"<blob>="info@diginotar.nl" "cenc"<uint32>=0x00000003 "ctyp"<uint32>=0x00000001 "hpky"<blob>=0x8868BFE08E35C43B386B62F7283B8481C80CD74D "\210h\277\340\2165\304;8kb\367(;\204\201\310\014\327M" "issu"<blob>=0x305F310B3009060355040613024E4C31123010060355040A1309444947494E4F544152311A301806035504031311444947494E4F54415220524F4F542043413120301E06092A864886F70D0109011611696E666F40646967696E6F7461722E6E6C "0_1\0130\011\006\003U\004\006\023\002NL1\0220\020\006\003U\004\012\023\011DIGINOTAR1\0320\030\006\003U\004\003\023\021DIGINOTAR ROOT CA1 0\036\006\011*\206H\206\367\015\001\011\001\026\021info@diginotar.nl" "labl"<blob>="DigiNotar Root CA" "skid"<blob>=0x8868BFE08E35C43B386B62F7283B8481C80CD74D "\210h\277\340\2165\304;8kb\367(;\204\201\310\014\327M" "snbr"<blob>=0x0C76DA9C910C4E2C9EFE15D058933C4C "\014v\332\234\221\014N,\236\376\025\320X\223<L" "subj"<blob>=0x305F310B3009060355040613024E4C31123010060355040A1309444947494E4F544152311A301806035504031311444947494E4F54415220524F4F542043413120301E06092A864886F70D0109011611696E666F40646967696E6F7461722E6E6C "0_1\0130\011\006\003U\004\006\023\002NL1\0220\020\006\003U\004\012\023\011DIGINOTAR1\0320\030\006\003U\004\003\023\021DIGINOTAR ROOT CA1 0\036\006\011*\206H\206\367\015\001\011\001\026\021info@diginotar.nl"
Well, enough playing. To delete the certificate, we will use 'delete-certificate' command. We have two choices:
1) Use -c parameter which is using 'common name'
2) Use SHA-1 fingerprint (safer).
Let's do both.
1) We need to use common name. This is the name you see in the GUI and we seem to get it from 'labl' line above. Command becomes
adil$ sudo security delete-certificate -c "DigiNotar Root CA" /System/Library/Keychains/SystemRootCertificates.keychain
2) As mentioned above, using SHA-1 fingerprint is less error-prone than relying on common names. To do that, we have to first locate the fingerprint. Noticed that it was not showing above when we displayed the certificate?
OK, so how do we get the fingerprint? Simple: we add -Z to the 'find-certificate' command which returns SHA-1 in the first line and then prints what we have seen above. So we will simply 'grep' the fingerprint:
adil$ security find-certificate -a -c "DigiNotar" -Z /System/Library/Keychains/SystemRootCertificates.keychain |grep SHA-1 SHA-1 hash: C060ED44CBD881BD0EF86C0BA287DDCF8167478C
And now we can get rid of the certificate:
adil$ sudo security delete-certificate -Z C060ED44CBD881BD0EF86C0BA287DDCF8167478C /System/Library/Keychains/SystemRootCertificates.keychain
Well that's all. Now, all you would need is to put these two lines in a shell script (find fingerprint if certificate exists & delete it), then run it against all your Macs.
Note that in general Safari and Chrome honor system-wide certificates, however, some versions of Firefox is not using the Keychain to store/retrieve certificates. It has its own database and you might need to manipulate that as well. Also note that browsers have their own list of trusted CAs so updating Chrome and Firefox would solve the problem as of today.
Update: There are several articles about why revoking this certificate may not be enough because of the way EV SSL treated in Safari. If you delete the certificate, this should not be a concern. However, there seems to be additional certificates that needs to be revoked to be safer.
In any case, I visited DigiNotar web site on Safari and found a page with "Order" button that takes you to another page with SSL. As soon as I clicked the "Order" link, Safari warned me that the certificate on the site was invalid (expired).
As far as I can tell chain goes like this:
DigiNotar Root CA -> DigiNotar Services 1024 CA -> *.diginotar.nl
So this seems to be good sign. I tried some other sites but I am yet to find a site that was issued and SSL from the the Root CA I deleted.
Update2: I saw https://www.maestre.com mentioned as a test site here. This is what I got on Safari:
It's good that I am getting a notification. Unfortunately, it is not because DigiNotar Root CA is missing from my Root keychain but because certificate has expired.
Update3: Apple today released a security patch to put the issue at rest. In their terms, here is what they did:
Description: Fraudulent certificates were issued by multiple certificate authorities operated by DigiNotar. This issue is addressed by removing DigiNotar from the list of trusted root certificates, from the list of Extended Validation (EV) certificate authorities, and by configuring default system trust settings so that DigiNotar's certificates, including those issued by other authorities, are not trusted.
Of course, they would not tell exactly what they did. I had a pretty good idea which file they were talking about. Let's look at the last one "configuring default system trust settings":
adil$ pwd
/System/Library/Keychains
adil$ ls -l
total 1048
-rw-r--r-- 1 root wheel 5353 Sep 9 17:53 EVRoots.plist
-rw-r--r-- 1 root wheel 167848 Jul 9 23:39 SystemCACertificates.keychain
-rw-r--r-- 1 root wheel 395312 Sep 9 17:53 SystemRootCertificates.keychain
-rw-r--r-- 1 root wheel 86380 Sep 9 17:53 SystemTrustSettings.plist
-rw-r--r-- 1 root wheel 282984 Jul 28 2008 X509Anchors
The bottom is the original, and above you see the updated file. Basically they updated the date and added a new array with a dictionary which set kSecTrustSettingsResult to 3.
Notice that I am looking at the Key that starts with C060E... which is the SHA-1 fingerprint we got above.
Also notice that IssuerName, we know that's DigiNotar. As noted in some of the links above, there were several certs by DigiNotar published by others. I can tell from the diff which are the ones that were affected but I cannot tell a way of figuring them out only by looking at the original as Issuer Names would be different and don't have a list of chains where DigiNotar exists.
No comments:
Post a Comment