Introduction
JS7 - Deployment of Scheduling Objects makes use of Signing Certificates to digitally sign workflows and other objects. Signing Certificates are deployed to Controllers and Agents. Use of certificates for signing is not related to use of certificates to secure HTTPS connections, see JS7 - How to create X.509 SSL TLS Certificates.
Users can choose one of the approachs specified with RFC5280:
- Self-issued Certificates are created individually per user and are deployed from individual certificate files to Controllers and Agents.
- There is no security gap in use of self-issued Certificates. When users store certificate files to Controllers and Agents then this proves that they trust the certificates.
- Private CA-signed Certificates are issued by users who operate their own Private Certificate Authority (CA). Individual Signing Certficates on behalf of users are not deployed to Controllers and Agents. Instead, the CA Certificate is deployed that was used to sign individual Signing Certificates.
- The approach includes that any Signing Certificate signed by the CA will be accepted for deployment of scheduling objects.
- For better control which certificates are made available for deplyoment, users might decide to use a specific Private CA.
- Public CA-signed Certificates are issued by a trusted Certificate Authority (CA) that validates the domain owner. Such certificates are not created by users but are purchased from the trusted CA and are not in scope of this article.
There is no difference in using a Private CA or Public CA concerning functionality of X.509 certificates, usage for Signing, or security of certificates. The only difference is that users trust the Private CA that they set up on their own instead of trusting an external Public CA.
Self-issued Certificates and Private CA Certificates are deployed to the <data>/config/private/trusted-x509-keys
directory of Controller and Agent instances.
The article explains how to create Signing Certificates for use with JS7. Users who operate an existing Private Certificate Authority might find different approaches and different responsibilities for the indicated steps. There's more than one way how to do it.
Examples make use of JS7 Release 2.7.2, OpenSSL 1.1.1k FIPS 25 Mar 2021 for Unix and OpenSSL 3.1.4 24 Oct 2023 for Windows. OpenSSL ships with Linux & other Unix OS and is available for Windows.
Creating self-issued Certificates
Users chose this approach if they intend to authorize specific users to deploy scheduling objects:
- The approach is managable if the number of Controller and Agent instances that receive the certificate is within acceptable limits.
- Consider certificate renewal that includes to update the certificate file on related Controller and Agent instances.
- Consider certificate revocation that includes to remove the certificate file from related Controller and Agent instances.
- The approach allows fine-grained control, but comes at a price of having to manage deployment of user certificates individually.
Creating the Private Key and Certificate Signing Request
The steps to create a Private Key and Certificate Signing Request are similar for self-issued Certificates and Private CA-signed Certificates.
Users have the option to use ECDSA or RSA algorithms for encryption performed using the Private Key.
Users can run the following commands from the shell and replace the value of the key_name
environment variable with a name of their choice that is used when creating related files.
Using ECDSA Encryption
# Specify key name used for file names key_name=signing # Create Private Key openssl ecparam -genkey -name secp384r1 -out ${key_name}.key # Create Certificate Signing Request openssl req -new -sha512 -nodes \ -key ${key_name}.key \ -out ${key_name}.csr \ -subj "/C=DE/ST=Berlin/L=Berlin/O=SOS/OU=IT/CN=${key_name}"
Using RSA Encryption
Creating the Signing Certificate
Users can run the following commands from the shell and replace the value of the key_name
environment variable with a name of their choice that is used when creating related files.
# Specify key name used for file names key_name=signing # Create Certificate openssl x509 -req -sha512 -days 3652 \ -signkey ${key_name}.key \ -in ${key_name}.csr \ -out ${key_name}.crt \ -extfile <(printf "keyUsage=critical,nonRepudiation,digitalSignature\nextendedKeyUsage=critical,codeSigning\n")
Self-issued Certificates must be copied to the <data>/config/private/trusted-x509-keys
directory of Controller and Agent instances.
Creating CA-signed Certificates
Users chose this approach if they intend to authorize users to deploy scheduling objects based on Signing Certificates issued by a specific CA.
- Any certificates signed by the CA will be accepted by Controllers and Agents to which the CA Certificate is deployed.
- The approach makes sense if users are in control of certificates created by the CA. Benefits include that a single CA Certificate is deployed to Controller and Agents instead of individual certificate files from self-issued Certificates.
Setting up the Private CA
For Private CA-signed Certificates a Certificate Authority (CA) is required owning a CA Private Key and CA Certificate. The CA Private Key and CA Certificate will be used to sign certificates on behalf of users.
- Setup of the Certificate Authority is performed once.
- Signing is performed for each certificate on behalf of users.
The steps to create the CA Private Key and CA Certificate are similar to Creating the Private Key and Certificate Signing Request for self-issued Certificates.
Creating the Private Key and Certificate Signing Request
Steps include to create the signing-ca.key
CA Private Key file and signing-ca.csr
CA Certificate Signing Request file both in PEM format.
Users have the option to use ECDSA or RSA algorithms for encryption performed using the Private Key.
Users can run the following commands from the shell and replace the value of the ca_key_name
environment variable with a name of their choice that is used when creating related files.
Using ECDSA Encryption
# Specify key name used for file names ca_key_name=signing-ca # Create Private Key openssl ecparam -genkey -name secp384r1 -out ${ca_key_name}.key # Create Certificate Signing Request openssl req -new -sha512 -nodes \ -key ${ca_key_name}.key \ -out ${ca_key_name}.csr \ -subj "/C=DE/ST=Berlin/L=Berlin/O=SOS/OU=IT/CN=${ca_key_name}"
Using RSA Encryption
Creating the CA Certificate
Steps include to create the signing-ca.crt
Private CA-signed Certificate file in PEM format.
Users can run the following commands from the shell and replace the value of the ca_key_name
environment variable with a name of their choice that is used when creating related files.
# Specify key name used for file names ca_key_name=signing-ca # Create Certificate openssl x509 -req -sha512 -days 7305 \ -signkey ${ca_key_name}.key \ -in ${ca_key_name}.csr \ -out ${ca_key_name}.crt \ -extfile <(printf "basicConstraints=CA:TRUE\nkeyUsage=critical,nonRepudiation,keyCertSign,cRLSign\n")
The CA Certificate must be copied to the <data>/config/private/trusted-x509-keys
directory of Controller and Agent instances.
Creating Signing Certificates
The steps explained with this section are performed for each Signing Certificate created on behalf of a user.
Creating the Private Key and Certificate Signing Request
Steps include to create the signing.key
Private Key file and signing.csr
Certificate Signing Request file both in PEM format.
Users have the option to use ECDSA or RSA algorithms for encryption performed using the Private Key.
Users can run the following commands from the shell and replace the value of the key_name
environment variable with a name of their choice that is used when creating related files.
Using ECDSA Encryption
# Specify key name used for file names key_name=signing # Create Private Key openssl ecparam -genkey -name secp384r1 -out ${key_name}.key # Create Certificate Signing Request openssl req -new -sha512 -nodes \ -key ${key_name}.key \ -out ${key_name}.csr \ -subj "/C=DE/ST=Berlin/L=Berlin/O=SOS/OU=IT/CN=${key_name}"
Using RSA Encryption
Creating the Signing Certificate
Steps include to create the signing.crt
Private CA-signed Certificate file in PEM format.
Users can run the following commands from the shell and replace the value of the key_name
environment variable with a name of their choice that is used when creating related files:
# Specify key name used for file names key_name=signing # Create Certificate openssl x509 -req -sha512 -days 3652 \ -CA signing-ca.crt \ -CAkey signing-ca.key \ -CAcreateserial \ -in ${key_name}.csr \ -out ${key_name}.crt \ -extfile <(printf 'keyUsage=critical,nonRepudiation,digitalSignature\nextendedKeyUsage=critical,codeSigning\n')
The Signing Certificate file does not require to be deployed to Controller and Agent instances. Instead, the CA Certificate file is deployed to Controller and Agent instances.
Resources
Shell Scripts
As an alternative to running OpenSSL commands in an interactive shell, scripts are provided that perform this task.
The below scripts assume the following directory layout:
<ca>
The directory<ca>
is a placeholder. Any directory can be used.create_root_ca.sh
create_signing_certificate.sh
certs
csr
private
The sub-directories certs
, csr
and private
will be created should they not exist.
Creating the Private Root CA Certificate
Download: create_root_ca.sh
The following files will be created when executing the script:
<ca>/certs/root-ca.crt
<ca>/csr/root-ca.csr
<ca>/private/root-ca.key
This step is performed just once. In case of renewal of the Root CA Certificate any Server Certificates will have to be renewed.
# Description # create_root_ca.sh --key-name=<basename> --subject=<distinguished-name> --days=<number-of-days> # Example for use with defaults ./create_root_ca.sh # Example for use with basename ./create_root_ca.sh --key-name=ca-root # Example applying specific distinguished name and lifetime ./create_root_ca.sh --subject="/C=DE/ST=Berlin/L=Berlin/O=SOS/OU=IT/CN=JS7 CA" --days=7660
The shell script is optionally executed with the following arguments:
--key-name
- The basename of the key without extension. Default:
root-ca
- The basename of the key without extension. Default:
--subject
- The distinguished name that is used as the subject of the CA Certificate. Default:
/C=DE/ST=Berlin/L=Berlin/O=SOS/OU=IT/CN=Root CA
- The distinguished name that is used as the subject of the CA Certificate. Default:
--days
- The lifetime of the certificate is specified by the number of days. Default:
7305
- Consider that Server Certificates have to be renewed if the Root CA Certificate expires.
- The lifetime of the certificate is specified by the number of days. Default:
Creating a Signing Certificate
Download: create_signing_certificate.sh
The following files will be created with <user>
being a placeholder for the user for which a certificate should be created.
<ca>/certs/<user>.crt
<ca>/csr/<user>.csr
<ca>/private/<user>.key
This step is performed for each Signing Certificate that should be created.
# Description # create_signing_certificate.sh --key-name=<basename> --ca-key-name=<basename> --subject=<distinguished-name> --days=<number-of-days> # Example for use with key name and lifetime ./create_signing_certificate.sh --key-name=ap --days=365 # Example for use with key name, CA key name and lifetime ./create_signing_certificate.sh --key-name=ap --ca-key-name=signing-ca --days=4017 # Example for use with key name, subject and lifetime ./create_signing_certificate.sh --key-name=ap --subject="/C=DE/ST=Berlin/L=Berlin/O=SOS/OU=IT/CN=ap" --days=4017
The shell script is executed with the following arguments:
--key-name
(required)- The basename of the key without extension.
--ca-key-name
- The basename of the CA key without extension. Default:
root-ca
- The basename of the CA key without extension. Default:
--subject
- The distinguished name that is used as the subject of the Signing Certificate. Default:
/C=DE/ST=Berlin/L=Berlin/O=SOS/OU=IT/CN=<key-name>
- The
CN
attribute should specify the user name. By default the key name specified with the--key-name
option is used.
- The distinguished name that is used as the subject of the Signing Certificate. Default:
--days
- The lifetime of the certificate is specified by the number of days. Default:
3652
- The lifetime of the certificate is specified by the number of days. Default: