Creating a Certificate Authority and generating certificates

Sample steps to create a CA and generate default certificates.

About this task

If you do not have a corporate CA, you can perform the sample steps listed below to create one and generate the required certificates. Ensure you modify all relevant data to match your environment. For more information about OpenSSL commands, see the related documentation.

You can use the openssl command located in the installation directory, as follows:

Procedure

  1. Browse to the following path:
    On Windows operating systems
    inst_dir\TWS\bin\tmpopenssl
    On UNIX operating systems
    inst_dir/TWS/tmpOpenSSL64/1.1/bin/openssl
  2. The following command generates a key with a length of 4096 bits and saves it to the ca.key file:
    ./openssl genrsa -out ca.key 4096
    where
    out
    specifies the output file name to write to
  3. The following command generates a self-signed X.509 certificate with the subject name /CN=my_name and saves it to the ca.crt file:
    ./openssl req -x509 -new -nodes -key ca.key -subj "/CN=my_name" 
                        -days 36500 -out ca.crt -config ./openssl.cnf
    where
    req
    specifies that the input file is a certificate request
    x509
    outputs a self signed certificate instead of a certificate request
    new
    generates a new certificate request
    nodes
    specifies no encryption is defined
    key
    specifies the file to read the private key from
    subj
    sets the subject name for a new request
    days
    specifies the number of days to certify the certificate for
    out
    specifies the output file name to write to
    config
    specifies the configuration file
    The ca.key must remain secret, while the ca.crt is involved in the procedure.
  4. The following command generates a new RSA private key with a length of 4096 bits, encrypts it using the AES-256 cipher, and saves it to the tls.key file:
    ./openssl genrsa -aes256 -out tls.key 4096
    where
    genrsa
    generates an RSA private key
    aes256
    specifies that the private key should be encrypted with AES-256 encoding
    out
    specifies the file name to save the private key to
  5. The following command generates a new certificate signing request (CSR) with the subject name my_name and saves it to the tls.csr file:
    ./openssl req -new -key tls.key -out tls.csr 
                        -subj my_name -config ./openssl.cnf
    where
    req
    specifies that the input file is a certificate request
    new
    generates a new certificate request
    key
    specifies the file to read the private key from
    out
    specifies the output file name to write to
    subj
    sets the subject name for a new request
    config
    specifies the configuration file
  6. The following command generates a new X.509 certificate by signing the certificate request in tls.csr with the private key in ca.key and saving the resulting certificate to tls.crt:
    ./openssl x509 -req -in tls.csr -days 36500 -CA ca.crt 
                        -CAkey ca.key -CAcreateserial -out tls.crt 
    where
    x509
    req
    specifies that the input file is a certificate request
    in
    specifies the file name of the certificate request to sign
    days
    specifies the number of days that the certificate is valid for
    CA
    specify the file name of the CA certificate to use for signing the certificate request
    CAkey
    specify the file name of the private key to use for signing the certificate request
    CAcreateserial
    specifies that a new serial number file should be created if one does not already exist
    out
    specifies the output file name to write to
  7. Retrieve the tls.crt, tls.key, and ca.crt files.
    You have now created the CA and the default certificates.

What to do next

You can copy these files to a local folder on the workstation where you plan to install an HCL Workload Automation component. If you are installing or upgrading a dynamic agent or fault-tolerant agent, you can also copy the certificates to the /depot folder on the master domain manager and download them to the agents at installation or upgrade time (using the twsinst script), or whenever necessary (using the AgentCertificateDownloader script). For more information about the twsinst and AgentCertificateDownloader scripts, see Reference.