Introduction

Installation, updates and upgrades are performed using the .tar.gz/.zip installer archives provided for the initial installation of newer releases.

For JS7 - Secure Operation the connections between JS7 JOC Cockpit, Controller and Agents are secured by SSL/TLS certificates.

• Users create a keystore that holds the private key and SSL/TLS certificate for the respective server. Users create a truststore that holds the Root CA Certificate and optionally Intermediate CA Certificate(s).
• The process of creating and updating keystores and truststores
• JS7 - Installation instructions apply.
• For environments with a larger number of JOC Cockpit instances the update, upgrade and patch processes can be automated in a number of ways:
  • Users can use their preferred tools such as Ansible®, Puppet®, Chef®.
  • Users can apply the JOC Cockpit Installer Certificate Management Script that is described in this article either standalone or in combination with such tools.

Security

Secure rollout of JS7 components is critical. It is therefore recommended that the solution described here is adjusted to suit specific security needs.

• Rollout of JS7 JOC Cockpit is considered critical as the software allows jobs to be executed on a larger number of servers.
  • Attention should be paid to the integrity of the sources for JS7 component downloads.
  • This includes intermediate devices on which JS7 software installers are stored in a user's environment.
  • One option is to run the JOC Cockpit Installer Script from sudo and to use the digest functionality that compares the script to a hash value stored with the sudoers file.
• The solution for updating, upgrading and patching the JS7 JOC Cockpit is based on shell scripting by design
  • to provide readability and to rely only on OS commands,
  • to prohibit the use of any 3rd-party components and additional dependencies that require code to be executed on the machines that run the JOC Cockpit.
• The JOC Cockpit Installer Script can be integrated in a number of ways:
  • by running one's own SSH script on top of the JOC Cockpit Installer Script,
  • by use of tools such as Ansible®, Puppet® that make use of an SSH Client,
  • by use of JS7 workflow automation as explained below.
    • It is recommended that a separate Standalone Controller and Agent are used for rollout purposes.
    • Access to the Controller and Agent for rollout should be securely managed.

JOC Cockpit Installer Script

The JOC Cockpit Installer Script is provided for download and can be used to automate updates, upgrades and patches of JS7 JOC Cockpits.

• The script is available for Linux, MacOS® and AIX® using bash, dash, ksh, and zsh shells.
• The script terminates with exit code 0 to signal success, with exit code 1 for command line argument errors and with exit code 2 for non-recoverable errors.
• The script is intended as a baseline example for customization by JS7 users and by SOS within the scope of professional services.
• Consider information from JS7 - JOC Cockpit Command Line Operation.

Download

Find the JOC Cockpit Installer Script for download from JS7 - Download.

Usage

Invoking the JOC Cockpit Installer Script without arguments displays the usage clause:

Certificate Management Script

The Certificate Management Script is provided for download and can be used to automate the creation of keystores and truststores.

• The script is available for Linux, MacOS® and AIX® using bash, dash, ksh, and zsh shells.
• The script makes use of OpenSSL and the Java Keytool available from a JRE/JDK.
• The script terminates with exit code 0 to signal success, with exit code 1 for command line argument errors and with other exit codes for non-recoverable errors.
• The script is intended as a baseline example for customization by JS7 users and by SOS within the scope of professional services.

Download

Find the Certificate Management Script for download from JS7 - Download.

Usage

Invoking the Certificate Management Script without arguments displays the usage clause:

Usage: js7_create_certificate_store.sh [Options] [Switches]

  Options:
    --keystore=<file>                     | required: path to keystore file in PKCS12 format
    --truststore=<file>                   | optional: path to truststore file in PKCS12 format
    --key=<private-key-file>              | required: path to private key file in .pem format
    --cert=<cert-file>               

Usage: js7_install_joc.sh [Options] [Switches]

  Options:
    --setup-dir=<directory>     | required: directorypath to whichcertificate thefile JOCin Cockpit installer should be extracted.pem format
    --setup-response=<file>alias=<alias-name>         | required: setup response file used to install JOC Cockpit,| defaultrequired: joc_install.xml
    --release=<release-number>  | optional: release number such as 2.2.3 for download if --tarball is not used
    --tarball=<tar-gz-archive>  | optional: the path to a .tar.gz archive that holds the JOC Cockpit tarball,
                                |           if not specified the JOC Cockpit tarball is downloaded from the SOS web site
    --home=<directory>          | optional: home directory of JOC Cockpit if --patch or --backup-dir is used
    --patch=<issue-key>         | optional: identifies a patch for an existing JOC Cockpit installation
    --license-key=<key-file>    | optional: specifies the path to a license key file that should be installed
    --license-bin=<binary-file> | optional: specifies the path to the js7-license.jar binary file for licensed code to be installed
                                |           if not specified the file is downloaded from the SOS web site
    --backup-dir=<directory>    | optional: backup directory for existing JOC Cockpit home directory
    --log-dir=<directory>       | optional: log directory for log output of this script
    --http-port=<http(s)-port>  | optional: specifies the http/https port the JOC Cockpit is operated for, default: 4446
                                            port can be prefixed by network interface, e.g. joc.example.com:4446
    --ini=<ini-file[,ini-file]> | optional: one or more Jetty config files http.ini, https.ini, ssl.ini etc. will be copied to <home>/jetty_base/start.d/
    --keystore-file=<path>      | optional: path to a PKCS12 keystore file that is copied to <data>/resources/joc/<keystore-file>
    --truststore-file=<path>    | optional: path to a PKCS12 truststore file that is copied to <data>/resourdes/joc/<truststore-file>
    --exec-start=<command>      | optional: specifies the command to start JOC Cockpit, e.g. 'sudo systemctl start joc'
    --exec-stop=<command>       | optional: specifies the command to stop the JOC Cockpit, e.g. 'sudo systemctl stop joc'
    --return-values=<file>      | optional: specifies a file that receives return values such as the path to a log file
  Switches:
    -h | --help                 | displays usage
    -u | --user                 | install configuration directories as current user, other directories as root using sudo
    -E | --preserve-env         | preserve environment variables when switching to root using sudo -E
    --show-logs                 | shows log output of the script
    --make-dirs                 | creates the specified directories if they do not exist
    --restart                   | stops a running JOC Cockpit and starts JOC Cockpit after installation
    --kill                      | kills a running JOC Cockpit if used with the --restart switch 

Explanation:

• Options
  • --setup-dir
    • Specifies the directory in which the installer for the JOC Cockpit should be extracted. This is not the JOC Cockpit installation directory but the directory that holds installer files.
  • --setup-response
    
    • The JOC Cockpit installer is used with the joc_install.xml response file. This file is available after extraction of the installer tarball and specifies options for installation of the JOC Cockpit. The file is applied when invoking the installer by ./setup.sh -u joc_install.xml, see JS7 - JOC Cockpit - Headless Installation on Linux and Windows.
    • Users should keep their copy of the response file and specify the path with this command line option. Response files can be re-used within the same minor release of the JOC Cockpit, for example when updating from release 2.3.1 to 2.2.4. When updating, for example, from release 2.2.x to 2.3.x it is recommended a check is carride out from the installer tarball if a newer version of the file is available.
    • Users should note that the response file can hold references to a license file and to a JDBC Driver .jar file. The JOC Cockpit setup is executed from the directories specified with the --setup-dir option. Paths can be used relative to this directory.
  • --release
    • Specifies a release number such as 2.3.1 for download from the SOS web site if the --tarball option is not used.
  • --tarball
    • Optionally specifies the path to a .tar.gz file that holds the JOC Cockpit installation files. If this option is not used the installer tarball will be downloaded from the SOS web site for the release indicated with the --release option.
    • Download is performed with curl which takes account of http_proxy and https_proxy environment variables and the relevant settings from a .curlrc file.
  • --home
    • Specifies the directory in which the JOC Cockpit should be installed.
  • --patch
    • A patch is identified by the release number to which it is applied which is specified with the --release option and by
      • the JOC Cockpit security level: low, medium, high,
      • a sequential number such as patch-1, patch-2.
      • A patch is specified as --patch=low.patch-1, --patch=low.patch-2, --patch=medium.patch-1 etc.
    • For JOC Cockpit patches are consolidated, i.e. patch-2 includes any patches of patch-1.
    • Patches are downloaded from the SOS web site if the --tarball option is not used.
    • Patches are added to the JOC Cockpit's JETTY_BASE/webapps/joc/WEB-INF/classes directory. When updating JOC Cockpit later on then the classes sub-directory will be emptied.
    • If a backup directory is specified then a JOC Cockpit's existing installation directory will be added to a .tar.gz file in this directory.
  • --license-key
    • Optionally the path to a license key file is specified. Customers with a Commercial License receive the license key file from SOS in .pem or .crt format.
    • For details see JS7 - How to apply a JS7 License Key.
    • This option is an alternative to specifying the license key file with the joc_install.xml response file, see --setup-response option.
  • --license-bin
    • Optionally the path to the js7-license.jar binary file is specified that includes code that is available for use with a Commercial License only, see JS7 - How to apply a JS7 License Key.
    • Should this argument be omitted and a license key file be specified with the --license-key option then the binary file is downloaded from the SOS Web Site, see JS7 - Download.
    • This option is an alternative to specifying the license key file with the joc_install.xml response file, see --setup-response option. If the response files specifies a license key then the binary file for licensed code is automatically installed.
  • --backup-dir
    • If a backup directory is specified then an existing JOC Cockpit's installation directory will be added to a .tar.gz file in this directory.
    • File names are created according to the pattern: backup_js7_joc.<hostname>.<release>.<yyyy>-<MM>-<dd>T<hh>-<mm>-<ss>.tar.gz
    • For example: backup_js7_joc.centostest_primary.2.3.1.2022-03-19T20-50-45.tar.gz
  • --log-dir
    • If a log directory is specified then the installer script logs information about processing steps to a log file in this directory.
    • File names are created like this: install_js7_joc.<hostname>.<yyyy>-<MM>-<dd>T<hh>-<mm>-<ss>.log
    • For example: install_js7_joc.centostest_primary.2022-03-19T20-50-45.log
  • --http-port
    • Optionally specifies the HTTP/HTTPS port that the JOC Cockpit is operated for. This argument takes precedence over the port setting in the joc_install.xml response file.
    • Only one of the protocols HTTP or HTTPS can be used as it undermines security to operate JOC Cockpit for both protocols at the same time.
    • The port can be prefixed by the network interface, for example joc.example.com:4446.
    • Use of HTTPS connections requires additional settings, see --ini , --keystore-file and --truststore-file options.
    • When used with the --restart switch, the HTTP/HTTPS port is used to determine if JOC Cockpit is running.
  • --ini
    • Specifies one or more *.ini files that include settings for the Jetty Servlet Container, for example http.ini, https.ini, ssl.ini. The files will be copied to the JOC Cockpit installation directory. For use with HTTPS connections the following settings in the ssl.ini file have to be adjusted:
      • jetty.sslContext.keyStorePath
      • jetty.sslContext.keyStorePassword
      • jetty.sslContext.keyManagerPassword
      • jetty.sslContext.trustStorePath
      • jetty.sslContext.trustStorePassword
    • The option takes a number of files as arguments that are separated by comma, for example: --ini="/js7-deployment/ssl.ini,/js7-deployement/https.ini".
  • --keystore-file
    • Specifies the path to a PKCS12 keystore file that holds the private key and certificate for HTTPS connections to JOC Cockpit.
    • Users are free to specify any file name, typically the name https-keystore.p12 is used. The keystore file will be copied to the <home>/jetty_base/resources/joc directory.
    • If a keystore file is made available then the JOC Cockpit's <home>/jetty_base/start.d/ssl.ini file has to hold a reference to the keystore location and optionally the keystore password. It is therefore recommended to use the --ini option to deploy an individual ssl.ini file. The following settings are automatically updated in the ssl.ini file:
      • jetty.ssl.host: optionally specifies the network interface that is available from the --http-port option provided that the port is prefixed with the network interface, for example joc.example.com:4446.
      • jetty.ssl.port: specifies the HTTPS port that is automatically updated from the --http-port option.
      • jetty.sslContext.keyStorePath: specifies the path to the keystore relative to the <home>/jetty_base/resources/joc directory.
    • Further settings in the ssl.ini file such as the keystore password have to be deployed from a copy of the file using the --ini option.
    • Assigning a keystore for HTTPS connections disables HTTP access and enables HTTPS access only to JOC Cockpit. The same port is alternatively used for HTTP and HTTPS connections.
  • --truststore-file
    • Specifies the path to a PKCS12 truststore file that holds the certificate(s) for HTTPS connections from JOC Cockpit to a Controller instance, LDAP server etc.
    • Users are free to specify any file name, typically the name https-truststore.p12 is used. The truststore file will be copied to the <home>/jetty_base/resources/joc directory.
    • If a truststore file is made available then the JOC Cockpit's <home>/jetty_base/start.d/ssl.ini file has to hold a reference to the truststore location and optionally the truststore password. It is therefore recommended to use the --ini option to deploy an individual ssl.ini file. The following settings are automatically updated in the ssl.ini file:
      • jetty.sslContext.trustStorePath: specifies the path to the truststore relative to the <home>/jetty_base/resources/joc directory.
    • Further settings in the ssl.ini file such as the truststore password have to be deployed from a copy of the file using the --ini option.
  • --exec-start
    • This option can be used if the JOC Cockpit has been started after installation from an individual command. For example, when using systemd then the option --exec-start="sudo systemctl start joc" will start the JOC Cockpit provided that the joc.service file is configured for systemd.
    • For systemd service files see JS7 - systemd Service Files for automated Startup and Shutdown with Unix Systems.
    • This option is an alternative for use of the -restart switch that starts the JOC Cockpit from its Start Script. If specified this option overrules the --restart switch.
  • --exec-stop
    • This option can be used if the JOC Cockpit has been stopped before installation from an individual command. For example, when using systemd then the option --exec-stop="sudo systemctl stop joc" will stop the JOC Cockpit provided that the joc.service file is configured for systemd.
    • For systemd service files see the JS7 - systemd Service Files for automated Startup and Shutdown with Unix Systems aticle.
    • This option is an alternative to use of the -restart switch that stops the JOC Cockpit from its Start Script. If specified this option overrules the --restart switch.
  • --return-values
    • Optionally specifies the path to a file which return values will be added to in the format <name>=<key>. For example:
      • log_file=install_js7_joc.centostest_primary.2022-03-20T04-54-31.log
      • backup_file=backup_js7_joc.centostest_primary.2.3.1.2022-03-20T04-54-31.tar.gz
    • An existing file will be overwritten. It is recommended that a unique file name such as /tmp/return.$$.$RANDOM.properties is used.
    • A value from the file can be retrieved like this:
      • backup=$(cat /tmp/return.$$.$RANDOM.properties | grep "backup_file" | cut -d'=' -f2)
• Switches
  • -h | --help
    • Displays usage.
  • -u | --user
    • Installs the JOC Cockpit configuration directory for the current user account, the installation directory is created by the root account using sudo. This switch corresponds to use of ./setup.sh -u joc_install.xml, see the JS7 - JOC Cockpit - Headless Installation on Linux and Windows for more information.
  • -E | --preserve-env
    • When installing for the current user account using the -u switch then environment variables are preserved when switching to the root account using sudo -E. This switch corresponds to use of ./setup.sh -u -E joc_install.xml.
  • --show-logs
    • Displays the log output created by the script.
  • --make-dirs
    • If directories are missing that are indicated with the --home, --backup-dir or --log-dir options then they will be created.
  • --restart
    • Stops a running JOC Cockpit before installation and starts the JOC Cockpit after installation using the JOC Cockpit's Start Script. This switch can be used with the --kill switch to control the way how JOC Cockpit is terminated. This switch is ignored if the --exec-start and --exec-stop options are used.
  • --kill
    • Kills a running JOC Cockpit if used with the --restart switch. This includes killing child processes of running tasks.
• Exit Codes
  • 1: argument errors
  • 2: non-recoverable errors
  • 3: this exit code is returned when used with the --restart switch and if it cannot be identified if a JOC Cockpit instance is running
  • 4: this exit code is returned if no --tarball option is used and download of the tarball reports errors
  • 5: this exit code is returned when used with the --restart switch and if the JOC Cockpit instance cannot be started
  • 6: this exit code is returned when used with the --restart switch and if the JOC Cockpit instance cannot be stopped
  • 7: this exit code indicates that the JOC Cockpit installation has failed
  • 8: this exit code indicates failure of the JOC Cockpit installation from logs

Examples

The following examples represent typical use cases. Users should consider to specify current releases, see JS7 - Download.

Install or Update from Download

./js7_install_joc.sh \
    --setup-dir=/home/sos/joc.setup \
    --setup-response=/home/sos/joc.response/joc_install.xml \
    --release=2.3.1 \
    --make-dirs

# downloads the JOC Cockpit release indicated and extracts the installer tarball to the specified JOC Cockpit setup directory 
# the setup directory is created if it does not exist and the indicated response file for setup options is used

Install or Update from Download with Commercial License

./js7_install_joc.sh \
    --setup-dir=/home/sos/joc.setup \
    --setup-response=/home/sos/joc.response/joc_install.xml \
    --release=2.3.1 \
    --license-key=/home/sos/example.pem \
    --make-dirs

# downloads the JOC Cockpit release indicated and extracts the installer tarball to the specified JOC Cockpit setup directory 
# the setup directory is created if it does not exist and the indicated response file for setup options is used
# installs the license key file and downloads the binary file for licensed code to enable cluster operations

Install or Update from Tarball

./js7_install_joc.sh \
    --setup-dir=/home/sos/joc.setup \
    --setup-response=/home/sos/joc.response/joc_install.xml \
    --tarball=/mnt/releases/js7/js7_joc_linux.2.3.1.tar.gz

# extracts the tarball indicated to the specified JOC Cockpit setup directory

Install or Update from Tarball with Commercial License

./js7_install_joc.sh \
    --setup-dir=/home/sos/joc.setup \
    --setup-response=/home/sos/joc.response/joc_install.xml \
    --tarball=/mnt/releases/js7/js7_joc_linux.2.3.1.tar.gz \
    --license-key=/home/sos/example.pem \
    --license-bin=/mnt/releases/js7/js7-license.jar

# extracts the tarball indicated to the specified JOC Cockpit setup directory
# installs the license key file and binary file for licensed code to enable cluster operations

Install or Update and Stop/Start using systemd

./js7_install_joc.sh \
    --setup-dir=/home/sos/joc.setup \
    --setup-response=/home/sos/joc.response/joc_install.xml \
    --tarball=/mnt/releases/js7/js7_joc_linux.2.3.1.tar.gz \
    --exec-start="sudo systemctl start js7_joc" \
    --exec-stop="sudo systemctl stop js7_joc"

# extracts the tarball indicated to the specified JOC Cockpit setup directory 
# the JOC Cockpit is stopped and started using systemd commands

Install or Update and Restart

./js7_install_joc.sh \
    --setup-dir=/home/sos/joc.setup \
    --setup-response=/home/sos/joc.response/joc_install.xml \
    --tarball=/mnt/releases/js7/js7_joc_linux.2.3.1.tar.gz \
    --restart

# extracts the tarball indicated to the specified JOC Cockpit setup directory 
# the JOC Cockpit is stopped and started from its own instance start script

Install or Update with Return Values

retval=/tmp/js7_install_joc.$$.tmp

./js7_install_joc.sh \
    --setup-dir=/home/sos/joc.setup \
    --setup-response=/home/sos/joc.response/joc_install.xml \
    --tarball=/mnt/releases/js7/js7_joc_linux.2.3.1.tar.gz \
    --backup-dir=/tmp/backups \
    --log-dir=/tmp/logs \
    --return-values=$retval \
    --restart

log_file=$(cat $retval | grep "log_file" | cut -d'=' -f2)
backup_file=$(cat $retval | grep "backup_file" | cut -d'=' -f2)

# extracts the tarball indicated to the specified JOC Cockpit setup directory, creates a log file and a backup file
# return values include the path to the log file and to the backup file

Install or Update with Fallback

retval=/tmp/js7_install_joc.$$.tmp

./js7_install_joc.sh \
    --setup-dir=/home/sos/joc.setup \
    --setup-response=/home/sos/joc.response/joc_install.xml \
    --tarball=/mnt/releases/js7/js7_joc_linux.2.3.1.tar.gz \
    --backup-dir=/tmp/backups \
    --log-dir=/tmp/logs \
    --return-values=$retval \
    --restart \
    --show-logs \
    --make-dirs \
 || ( backup=$(cat $retval | grep "backup_file" | cut -d'=' -f2) \
      && ( test -e "$backup" ) && \
      ./js7_install_joc.sh \
          --setup-dir=/home/sos/joc.setup \
          --setup-response=/home/sos/joc.response/joc_install.xml \
          --tarball=$backup \
          --log-dir=/tmp/logs \
          --restart \
          --show-logs )

log_file=$(cat $retval | grep "log_file" | cut -d'=' -f2)
backup_file=$(cat $retval | grep "backup_file" | cut -d'=' -f2)

# extracts the tarball indicated to the specified JOC Cockpit setup directory, creates a backup file and a log file and restarts JOC Cockpit
# should installation fail then the installation from the backup file will be reverted to

Install or Update and Apply Certificates

./js7_install_joc.sh \
    --setup-dir=/home/sos/joc.setup \
    --setup-response=/home/sos/joc.response/joc_install.xml \
    --tarball=/mnt/releases/js7/js7_joc_linux.2.3.1.tar.gz \
    --ini="./joc.config/http.ini,./joc.config/https.ini,./joc.config/ssl.ini" \
    --http-port=4446 \
    --keystore-file=./joc.config/https-keystore.p12 \
    --truststore-file=./joc.config/https-truststore.p12 \
    --make-dirs \
    --user \
    --preserve-env

# extracts the tarball indicated to the specified JOC Cockpit setup directory
# deploys Jetty SSL configuration files that hold references to keystore and truststore
# deploys keystore and truststore files

Patch from Download

./js7_install_joc.sh \
    --home=/home/sos/joc \
    --release=2.3.1 \
    --patch=low.patch-1

# downloads the patch indicated and extracts the tarball to the specified JOC Cockpit home directory
# the patch is stored in the JOC Cockpit's jetty_base/webapps/joc/WEB-INF/classes sub-directory

Patch from Tarball

./js7_install_joc.sh \
    --home=/home/sos/joc \
    --tarball=/mnt/releases/js7/js7_joc_linux.2.3.1.low.patch-1.tar.gz \
    --patch=low.patch-1

# extracts the patch tarball indicated to the specified JOC Cockpit home directory
# the patch is stored to the JOC Cockpit's jetty_base/webapps/joc/WEB-INF/classes sub-directory

Automation

The JOC Cockpit Installer Script can be executed from a job for automated updating and upgrading of JS7 JOC Cockpit instances.

The steps for automation are similar to updating and upgrading JS7 Agents. You will find instructions for setting up workflow automation from the JS7 - Automated Update of Agent article.

Further Resources

alias name for keystore entry
    --password=<password>                 | required: password for certificate store, optionally for private key
    --ca-cert=<ca-cert-bundle-file>       | optional: path to CA Certificate Bundle file in .pem format
    --ca-root=<ca-root-file>              | optional: path to Root CA Certificate file in .pem format
    --ca-intermediate=<ca-file[,ca-file]> | optional: paths to Intermediate CA Certificate files in .pem format
    --backup-dir=<directory>              | optional: backup directory for existing certificate stores
    --log-dir=<directory>                 | optional: log directory for log output of this script
  Switches:
    -h | --help                           | displays usage
    --chain                               | add certificate chain to keystore
    --show-logs                           | shows log output of the script
    --make-dirs                           | creates the specified directories if they do not exist

Explanation:

• Options
  • --keystore
    • Specifies the path to a PKCS12 keystore file that should be created. The keystore holds the private key and server certificate for HTTPS connections to JS7 products.
    • Users are free to specify any file name, typically the name https-keystore.p12 is used.
    • Further settings in JS7 configuration files such as the keystore location and password have to be considered.
  • --truststore
    • Specifies the path to a PKCS12 truststore file that should be created. The truststore holds the certificate(s) for HTTPS connections from JS7 products.
    • Users are free to specify any file name, typically the name https-truststore.p12 is used.
    • Further settings in JS7 configuration files such as the truststore location and password have to be considered.
  • --key
    • Specifies the path to the file that holds the private key that should be added to the keystore.
    • This argument is required should a keystore be created, see --keystore.
  • --cert
    • Specifies the path to the file that holds the server/client authentication certificate that should be added to the keystore.
    • This argument is required should a keystore be created, see --keystore.
  • --alias
    • Specifies the alias name of the entry in the keystore that holds the private key and certificate.
    • This argument is required should a keystore be created, see --keystore.
  • --password
    • Specifies the password that protects the keystore and truststore. If the private key is encrypted then the password is used to read the key. Private key passphrase and keystore password must match.
    • Passwords for certificate stores are not intended to improve security but to prevent users from shooting themselves in their foot. For a keystore the password protects read and write access, for a truststore the password protects write access.
    • This argument is required should a keystore or truststore be created, see --keystore, --truststore.
  • --ca-cert
    • Specifies the path to a CA Certificate Bundle file that holds the Intermediate CA Certificate(s) and Root CA Certificate in the indicated sequence.
    • This argument is required should a keystore be created and the --chain switch be used. In addition this argument is required should a truststore be created and no Root CA Certificate be specified, see --ca-root.
  • --ca-root
    • Specifies the path to a Root CA Certificate file.
    • This argument is required if no CA Certificate Bundle file is specified, see --ca-cert, and should a keystore be created with the --chain argument. In addition this argument is required should a truststore be created using the --truststore option and no CA Certificate Bundle file is specified, see --ca-cert option.
  • --ca-intermediate
    • Specifies the path to one or more Intermediate CA Certificate files.
    • If more than one file is specified then file names have to be separated by comma, for example --ca-intermediate="./certs/intermediate-ca-1.crt,./certs/intermediate-ca-2.crt".
    • This argument is required if no CA Certificate Bundle file is specified, see --ca-cert, and should a keystore be created using the --chain switch.
  • --backup-dir
    • If a backup directory is specified then an existing keystore and truststore will be added to a .tar.gz file in this directory.
    • File names are created according to the pattern: backup_js7_<keystore|truststore>.<hostname>.<yyyy>-<MM>-<dd>T<hh>-<mm>-<ss>.tar.gz
    • For example: backup_js7_keystore.centostest_primary.2022-03-19T20-50-45.tar.gz
  • --log-dir
    • If a log directory is specified then the installer script logs information about processing steps to a log file in this directory.
    • File names are created like this: certificate_store_js7.<hostname>.<yyyy>-<MM>-<dd>T<hh>-<mm>-<ss>.log
    • For example: certificate_store_js7.centostest_primary.2022-03-19T20-50-45.log
• Switches
  • -h | --help
    • Displays usage.
  • --chain
    • Adds the certificate chain to the keystore if the --keystore option is used. In most situations this is not required as the certificate chain is made available with the truststore. The certificate chain will be created from the CA Certificate Bundle file, see --ca-cert, or from individual CA Certificates, see --ca-root, --ca-intermediate.
  • --show-logs
    • Displays the log output created by the script.
  • --make-dirs
    • If directories are missing that are indicated with the --keystore, --truststore, --backup-dir or --log-dir options then they will be created.
• Exit Codes
  • 1: argument errors, OpenSSL errors
  • 2: this exit code is returned in case of keystore/truststore verification errors.

Examples

The following examples represent typical use cases. Users should consider to specify current releases, see JS7 - Download.

Creating a Keystore and Truststore (recommended)

./js7_create_certificate_store.sh \
    --keystore=https-keystore.p12 \
    --truststore=https-truststore.p12 \
    --key=./private/centostest-primary.key \
    --cert=./certs/centostest-primary.crt \
    --alias=centostest-primary \
    --password=jobscheduler \
    --ca-root=./certs/root-ca.crt

# creates a keystore from the private key and certificate
# creates a truststore from the Root CA Certificate
# the keystore and truststore will be protected with the given password

Creating a Keystore

./js7_create_certificate_store.sh \
    --keystore=https-keystore.p12 \
    --key=./private/centostest-primary.key \
    --cert=./certs/centostest-primary.crt \
    --alias=centostest-primary \
    --password=jobscheduler

# creates a keystore from the private key and certificate
# the keystore will be protected with the given password

Creating a Keystore with a Certificate Chain

./js7_create_certificate_store.sh \
    --keystore=https-keystore.p12 \
    --key=./private/centostest-primary.key \
    --cert=./certs/centostest-primary.crt \
    --alias=centostest-primary \
    --password=jobscheduler \
    --ca-cert=./certs/ca-bundle.crt \
    --chain

# creates a keystore from the private key and certificate
# adds the certificate chain from the CA Certificate Bundle to the keystore
# the keystore will be protected with the given password

Creating a Truststore from a CA Certificate Bundle

./js7_create_certificate_store.sh \
    --truststore=https-truststore.p12 \
    --password=jobscheduler \
    --ca-cert=./certs/ca-bundle.crt
 
# creates a truststore from the CA Certificate Bundle
# the truststore will be protected with the given password

Creating a Truststore from a number of CA Certificates

./js7_create_certificate_store.sh \
    --truststore=https-truststore.p12 \
    --password=jobscheduler \
    --ca-root=./certs/root-ca.crt \
    --ca-intermediate=./certs/sos.intermediate-ca-1.crt,./certs/sos.intermediate-ca-2.crt

# creates a truststore from the Intermediate CA Certificates and the Root CA Certficate
# the truststore will be protected with the given password

Creating a Keystore using Log Files and Backups

./js7_create_certificate_store.sh \
    --keystore=https-keystore.p12 \
    --key=./private/centostest-primary.key \
    --cert=./certs/centostest-primary.crt \
    --alias=centostest-primary \
    --password=jobscheduler \
    --log-dir=./logs \
    --backup-dir=./backup

# creates a keystore from the private key and certificate
# creates a log file in the indicated directory
# creates a backup file of the keystore in the indicated directory

Automation

The Certificate Management Script can be executed from a job for automated creation of keystores and truststores.

Further Resources

• JS7 - Automated Installation and Update
• JS7 - Automated Update of Controller
• JS7 - Automated Update of Agent