The custom root CA certificate must be installed on each client system that will use the service. If only internal systems with automated configuration need be supported, installing a custom root certificate is trivial. When many unmanaged systems are involved, purchase certificates from a commercial third party CA.

The level of security for a custom CA depends on the site and what the encryption is being used to protect. A personal site could simply store the CA in an encrypted file. A larger organization with different subgroups should consider a CA for each subgroup (accounting, development, public systems) on different systems, at minimum.

Using a custom area for each CA prevents vendor updates from modifying the configuration and scripts used, and allows customization as required on a per-CA basis.

The example CA for sial.org is located on an encrypted 512K Unix File System (UFS) disk image created with Disk Copy on Mac OS X. Alternatives include encrypting a tarball of the CA directory with openssl or gpg, and decrypting/unpacking and packing/encrypting as needed.

Download and customize these files to suit the needs of the CA in question, then run the following to setup the required files and directories.

Currently, the Makefile and custom openssl.cnf configuration file can only generate a CA, and sign certificate signing requests for certificates, and revoke signed certificates. Certificate Signing Requests (CSR) must be generated using a different openssl.cnf, such as the system-wide one.

Options must be customized before running the following command, especially the days the various certificates will last for and the x509 attributes (commonName, among others) used in certificates. If running OpenSSL 0.9.8a or higher, change the -newkey rsa option to -newkey rsa:2048.

This should create a number of new files and directories that the CA needs to operate properly.

# lsMakefile crl newcerts privateca-cert.pem index openssl.cnf serial

Usually a password is used on the CA private key (stored here in private/ca-key.pem); however, for my needs a single password on the encrypted disk image works well enough, as the system in question is used only by me. To encrypt the private key file, remove the -nodes argument from the openssl command under the init rule in the Makefile before running make init.

The CA certificate must be installed on all client systems that will be interacting with certificates signed by the custom CA certificate. The make init step saves this CA certificate data into the ca-cert.pem file by default.

The resulting mail.example.org.cert should be returned to the client, and also saved for future use, such as certificate revocation. Certificates are stored under the newcerts directory, though with filenames based on the serial number, not the requesting host.

If, when signing a new request for a host a previous certificate was signed for, OpenSSL fails with an error similar to the following, either set the unique_subject = no option in openssl.cnf (or index.attr), or first revoke the old certificate.

If a particular certificate is no longer to be trusted, it can be revoked by the CA. Revocation itself is easy; the hard part is distributing the revocation list to all client applications that use the CA certificate.

A CA should save certificates it signs under the CA directory to ease revocation. Saving the certificates as hostname.cert is one way to do this; a copy of the certificate is also saved under newcerts, though is named after the serial number.