The reason that importing the CA cert that was created via the tutorial for setting up a HTTPS munki server failed was the certificates, not the import method.
Once I corrected the certificates, the following workflow worked:
# Create the keychain at ~/Library/Keychains/ (or specify a full path instead of a relative filename)
security create-keychain -p munki munki.keychain
# Unlock it
security unlock-keychain -p munki munki.keychain
# Disable locking on it
security set-keychain-settings munki.keychain
# List the existing keychain paths (this is only necessary for 10.9+ which doesn't auto-add the keychain to search paths)
security list-keychains -d user
# Set search paths with existing paths (dumped by prior command) + new keychain location
security list-keychains -d user -s ~/Library/Keychains/login.keychain ~/Library/Keychains/munki.keychain
# Import the CA cert - note that using -r TrustRoot and placing it in the System keychain is not necessary
# Simply fully trusting it and putting it in a user keychain in the keychain search path is enough
security add-trusted-cert -k munki.keychain ~/Desktop/certs/ca.pem
# Import the client cert, no trust required
security import ~/Desktop/certs/client.pem -k munki.keychain
# Find the imported client cert by name and extract the SHA-1 hash
# This is a workaround for set-identity-preference getting confused between the cert and
# key of the client.pem, I think
security find-certificate -c munki_client -Z munki.keychain | grep 'SHA-1 hash'
# Use the hash to set an identity preference for the munki repo
# There's no need to specify a keychain here, the security command does not currently
# create identity preferences from the command-line outside of the 'default'/login keychain
# (Keychain Access.app lets you do this, however.)
security set-identity-preference -s 'https://trustedsite.dev/' -Z HASH_GOES_HERE
*** Analysis of the certs ***
The problem is that curl is too lenient with certificate verification in comparison to OS X. curl just checks to see if the certificate you received was signed by a CA that it knows / that you've pointed it towards.
OS X will actually check the purpose of the certificate and if it's being used for TLS / HTTPS, it won't let you use it for that unless the purpose was declared under the X509v3 extensions. Same goes for the key usage section.
The tutorial on the munki wiki has a very poor openssl.conf being used to generate the server certificates. It's "good enough" for curl, but not for OS X which is actually performing real x509 verifications.
openssl.cnf changes for generating a server:
[ CA_default ]
default_md = sha1
[ req ]
# x509_extensions = v3_ca
req_extensions = v3_req
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth, nsSGC
When used to generate a server cert and key, you can verify the certificate with openssl via:
openssl x509 -in server.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
bc:b6:[...]
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=WA, L=Olympia, O=Company, OU=IT, CN=MUNKI_CA
Validity
Not Before: Nov 26 09:19:42 2013 GMT
Not After : Nov 26 09:19:42 2014 GMT
Subject: C=US, ST=WA, O=Company, OU=IT, CN=trustedsite.dev
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b3:[...]
5d:bc:[...]
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto
Signature Algorithm: sha1WithRSAEncryption
36:d1:[...]
b7:24:[...]
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----