Certificate management

Certificate management#

This section contains additional instructions/guides related to certificate management in Scrutinizer.

On this page:

Certificate rotation and regeneration
Certificate rotation and regeneration
Wildcard certificates
Wildcard certificates
Full chain certificates
Full chain certificates
Distributed cluster certificates
Distributed cluster certificates

For further information or assistance with these functions, contact Plixer Technical Support.

Certificate rotation and regeneration#

The following certificate rotation utilities can be run to re-issue certificates and keys to address database communication issues:

Operations and syntax

Regenerate all certificates on all nodes, including any ML engines, with an optional expiration of the number of DAYS specified. If the --reset flag is included, the CA and web server certificates on the primary reporter will also be regenerated.

scrut_util --rotatecerts [--days <DAYS>] [--reset] [--verbose]

Regenerate the web server certificate and key with an optional expiration of the number of DAYS specified. The --csr option can be used to create a certificate signing request (CSR) using the current private key and user-configured subject in /home/plixer/scrutinizer/files/scrutinizer.csr instead.

scrut_util --nginxcerts [--days <DAYS>] [--csr] [--verbose]

Generate a new self-signed certificate (/etc/pki/tls/certs/ca.crt), private key (/etc/pki/tls/private/ca.key), and CSR (/etc/pki/tls/private/ca.csr) with default details; must be run from the scrut_util prompt.

SCRUTINIZER> set ssl on

To run the operation from the shell with user-provided details, use:

scrut_util --set ssl --toggle [on|off] --port <TCP_PORT> --country <COUNTRY> --state <STATE/PROVINCE> --city <CITY/LOCALITY> --org <ORG_NAME> --email <CONTACT_EMAIL> --name <COMMON_NAME> --keysize [1024|2048|4096]

Regenerate TLS certificates and private keys on the Plixer ML Engine node with the specified IP_ADDRESS with an optional expiration of the number of DAYS specified. If the --install option is included, setup.sh --reload-certs will not be executed on the node.

scrut_util --mlcerts --ip <IP_ADDRESS> [--days <DAYS>] [--install] [--verbose]

Regenerate all certificates used for PostgreSQL connections on all nodes with an optional expiration of the number of DAYS specified. If the --reset option is included, the CA certificate on the primary reporter will also be regenerated.

scrut_util --pgcerts [--days <DAYS>] [--reset] [--verbose]

Note

  • The optional DAYS flag can be used to set an expiration date for the certificate(s) regenerated by each utility. Once they expire, the same command can be run again to re-issue certificates with new expiry dates.

  • With the exception of set ssl on, the above commands cannot be run from the SCRUTINIZER> prompt.

Wildcard certificates#

If a signed wildcard certificate and key were generated with a passphrase, the passphrase must be removed from the private key to allow Scrutinizer to use the pair.

  1. Copy the private key file (*.key) to /etc/pki/tls/private/.

  2. Re-generate the key without a passphrase (replace ORIGINAL with the filename of the key):

    openssl rsa -in /etc/pki/tls/private/ORIGINAL.key -out /etc/pki/tls/private/new.key

  3. When prompted, enter the passphrase used for the original key.

This will create a new, unencrypted key named new.key in /etc/pki/tls/private/, which must be renamed to ca.key. If the key pair was originally created without a passphrase, it need only be renamed after being copied into the correct directory.

Full chain certificates#

A full chain certificate or chain of trust can be created as follows:

  1. Create the file ca_chain.crt under /etc/pki/tls/CA/.

  2. Copy the contents of the intermediate CA .crt file into ca_chain.crt.

  3. Copy the contents of the root CA .crt file into ca_chain.crt (after the intermediate CA).

  4. Set ssl_certificate setting in /etc/nginx/webapp.d/inc/ssl.conf:

    ssl_certificate /etc/pkl/tls/CA/ca_chain.crt

  5. Restart the web server:

    sudo systemctl restart plixer_webapp

After the restart, the full chain certificate will be in use.

Distributed cluster certificates#

To generate CSRs and install the signed keys for a distributed cluster, run the following scripts:

Note

  • These scripts should be run from the distributed cluster’s primary reporter as the plixer user and rely on Scrutinizer’s default SSH connectivity.

  • scrut_util --rotatecerts --reset (see above) can be used if either of these scripts causes unexpected issues or DB connection errors. However, any existing signed certificates will be lost.

/home/plixer/scrutinizer/files/generate_requests.sh

Generates certificate signing requests (CSRs) for all TLS keys in a distributed cluster

CSRs are saved to subdirectories in /tmp/request with webapp_plixer_client being the signing request for the primary reporter’s web server.

 
/home/plixer/scrutinizer/files/install_certs.sh

Installs signed TLS certificates to all nodes in a distributed cluster

.cer files should be saved to /tmp/signed following the path and filename conventions used by generate_requests.sh for the signing requests. The Certificate Authority’s root certificate should be saved as ca.cer.
Contents