SSL and TLS for Humans, Part 2 (Keychain Assistant) by Chris Pepper
In Part 1 of this article, we discussed SSL/TLS and how they work. In Part 2, we examine Apple's Certificate Assistant for working with SSL/TLS certificates. In Part 3, we will discuss command-line procedures for actually using SSL/TLS certificates. In Part 4, we will look at some streamlined CA tools.
Choose Your Weapon -- There are several different ways to deal with SSL/TLS certificates. The oldest is to use the command line; the openssl command can do just about everything with certificates, but is neither simple nor well documented (there is a lot of documentation for OpenSSL, but much of it is poor or tied to a specific service or product). On the other hand; OpenSSL is ubiquitous. OpenSSL is standard on Mac OS X, Linux, Solaris, etc.; and serves as the basis for Apache httpd's SSL/TLS capabilities.
To help customers deal with the complexities of SSL/TLS without using OpenSSL directly (it's not even a little bit "Mac-like"), Apple provides Certificate Assistant, normally launched from Keychain Access (in /Applications/Utilities). (For Windows and Linux users, an "Assistant" is what Apple calls a "wizard"). Certificate Assistant deals with both individual certificates (useful for SSL/TLS and encrypted mail), and CA certificates. Additionally, it can verify certificate and display detailed information, useful because certificates and keys are not normally human-readable.
It's worth noting that Apple provides a non-graphical alternative (actually two): certtool is a simple interactive text-based utility capable of handling the major certificate procedures (creating a CSR, creating a self-signed certificate, etc.). certtool uses simple prompts to request information; Apple designed it to manage certificates for the keychain, but Keychain Access makes it reasonably simple to import and export certificates and keys to text files. If you are only using Mac OS X (Server and/or non-Server), and need to work through a command line environment, certtool might be an excellent option. To learn about certtool, simply type "man certtool" in a shell (a Terminal window). Since certttool is neither cross-platform nor as easy to use as Certificate Assistant, and is incomplete, we will not discuss it further here. Apple intends to replace certtool with the security command, but unfortunately it has all the same limitations as certtool including being incomplete.
One of the easier ways to work with certificates on a Mac is through Server Admin (only available for Mac OS X Server). Server Admin makes it easy to create new certificates - simply click on a server's name (not a service but the server itself), then Settings, then Certificates, and then the large '+' (plus sign) button. Fill in the blanks, then click Save. Next choose either "Request Signed Certificate From CA..." (to generate a Certificate Signing Request) or "Add Signed Certificate..." (to self-sign). Unfortunately, when using Server Admin, Mac OS X Server can get confused and lose or delete certificates, so it's important for Mac OS X Server users to keep good backups and test SSL/TLS services after working with certificates.
http://www.apple.com/server/macosx/
There are many alternatives. As one example, for a while I used the web interface of our Big-IP load balancers to create CSRs and self-signed certificates for various different sites - the Big-IP UI is quick and simple, and about half our certificates were for the Big-IPs anyway.
http://www.bigip.com/products/bigip/
Apple's Preferred Tool -- Certificate Assistant is friendly and capable. It does have one particular oddity to be aware of, however: unlike most applications, it is not possible to initiate an action from within the program. There is no "New Certificate" command, or anything like that. Instead, if Certificate Assistant is launched by opening a configuration file, it creates a new CSR according to the contents of that configuration file; if it is launched with a CSR, it attempts to sign it; if the Assistant is launched by itself, it presents a menu of available actions.
What Can You Do? -- Certificate Assistant can help with the common certificate operations.
I suggest starting with a test CA (Certificate Authority), which gives the most flexibility; once you've figured out how things work, you can start again to create a real CA (or if you haven't made any mistakes or compromised the security of your test CA), you can simply begin to use the test CA "for real".
As part of creating a CA, Certificate Assistant offers several choices for how the CA will work. First, it suggests using 2048-bit RSA for the CA key; this is a good (strong) choice for encryption; next it suggests using 2048-bit RSA for all keys created by the Certificate Assistant CA; 128-bit is normal for commercial certificates, but 2048 bits provide stronger security. Unfortunately, while the "Learn More..." tab suggests 3000-plus bits for long-lived certificates and CAs, but Certificate Assistant only offers 512, 1024, and 2048 bits.
Certificate extensions were created to record attributes and restrictions for certificates; among other things they are intended to allow CAs to limit the certificates they create. Unfortunately restrictions are not used reliably, so accept Apple's defaults unless you have a specific reason not to.
Eventually, Certificate Assistant will ask which keychain file to store the CA's private and public keys in; then it will ask for a filename. Once these have been specified, Certificate Assistant generates the actual private and public keys (large numbers) and stores them in the specified keychain (if you can't see them immediately, quit and relaunch Keychain Access). Certificate Assistant puts the certificate (the public key and identifying information, signed by the private key) in a ".p7b" file (PKCS #7 format) inside ~/Library/Application Support/Certificate Authority. Note that all root certificates are implicitly self-signed (if there was a parent signature, it wouldn't be a root certificate!)
http://en.wikipedia.org/wiki/X.509
In addition, Certificate Assistant creates an XML file with a ".certAuthorityConfig" suffix, containing all the non-cryptographic information from the certificate but no keys or signature. If a Mac user opens this file, Certificate Assistant launches and walks through the process of requesting a certificate from the CA that created the XML file. Theoretically, the completed CSR is automatically sent to the CA for signature and return, but I have been unable to find such an email message.
2. Create a new certificate signing request -- In theory, Certificate Assistant makes this trivially easy. If your Certificate Authority is using Certificate Assistant as well, just double-click on the appropriate ".certAuthorityConfig" file, answer the prompts (your address and the Canonical Name, normally the website's full hostname, such as "www.tidbits.com"), and let CA do its magic. Unfortunately, Certificate Assistant claims to send an email to the CA with the CSR for signing, and I am unable to find any trace of the actual CSR after that point. As a CA, I've never actually received such a CSR email, or been able to find a file containing the new CSR.
If you don't have an XML configuration file for your CA, Certificate Admin is still easy to use - it simply prompts for more information (the XML file is mostly used to skip prompts, instead automatically picking up the CA's preferred settings).
3. Create a self-signed certificate --
4. Request that a CA sign a CSR, and return a signed certificate --
5. Sign a CSR with your own root certificate --
6. Check a certificate --
7. Install a certificate in a server --
8. Trust a certificate in a browser --
9. Test an SSL/TLS connection --
What Comes Next? In Part 3 of this article, we will look at command-line procedures for running a CA.