Enable a CRL endpoint for my CA in Keychain Access

Solution 1:

Unfortunately, Keychain Access (Certificate Assistant) does not have the ability to include a CRL Distribution Point inside of a certificate's extensions section in certificates that it generates. You'll likely notice that your current CA does not have a CRL distribution point specified (even if you've enabled CRL signing as an allowed usage of that certificate during creation.)

It just works!

Interestingly enough, when setup as an Open Directory master, OS X Server automatically creates a self-signed certificate authority along with an Intermediate CA - both of which possess a CRL distribution point (with a format similar to: http://server.example.com:1640/rfc2585/Example.crl.) These certificates are not generated by Certificate Authority, but by xscertd-helper, which is forked by slapconfig during Open Directory setup and configuration. If your machine were already running Open Directory, you could use slapconfig (mainly xscertd-helper) to:

• Create a self-signed certificate authority
• Sign an intermediate authority cert (both containing CRL distribution points on the OD server "server.example.com")
• Store both certificates in the System keychain and LDAP "Certificate Authorities" container
• Create and update CRLs at /var/db/crls automatically
• Respond to SCEP requests on port 1640 (xscertd)

From the slapconfig man page, the command that you can use to recreate the CA setup used by Open Directory (note: this is part of the OD setup process and is unnecessary in most situations) is:

-createrootcertauthority <Certificate Authority Name> <Certificate Authority Admin Email> <Certificate Authority Organization Name>
Create a CA on the OD master.

Unfortunately, slapconfig will check to confirm that the machine is an OD master before allowing this setup to commence. Although you can trick it into performing a few steps by setting false flags in plist files (/Library/Preferences/com.apple.openldap.plist), the software eventually makes LDAP queries to the local node, and fails to find the node responding (or fails to find the certificationAuthority object class).

There is a utility named xscertadmin that can be used (by humans!) to add items to the CRL distribution list. However, that software is (again) reliant on your computer being an OD master (and running xscertd). From what I can see, Apple is storing several pieces of data in the System Keychain (identity preferences for the OD CA and IA certs, the passphrase used to secure each private keys, as well as the certificates themselves) as well as in the LDAP database (CRL, CA certs). It appears that this utility is really only meant to read and write certificate and CRL data to/from the local LDAP node and System Keychain.

The downside to the OD setup is that it doesn't seem to be providing CRL distribution points inside of any of the certificates that are created by the Intermediate CA (i.e., the OD server's machine certificate; a code signing certificate for use with Profile Manager), which doesn't seem to be of much use.

Cranking it by hand

Of course, this doesn't rule out using openssl on the command line to manage your certificates. Certificate management can also be somewhat automated using openssl configuration files. However, you will still be required to keep track of certificates that you have issued and those that have been revoked.

You can export your current CA's certs and keys out of Keychain Access, and (given it was created with the usage ability to sign CRLs) can use it for management of your certificate signing. Unfortunately, this will not give you the ability to use the user-friendly Certificate Assistant interface.

Although it is also likely possible to mimic the setup that Apple is using (storing CA keys inside of the Keychain), when signing certificates with OpenSSL, the workarounds that would have to be performed in getting the keys out so that openssl can sign would be a bit of work, and may minimize the return.