Background

Traditionally, a server's SSL certificate is signed by a well-known (root) certificate authority (CA). The signing CA is trusted (or not) by a client when the client consults the list of trusted root CA certs that is provided by Apple in every copy of Mac OS X. These trusted roots live in

/System/Library/Keychains/SystemRootCertificates.keychain

For a server using a SSL cert that is signed by a known authority, use of that cert is fairly straightforward: you provide the service the cert file and the corresponding private key file; when the client connects, the cert is validated against the client's list of trusted roots. It looks something like this:

Root CA |     << trust evaluation >>  [client's list of trusted roots]
        |
         \
          Server cert

In this configuration, the iCal Server config would contain something like shown below.

    <!-- Public key -->
    <key>SSLCertificate</key>
    <string>foo.com.crt</string>

    <!-- Private key -->
    <key>SSLPrivateKey</key>
    <string>foo.com.key</string>

But then...

For security reasons, CAs have recently begun to sign customer SSL certificates not with their root CA, but rather with an intermediate CA. An intermediate CA has a cert that was signed by the root CA. When the client tries to validate the server's cert, it checks to see that the signer (the intermediate CA) is trusted. This may be a problem, because the (newfangled) intermediate CA is typically NOT in the list of the client's trusted roots. This causes the client to throw warnings when connecting to the service over SSL.

Root CA |
        |
         \ 
          Intermediate CA |   << trust evaluation >>  [client's list of trusted roots]
                          |
                           \
                            Server cert

What Now?

Depends on who you ask. SSL is a rat's nest. For us (iCal Server), this means:

Create an SSL Authority Chain file. This file specifies each step in the SSL authority chain, from the root down to the server cert. A graphical depiction of such a chain is shown in the previous section.
Configure iCal server with an additional parameter that declares the location of the SSL Authority Chain file you created above.

Constructing an SSLAuthorityChain file

The SSL authority chain file is literally a concatenation of the server cert, any intermediate cert, and then the root cert. Be sure to specify them in the correct order based on the trust hierarchy. The server cert should be the first cert in the file, and the root should be the last. Each of these certificates should be made available by the cert provider. A concatenated chain file might look something like:

Configure SSLAuthorityChain in caldavd.plist

This part is pretty easy. Just add the following stanza to the config file:

    <!-- SSL Authority Chain File -->
    <key>SSLAuthorityChain</key>
    <string>foo.com.chcrt</string>

We use 'chcrt' to denote 'chain cert', which is the concatenated representation of the authority chain from server to root.

Errata

Odds and ends that may be useful in configuring or troubleshooting this stuff

Show cert details

In particular, two important attributes you'll see here are Issuer and Subject. Issuer identifies the CA that signed this cert, and subject identifies the owner of this cert. This is useful to verify the order of the certs in the chain file.

openssl x509 -text -in foo.crt

Examine a keychain's contents

sudo security dump-keychain /System/Library/Keychains SystemRootCertificates.keychain | grep alis

Remove a trusted cert from Keychain

Sadly, this works on 10.5.8 and later, but not 10.5.7. The argument after -c is the name of the cert, which is shown on the 'alis' line of the dump-keychain output.

sudo security delete-certificate -c "Entrust Certification Authority - L1B" /Library/Keychains/System.keychain

Validate the SSL cert chain of a running service

Remember that each cert can be decoded if necessary; see above.

openssl s_client -showcerts -connect foo.apple.com:8443