Introduction

• When If JOC Cockpit is installed for a the high security level then deployment of scheduling objects forces workflows requires external signing.
  • For the low security level the private key Private Key of the root account available with the the JS7 database - Database is used for all users.
  • For the medium security level the user's individual private key Private Key available with the JS7 database is used.
  • For the high security level signing is performed outside of JOC Cockpit. No Private Keys are stored with JOC Cockpit and the JS7 database.
• For details see JS7 - Security Architecture.

Users have a choice how to perform signing and deployment of workflows:

• For manual signing and deployment see
  • JS7 - Signing Workflows with X.509 Certificates from JOC Cockpit
• For automated signing and deployment see
  • JS7 - Signing Workflows with X.509 Certificates using Unix Shell Script
  • JS7 - Signing Workflows with X.509 Certificates using PowerShell Script
  • JS7 - Signing Workflows with X.509 Certificates using PowerShell CI CD pipeline

Prerequisites

Required: User Signing Certificate

Each user Users with the permission to deploy has workflows have to add their X.509 signing certificate to JOC CockpitSigning Certificate to their profile like this:

Image Modified

Optional: Root CA Certificate

In addition, the X.509 certificate of the Root CA Certificate which signed the user's signing certificate can be added to JOC Cockpit. There is a single Root CA certificate Certificate for all user profiles.

Image Modified

• Any user signing certificates have to be rolled out to available with the Controller instances and Agents. Certificates are stored in the the config/private/trusted-x509-keys folder sub-directory of Controller and Agent installations.
• If a Root CA certificate Certificate is present in JOC Cockpit , then it is sufficient to add the Root CA certificate Certificate to the the config/private/trusted-x509-keys folder of  sub-directory of Controller and Agent installations.
  • No further user signing certificates have to be added to the Controller instances or Agents as long as the user signing certificates is are created by the given same Root CA.
  • This mechanism implies that any user signing certificate signed by the same Root CA certificate Certificate will be accepted.
  • Users who do not wish to use this implicit mechanism should not add the Root CA certificate Certificate to the Controller instances and Agents but should only add individual user signing certificates only.

Deployment Process Overview

• The user has Users have to export the desired configuration of scheduling objects with the workflows using the Export operation available from the JOC Cockpit's Configuration view.

  • Other deployable objects such as File Order Sources, Job Resources, Notice Boards, Resource Locks etc. do not require signing.
  • Releasable objects that are not digitally signed include Calendars, Schedules, Script Includes, Job Templates etc.
• Deployment tasks include:
  

  • Exporting scheduling objects with workflows using the checkbox "for Signing" checked to an archive file (.zip). to a .tar.gz/.zip export archive file.

  • Extracting the export archive fileUnpacking the exported archive.
    • The export archive contains file includes a meta_inf file and the configurationsrelated folders and files for workflows.
  • Signing the extracted workflow files.
  • Storing the base64 encoded signature file for each workflow file in configuration files of scheduling objects and storing the signature - base64 encoded - in a file in the same folder.
  • Note that each signature file has to use the same name as the original configuration file of the scheduling object workflow with an additional filename file extension.
    • for X.509 RSA/ECDSA signatures signature files use the filename extension ".pem" or "file extension .sig" respectively.
    • for PGP signatures PGP signature files use the default filename file extension " .asc".
  • Packing the archive once again to add the signature files and make sure Adding signature files to a .tar.gz/.zip import archive file. This includes that the meta_inf file is still available with in the root top-level folder of the import archive file.
  • Uploading the import archive file using the Import And and Deploy button .

Example

Export

...

Signing

It is recommended that the signing procedure is performed on a secure device. It is essential that the signing process is performed in a secure manner outside of the server running the JOC Cockpit.

...

Image Removed

Signing the configuration

For this example, we use OpenSSL to sign the configuration file:

openssl dgst -sha256 -sign c:\tmp\sos.private-ec-key.pem -out c:\tmp\example-wf.workflow.json.sha256 c:\tmp\example-wf.workflow.json

...

• the signer algorithm

...

• the private key file to sign the content of the original configuration file

...

• the path to the output file
• the file containing the binary representation of the signature

...

openssl base64 -in c:\tmp\example-wf.workflow.json.sha256 -out c:\tmp\example-wf.workflow.json.pem

• base64
  • OpenSSL switch to encode base64
• -in c:\tmp\example-wf.workflow.json.sha256
  • the newly created binary signature file
• -out c:\tmp\example-wf.workflow.json.pem
  • the base64 encoded text signature file according to the JOC Cockpit deployment naming convention

The procedure for adding scheduling object files and signatures to an archive includes the following steps:

...

• The exported archive contains the meta_inf file. This file does not have to be signed. Make sure the file is present in the root folder of the target archive.

• • available from the JOC Cockpit's Configuration view..

Resources

• JS7 - Deployment of Workflows for High Security Level

...

Image Removed

...