Apple

*
Apple has released a security update for Snow Leopard and Lion that addresses this issue:

Snow Leopard: http://support.apple.com/kb/DL1446
Lion: http://support.apple.com/kb/DL1447

There is no update for Leopard, so, in that case, you should still follow the instructions below.

Apple's update simply drops these files into place (on Lion):

/System/Library/Keychains/EVRoots.plist
/System/Library/Keychains/SystemRootCertificates.keychain
/System/Library/Keychains/SystemTrustSettings.plist

So, no matter which updates you made to the Diginotar cert -- delete or untrust -- the Apple update will just plow over all of that with the right setting and updated certs.
*

While ignoring how broken the entire Certificate Authority (CA) model is, here's what you should do right now: Delete the CA cert for Diginotar from your system. Why?

http://www.computerweekly.com/Articles/2011/08/30/247730/Microsoft-warns...

Now, if you're an individual, this is simple: just remove it from your system. Since I largely focus on Macs here, that would be in the keychain. Open Keychain Access.app, search for "Diginotar" and delete the resulting certificate.

...and don't forget Firefox, which keeps its own list of CAs:

http://support.mozilla.com/en-US/kb/deleting-diginotar-ca-cert

But, what if you're a Sys Admin responsible for protecting a fleet of machines and you don't expect end-users to do this themselves? (Or, that you're going to personally visit each machine.) Automate it, of course! The security binary will help you do that:

sudo /usr/bin/security delete-certificate -Z C060ED44CBD881BD0EF86C0BA287DDCF8167478C /System/Library/Keychains/SystemRootCertificates.keychain

(You can first check for the existence of the certificate using security's find-certificate instruction.)

Of course, you're using a system management framework that will allow you to run this command on all the machines in your fleet, right?

Update: This turns out to be a little more complex than simply removing the certificate. While removing the Diginotar cert is still recommended, DigiNotar is cross signed by other CAs. Removing the Diginotar root only removes one of them (and there are 5 paths). Also, it seems that there are some bugs in Apple's certificate handling in some cases. So, what can we do?

Certainly, remove the Diginotar cert from your machines, as that does help the most egregious cases. From there, we have two options: Use FireFox 6.0.1, which uses its own root certificate store and is now protected against this. Secondly, we need to wait for a patch from Apple--the only one in a position to really address this. Only a patch from Apple can completely fix browsers and apps that rely on the system store, Safari, of course, being the biggest use case, with Chrome and Mail.app as two other Webkit-based apps that may rely on the system root store for certificate handling.

(Big thanks to Harald Wagener for review on this, and reminding me about using find-certificate.)

Honestly, there's no more finicky service under OS X Server than Software Update. Sometimes, you just need reset the service and start from scratch. Under Server 10.6, the best way I've found is to:

- Stop the service.
- Get a shell on the server and sudo up to root.
- mv /var/db/swupd /var/db/swupd.old
- mv /etc/swupd /etc/swupd.old
- mkdir -p /var/db/swupd/html
- chown -R _softwareupdate:_softwareupdate /var/db/swupd
- chmod g+w /var/db/swupd
- Use ServerAdmin to (re)set the preferences for the service
- Let 'er rip. (start the service)

Pretty awesome utility: most people know that you can pull up a web/javascript debugger under Safari. But did you know that you can expose this on (nearly) any WebKit frame? Try this:

defaults write -GlobalDomain WebKitDeveloperExtras -bool true

...and then launch (or, quit and relaunch) any app that exposes a WebKitUIView. Right-click on the WebKitUIView and choose "Inspect Element" - Bingo! Up pops the WebKit web debugger.

Now, some applications block this ability unintentionally, or sometimes very intentionally (Mail.app, I'm looking at *you*).

My book on Managed Preferences for Mac OS X has been released (Amazon Link).

I can't seem to find this documented plainly anywhere, so, now it will be: when you set your MobileMe iDisk to sync locally, it now creates a sparsebundle disk image in:

~/Library/FileSync/(FS_identifier)/(MobileMe_username)_iDisk.sparsebundle

You may want this information so you can exclude this path from backups or know how to mount the image manually.