The recent events at Diginotar turned my attention again to the way Apple handles certificates in MacOS X. Apple makes use of certificates not only in the browser for the standard SSL/TLS support, but it is also an integral part of the security system of Mac OS X. Both the App store and the application firewall make use of certificates:

• All applications in the App store must be signed by the developer.
• The application firewall whitelists uses the certificate of an application to maintain the whitelist over different releases of the software.
• The application firewall whitelists Apple’s software based on the signature with the Apple certificate.

So far, things look good. However, when I tested what happens with the websites that use a diginotar PKIOverheid certificate I noticed that they were still accepted even though the Dutch Government revoked the intermediate certificate and updated OCSP to reflect that.

A quick look at the keychain preferences showed me that OCSP (Online Certificate Status Protocol) and CRL (Certificate Revocation List) were both disabled.  I changed both settings to ‘Required when certificate indicate’ and Safari started to behave like I expected. (I know there is a different solution as outlined here, but I don’t want to keep track of things the computer can keep track of for me)

So, everything is fine? Not really! With this setting I noticed something annoying. The App store didn’t work anymore and was dreadfully slow.

It looks like Apple is doing loads of CRL and OCSP requests during startup of the application and some more when trying to install or update an application. However, by playing around with the keychain settings I found out that the CRL requests fail and therefor the installation is (correctly) denied. I don’t mind that, but there are a couple of things that do bother me.

1. Why does it make the App store dreadfully slow? The certificates only have to be validated upon installation, a secured connection to the App Store should be sufficient protection for the catalogue.
2. Why do I get such a cryptic error message?
3. But above all, how it is possible that the App Store contains packages that fail to install if CRL validation is set to “Required when certificate indicate”.

To have a reliable system we should be able to trust that it is correctly configured. The default configuration on Mac OS X is a mess. An important function, CRL and OCSP online validation of certificates is disabled by default. When we enable it an integral part of the Mac OS X ecosystem fails, because of an apparent incorrect configuration of the developer certificates used to sign software in the App store.