You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Introduction

  • When JOC Cockpit is installed for a high security level then deployment of scheduling objects forces external signing.
    • 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.
  • For details see JS7 - Security Architecture.

Prerequisites

Required: User Signing Certificate

Each user with the permission to deploy has to add their X.509 signing certificate to JOC Cockpit:

Optional: Root CA Certificate

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



  • Any user signing certificates have to be rolled out to the Controller and Agents. Certificates are stored in the config/private/trusted-x509-keys folder 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 folder of  Controller and Agent installations.
    • No further user signing certificates have to be added to the Controller or Agents as long as the user signing certificates is created by the given 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 and Agents but should only add individual user signing certificates.

Deployment Process Overview

  • The user has to export the desired configuration of scheduling objects with the Export operation available from the Configuration view.

  • Deployment tasks include:
    • Exporting scheduling objects with the checkbox "for Signing" checked to an archive file (.zip).

    • Unpacking the exported archive.
      • The archive contains a meta_inf file and the configurations.
    • Signing the 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 with an additional filename extension.
      • for RSA/ECDSA signatures use the filename extension ".pem" or ".sig" respectively.
      • for PGP signatures use the default filename extension ".asc".
    • Packing the archive once again to add the signature files and make sure that the meta_inf file is still available with the root folder of the archive.
    • Uploading the archive using the Import And Deploy button.

Example

Export

  • Click Export in the context menu of the folder to export or from the button in the top right corner:



  • In the Export popup window check the checkbox for Signing:



  • Select the scheduling objects to deploy.

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.

Extract the configuration from the archive and preserve the folder structure of the included scheduling object files:


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
  • -sha256
    • the signer algorithm
  • -sign c:\tmp\sos.private-ec-key.pem
    • the private key file to sign the content of the original configuration file
  • -out c:\tmp\example-wf.workflow.json.sha256
    • the path to the output file
    • the file containing the binary representation of the signature
  • c:\tmp\example-wf.workflow.json
    • the path to the original scheduling object file (in this example: workflow)

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:

  • Copying the newly created text signature files to the same folders as the scheduling object files.
  • Packing the archive once again or adding the signature files to the existing archive.
    • 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.
  • Importing/Deploying this archive with the Import And Deploy function of JOC Cockpit.



Enter the signature algorithm using the default Java names for the signature algorithm:


Supported signature names include

OpenSSLJava with RSAJava with ECDSA
sha512SHA512withRSA-
sha256SHA256withRSASHA256withECDSA


During import, the scheduling object configuration and the signature from the archive will be forwarded to the Controller and will be validated. After successful validation by the Controller and by the Agent the scheduling object is deployed.


  • No labels