Openssl Certificate Management

---

NOTE: The information on this page is likely outdated, and is ported forward from an old wiki solely for posterity and future reference/updating.

---

These steps will allow you to create a Certificate Authority, which esentially signs SSL keys for a particular service, host, site, or combination thereof. I'm assuming that you are using OpenSSL on a Linux box, but the steps are probably pretty similar for other SSL toolkit/operating system combinations.

1. Create Certificate Authority (CA)
   1. Update openssl.cnf to reflect your organization. This file is generally located in /usr/share/ssl, but may be in /usr/local/share/ssl/, or another location, depending on how you installed openssl. You can get creative here, but this will just cover the basics.
      1. Find the section labeled CA_default. This is where all of the default and system-wide settings will be kept.
      2. dir should be the root of the location where you will keep all of your files associated with this CA. If specified as a relative directory (i.e. ./my_ca), it will be relative to the directory that holds the openssl.cnf file. Create this directory with permissions of 0700.
      3. certs, crl-dir, and new_certs_dir are generally specified relative to $dir, and should be created with permissions of 0700 as well. You should also create the directory <certs>/private with the same permissions.
      4. database, and serial are generally specified relative to $dir, and are created with the commands below:
         1. touch <database_specified_in_cnf> ; chmod 0600 <database_specified_in_cnf>
         2. echo 01 > <serial_specified_in_cnf> ; chmod 0600 <serial_specified_in_cnf>
      5. You can edit the other settings in openssl.cnf, but they are not necessary. If you're planning to create or sign a LOT of keys or certs, you could fill out some or all of the *_default settings in the req_distinguished_name section. For any variable name that doesn't already have a _default entry, you can create one.
      6. Although not required or specified in openssl.cnf, I also create a 0700 mode directory in the "certs" directory called "csr_complete", just for tree neatness.
   2. Run the following commands as root, or a user with write permissions to all of the directories and files discussed above:
      1. openssl req -x509 -new -days <num_days_ca_cert_should_be_valid> -out <certificate_specified_in_cnf> -keyout <private_key_specified_in_cnf>
      2. I use <organization>-ca.pem and <organization>-ca_key.pem as filenames for the cert and key, respectively.
      3. The passphrase that you specify during this process is extremely important and sensitive. Anyone with your key and that passphrase will be able to perform SSL actions on your behalf, which affects the trustworthiness and security of all communications that rely on any certificates that have ever been signed by your CA.
   3. Verify appropriate permissions are set on all files and subdirectories within the dir that you specified in openssl.cnf.
   4. To renew CA, use: openssl x509 -in oldcert.pem -out newcert.pem -days <insert_large_number_of_days> -signkey cakey.pem
2. Configure client app(s) to trust all keys signed by the CA
   1. TODO TODO TODO TODO TODO TODO TODO TODO TODO TODO
3. Generate SSL key (key) for your service/host/etc
   1. This step can be accomplished on either the CA system, the system where the certificate will ultimately be used, or any other system, for that matter. However, keep in mind that you will be creating a private key in this step! If it is created on any system other than the one where it will ultimately be used, you'll need a trustworthy, secure means of moving a file to that final system! Using any insecure means will expose the private key material to being viewed and captured by a third party, who would then be able to decrypt any traffic that has been encrypted with that key.
   2. Run the following command as root, or more preferably, the user that will be using the key/cert to secure traffic:
      1. openssl genrsa -out <file_for_private_key_material> 2048
      2. Note that the 2048 above specifies the key size for this key, and should be changed to remain in accordance with any local laws or other requirements.
      3. I generally name the private key file something like <service>-<host>_key.pem file, because it then indicates all relevant information just by the filename. Whether you choose this naming convention or not, decide on one and stick to it. This certainly isn't required, but will greatly simplify management of keys and certificates down the road.
4. Generate Certificate Signing Request (CSR) for the key
   1. As the same user that created the key, run the following command:
      1. openssl req -new -key <file_for_private_key_material_above> -out <file_for_certificate_signing_request>
      2. For CSRs, I use the naming convention <service>-<host>.csr
   2. Transmit this CSR to the CA, using a secure means. (TODO: I don't think that CSRs are sensitive in and of themselves, but I need to check on that...)
5. CA signs key via CSR, creating Public Certificate (cert)
   1. The CA verifies that the CSR contains valid information, and if comfortable with the truth of that information, signs the CSR.
   2. As root or a user with write permissions to the CA dir tree, run the following command:
      1. openssl ca -days <num_days_cert_should_be_valid> -in <CSR_received_from_above_step> > <public_key_filename>
      2. I use <service>-<host>.pem as a naming convention.
   3. Transmit the public key certificate file to the requestor. This file is public knowledge, so while secure means may be preferable for a number of reasons, it's not strictly required.
6. Configure server to use key/cert combination