Friday, 8 December 2017

When certificates don't certify

I’ve spent the last few days trying to fix a pretty weird munki problem on a computer i manage. Turns out it wasn’t a munki problem at all. It all boiled down to certificates.

The munki server runs over https. This environment has a home-baked PKI with a root certificate and an intermediate cert, which has signed the munki server’s cert. The root and intermediate certificates are nicely tucked in to the computers System keychain and the Mac is set to Always Trust the Root CA. All should be fine.

But while i could surf to my munki server with a browser or with curl, i could not get managedsoftwareupdate to work.

Instead of steaming off with what i tried and what didn’t work, i’ll just tell that a clue to why it didn’t. I was not able to sudo curl https://munki.server.

Turns out that the Root CA, even though it was in the System keychain, was only trusted by the currently logged in user. So i removed the Root CA from the System keychain, added it again from the command line:

% sudo security add-trusted-certificate -d -r trustRoot \ 
-l /Library/Keychains/System.keychain path/to/ca.cert.pem

(Adding it from the GUI didn’t, somehow, help).

Et voilĂ , managedsoftwareupdate works again.

And i now think i know why. I believe i might have imported the root and intermediate certificates by dragging them into my login keychain using the Keychain Access app, then realising they were in the wrong spot, and drag-and-dropping them into the System keychain. That would explain how a cert in the System keychain, which should be available for the whole system, was only available for $me.

Silly $me.

Thursday, 19 January 2017

Validating your Munki manifests and pkgsinfos

Sometimes, bad things happen to your .plist files. Thus, it is prudent to run the following check on your Munki repo before deploying into production:

find {manifests,pkgsinfo} -type f -exec xmllint --output /dev/null {} \;

This will find all the files under the manifests and pkgsifo directories, check them for well-formedness (but not content; you might still have a typo in what you actually want to say!), and report only on the errors.

The output is sent to /dev/null, as xmllint would otherwise spew out all valid plist files to the terminal, effectively hiding any problems you might have had. A --quiet|-q option would have been cleaner...