SSL Certificate Generation

Overview

For the purposes of a Client machine authenticating a Server and vice versa, a minimum of three x509 certificate/key pairs are needed:

  • A certificate authority (CA)

  • A Server certificate

  • A Client certificate

Deadline Clients expect the Client certificate and private key to be in PKCS#12 format (*.pfx or *.p12 file), which can be password-protected. Additionally, it is recommended that this PKCS#12 file contain a copy of the CA certificate (NOT its private key), allowing Deadline to validate the Server’s certificate without needing to add the CA to the OS’s list of trusted roots.

These certificates can be generated with any certifiate authority (CA) system. The documentation below outlines an example of how to generate these certificates and keys using OpenSSL.

Requirements

  1. OpenSSL

Usage

This section will go over how to generate each one of these using the utility script linked in the overview above.

NOTE: While the certificates themselves (*.crt) can be transported without much worry (they can be considered public knowledge), private keys (.key) are more sensitive in nature. Knowledge of any of the private keys would allow impersonation of a valid Client or Server (or both) in the system; as such, these files should be password-protected whenever possible, and always maintained with restrictive file permissions/ACLs. Note that sometimes, both the certificate and private key are combined into a single file for convenience (generally in *.pem, *.pfx, or *.p12 files).

The ‘-days’ option in the commands below sets the expiry date for each certificate. These can be customized as needed, keeping in mind that certificates will need to be re-generated and replaced before their expiry dates to avoid connectivity issues. The examples below are set to 10 years (3650 days) for the CA certificate, and 1 year (365 days) for the server and client certificates.

1. Generate a new Certificate Authority

The Certificate Authority (CA) is used to sign other certificates, indicating that they can be trusted as authentic. In this way, trusting a root CA in turns implies trust of all certificates that were (or will be) signed by that CA; this is the mechanism that Deadline leverages to authenticate clients and servers when negotiating secure communication. For this reason, it is important that the CA machine is secure, and that permissions for the CA key is restricted to users who need it to perform certificate signing operations.

To generate a new CA, run the following commands:

  1. Generate the new CA key:

    openssl genpkey -algorithm RSA -out ca.key

  2. Generate the CA certificate based on the new CA key by running the following command and entering the requested information, with the ‘Common Name’ set to ‘CA’.

    openssl req -new -x509 -key ca.key -out ca.crt -days 3650

  3. Create a file named usage.cnf in the same location as the CA certificates created above, with the following contents:

    [serverAuth]
extendedKeyUsage = serverAuth

[clientAuth]
extendedKeyUsage = clientAuth

This will create a ‘ca.crt’ and ‘ca.key’ file in the current directory. The public portion of this (the *.crt file) will need to be distributed to the Client and Server machines, so that they can validate each other’s certificates (that will be signed by this CA). This can be done by packaging the *.crt in a PFX file (see last step). On the other hand, the private portion of this (the key) should be closely guarded. Access to the private key of a Certificate Authority allows creation of new client certificates, which would automatically be trusted by the server.

2. Generate the server certificate

This is the certificate that the Server will use for the purposes of identifying itself when negotiating TLS connections. It will be signed by the CA that was generated in Step 1.

To generate the server certificate, follow these steps, replacing ‘<server_name>’ with the name of the RCS server machine.

  1. On the RCS server, generate the key and signing request by running the following command. Enter the organization information as prompted, with the ‘Common Name’ set to the server name. The ‘challenge password’ and ‘optional company name’ can be left blank.

    openssl req -new -nodes -keyout <server_name>.key -out <server_name>-req.pem

  2. Copy the ‘<server_name>-req.pem’ file to the CA machine.

  3. On the CA machine, generate the certificate based on the signing request:

    openssl x509 -req -days 365 -in <server_name>-req.pem -out <server_name>.crt -CA ca.crt -CAkey ca.key -extfile usage.cnf -extensions serverAuth

  4. Copy the resulting ‘<server_name>.crt’ and ‘ca.crt’ files to the RCS server.

  5. On the RCS server machine, create the PKCS#12 (pfx) file for use with Deadline RCS by running the following command. This file will include the client private key and certificate.

    openssl pkcs12 -export -in <server_name>.crt -inkey <server_name>.key -out <server_name>.pfx

The ‘<server_name>.pfx’ and ‘ca.crt’ files will be used to configure the RCS. The pfx and key files should be secured on the RCS server with restrictive file permissions granting read access only to the user(s) that will run the RCS process.

3. Generate the client certificate(s)

This is a certificate that will be used by Deadline clients to authenticate themselves, and you can create more than one. While they don’t need to be signed by the same CA as the Server certificate, the Server will need to trust the root that does sign it (either by having it specified explicitly, or present in the OS-level trusted store).

While it is highly recommended to generate a separate client certificate for each client machine for optimal security, a single client pfx file can be shared across multiple clients if needed.

To generate a client certificate signed with the CA created in Step 1, run the following commands, replacing <client_name> with a name or identifier for the client:

  1. On the client machine, generate the key and signing request. Enter the organization information as prompted, with the ‘Common Name’ set to the client name. The ‘challenge password’ and ‘optional company name’ can be left blank.

    openssl req -new -nodes -keyout <client_name>.key -out <client_name>-req.pem

  2. Copy the ‘<client_name>-req.pem’ file to the CA machine

  3. On the CA machine, generate the certificate based on the signing request:

    openssl x509 -req -days 365 -in <client_name>-req.pem -out <client_name>.crt -CA ca.crt -CAkey ca.key -extfile usage.cnf -extensions clientAuth

  4. Copy the resulting ‘<client_name>.crt’ and ‘ca.crt’ files to the client machine.

  5. On the client machine, create the PKCS#12 (pfx) file for use with Deadline Client by running the following command. This file will include the client private key and certificate, and the CA certificate. Entering an export password is recommended to protect the private key. If an export password is entered, it will need to be entered in the Deadline Client connection configuration when specifying the certificate.

    openssl pkcs12 -export -in <client_name>.crt -inkey <client_name>.key -certfile ca.crt -out <client_name>.pfx

This will place a ‘<client_name>.pfx’ file in the current directory. This file can be specifed in the Deadline client configuration when configuring the connection to the Deadline RCS.