Introduction

...

• For the low security level the private key of the root account available with the JS7 - Database is used for all users.
• For the medium security level the user's individual 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.

...

The JS7 allows to operate JOC Cockpit in one of the Security Levels low, medium, high, for details see JS7 - Security Architecture.

...

Prerequisites

Required: User Signing Certificate

...

• low: workflows are digitally signed from a single Private Key used by all user accounts in JOC Cockpit. The Private Key is stored in the JS7 database.
• medium: workflows are digitally signed from Private Keys per user accounts in JOC Cockpit. The Private Key is stored in the JS7 database.
• high: workflows have to be digitally signed outside of JOC Cockpit. Users export workflows from the JS7 inventory

Image Removed

Optional: Root CA Certificate

...

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

Deployment Process Overview

• Users have to export 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 workflows using the checkbox for Signing to a .tar.gz/.zip export archive file.
• Extracting the export archive file.
  • The export archive file includes a meta_inf file and related folders and files for workflows.
• Signing the extracted workflow files.
• Storing the base64 encoded signature file for each workflow file in same folder.
• Note that each signature file has to use the same name as the original workflow with an additional file extension.
  • for X.509 RSA/ECDSA signature files use the file extension .sig.
  • for PGP signature files use the file extension .asc.
• Adding signature files to a .tar.gz/.zip import archive file. This includes that the meta_inf file is available in the top-level folder of the import archive file.
Uploading the import archive file using the Import and Deploy button available from the JOC Cockpit's Configuration view..

For an overview of the signing process see JS7 - Deployment of Workflows for High Security Level.

The following example is provided for manual signing and deployment of workflows.

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

Example for Deployment Process

Export

• Click Export in the context menu of a folder or use the Export button in the right upper corner of the Configuration view:
  
  Image Modified
  
  
• In the Export popup window check the checkbox for Signing:
  
  Image Modified
  
  
• Select the workflows to deploy.

Signing

The following steps are explained for manual signing. For automated signing see JS7 - Signing Workflows for High Security Level.

...

Extract the export archive file and preserve the folder structure of included workflow files:

Image Modified

Signing Workflow Files

This example makes use of OpenSSL to sign a workflow file in two steps:

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

• -sha256
  • the The signer algorithm
• -sign c:\tmp\sos.private-ec-key.pem
  • the private key The Private Key file used to sign the workflow file
• -out c:\tmp\example-wf.workflow.json.sig.bin
  • the The path to the output file that contains the binary representation of the signature
• c:\tmp\example-wf.workflow.json
  • the The path to the original workflow file.
    
    
    

...

• base64
  • OpenSSL switch to transform the signature file from binary encoding to base64 encoding
• -in c:\tmp\example-wf.workflow.json.sig.bin
  • the The binary encoded signature file as created in step 1)
• -out c:\tmp\example-wf.workflow.json.sig
  • the The base64 encoded signature file to be created that carries a .sig extension and that will be picked up later on by JOC Cockpit when importing workflows and signatures.

...

• base64 encoded signature files have to be available in the same folder as the workflow file.
• Creating a .tar.gz/.zip import archive file that includes the workflow files and signature files.
  • The exported archive contains the meta_inf file. This file does not have to be signed. However, it should be present in the top-level folder of the import archive file.
• Importing and deploying the archive file using the Import and Deploy operation of JOC Cockpit.
  
  

Image Modified

Enter the signing algorithm using default Java names:

Image Modified

Supported signing algorithm names include:

...