In this post I’ve outlined the procedure for generating SSL requests, keys and certificates for ECS, as well as outlining the process for uploading them to ECS and verifying the installed certificates afterwards. This was a new process for me so I created very detailed documentation on the process I used, hopefully this will help someone else out.

I mention using the ECS CLI a few times in this document. If you’d like to use the ECS CLI, I have another blog post here that reviews the details on it’s implementation. It requires Python.

Part 1: Generating SSL requests, Keys, and Certificates.

The procedure for generating SSL requests, keys, and certificates is unnecessary if you will be given the certificate and key files from a trusted source within your organization. If you’ve been provided the certificate and key file already, you can skip to the Part 2 that details how to upload and import the keys and certificates to ECS. This is of course a sample procedure on how I did it in my organization, specific details may have to be altered depending on the use case.

a. Prepare for Creating (or editing) the SSL Request file

The first step in this process is to generate an SSL request file. As OpenSSL does not allow you to pass Subject Alternative Names (SANs) through the command line, they must be added to a configuration file first.

On ECS, the OpenSSL configuration file is located at /etc/ssl/oenssl.cnf by default. Copy that file to a temporary directory where you will be generating your certificates.

Run this command to copy the request file for editing:

admin@ecs-node1:~# cp /etc/ssl/openssl.cnf /tmp/request.conf

b. Make changes to the request.conf file. Edit it with vi and make the edits outlined below. Each bullet reviews a specific section of the file where changes are required.

[ alternate_names ] Edit the [ alternate_names ] section. In a typical request file these are included at the very end of the configuration file. Note that this request example includes the wildcard as the first entry (which is required by S3).

Search for “basicConstraints” in the [ v3_ca ] section. You may see “basicConstraints = CA:true”. Make sure it is commented out – add the # to the beginning of the line.

# basicConstraints = CA:true

Search for “keyUsage = cRLSign, keyCertSign” in the [ v3_ca ] section. You may see “# keyUsage = cRLSign, keyCertSign”. Make sure it is commented out.

# keyUsage = cRLSign, keyCertSign

[ v3_req ] Verify the configuration in the [ v3_req ] section. The line below must exist.

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ usr_cert ] Verify the configuration in the [ usr_cert ] section.

Search for the entry below and uncomment it, it should be added.

extendedKeyUsage = serverAuth

The following line is likely to already exist in this [ v3_ca ] section. The authorityKeyIdentifier line exists in multiple locations in the config file, however in the v3_ca section it must have “always,issuer” as its option.

# authorityKeyIdentifier=keyid:always,issuer

[ req ] Verify the configuration In the [ req ] section.

For our dev environment, in the testing phase with a self-signed certificate, the following entry was made six lines below the [ req ] header:

x509_extensions = v3_ca # The extensions to add to the self-signed cert

The x509_extensions line also exists in the [ CA_default ] section. This was left untouched in my configuration.

x509_extensions = usr_cert # The extensions to add to the cert

Change based on certificate type. Note that this will change if you’re not using a self-signed certificate, which I did not test. The req_extensions line exists in the default configuration file and is commented out.

Now that the private key is generated, you can either create a certificate request (the .req file) to request a certificate from a CA or generate a self-signed certificate. In the samples below, I’m setting the Common Name (CN) on the certificate to *.os.example.com.

d. Generate the Certificate Request. Next we will look at the steps used to generate a certificate request.

Running the command above will prompt for additional information that will be incorporated into the final certificate request (the Distinguished Name, or DN). Some fields may be left blank and some will have default values, If you enter ‘.’ the field will be left blank.

Now that the certificate request is completed it may be submitted to the CA who will then return a signed certificate file.

e. Generate a Self-Signed Certificate. Generating a self-signed certificate is almost identical to generating the certificate request. The main difference is that instead of generating a request file, you add an -x509 argument to to the openssl req command to generate a certificate file instead.

Running that command will prompt for additional information that will be incorporated into the certificate request. This is called a Distinguished Name (DN). Some fields may be left blank and some will have default values, If you enter ‘.’ the field will be left blank.

f. Chain File. In either a self-signed or a CA signed use case, you now have a certificate file. In the case of a self-signed certificate, the certificate is the chain file. If your certificate was signed by a CA, you’ll need to append the intermediate CA cert(s) to your certificate. I used a self-signed certificate in my implementation and did not perform this step.

Append the CA cert if it was signed by a CA. Do not append the root CA certificate:

f. Verify that the certificate was propogated to each node. The output will show the certificate, scroll up and verify all of the information is correct. At the minimum the first and last node should be checked.

3. Verify the Installed Certificates. The object certificate and management certificate each have their own GET request to retrieve the installed certificate. Note that these commands are management requests.

a. Verify the installed/Active Management Certificate

An alternative method to this one, which I used personally, is the OpenSSL s_client command. The details in step 3a below aren’t necessary if you are going to use s_client for verification, I’ve simply included them here for completeness. You can skip to step 3b for the s_client method.