Page History

...

• The signing process is performed by the JOC Cockpit and includes:
  • the user is assigned a private key and a certificate (X.509) or a public/private key (PGP),
  • to create a signature from the JSON representation of the workflow by use of the user's private key.
• The verification process is performed by the Controller and Agent which has been assigned the relevant scheduling object such as a workflow:
  • Both Controller and Agent instances look up available X.509 certificates and PGP public keys from files with the following locations:
    • Unix
      • X.509 certificates: ./config/private/trusted-x509-keys
      • PGP public key: ./config/private/trusted-pgp-keys
    • Windows
      • X.509 certificates: .\config\private\trusted-x509-keys
      • PGP public key: .\config\private\trusted-pgp-keys
  • If a certificate or public key is found then the signature of the deployed scheduling object is verified as follows:
    • X.509: 
      • the Root CA Certificate or Intermediate CA Certificate that was used originally to sign the user's Signing Certificate has to be in place or
      • the user's self-issued Signing Certificate has to be in place.
      • Using the Root CA Certificate or Intermediate CA Certificates simplifies certificate management as a single certificate file has to be present for any Controller or Agent instances. At the same time, security-aware administrators might prefer to deploy individual user Signing Certificates to Controller and Agent instances for more fine-grained control of which workflows and other objects can be deployed by a specific user to a given Agent. Similarly a specific Intermediate CA can be used to sign user Signing Certificates.
    • PGP: the public key available for the given user who signed the deployed scheduling object has to be present.
  • Controller and Agent instances make use of all certificate files and public key files available in the directories mentioned above. If none of the files matches the signature of a deployed scheduling object then deployment will be denied.

...

• Security Level Low
  • Inventory objects are automatically signed with the private key that is stored with the root account.
  • Signing is automatically applied when performing the Deploy operation.
• Security Level Medium
  • Inventory objects are automatically signed with the private key that is stored with the current user's account.
  • Signing is automatically applied when performing the Deploy operation.
• Security Level High
  • Scheduling objects are signed outside of JOC Cockpit:
    • Scheduling objects are exported using the Export operation and the option For signing.
    • The export archive file is transferred to a secure device, e.g. to a secure desktop machine.
    • The export archive file is extracted and each scheduling object file included is signed individually. 
      • The JS7 offers a script solutions, see JS7 - Signing Workflows for High Security Level.
      • For There is no prerequisite regarding the tools used for signing. For example the OpenSSL command line utility can be used as well as tools such as OpenPGP Kleopatra.
      • The signing step includes to create a signature file for each scheduling object file with the same name and the extension .sig (using X.509 certificates) or .asc (using PGP keys).
    • The signed scheduling object files and signature files are added to the same or to a new archive file.
  • The archive file that includes the scheduling object files and signature files is imported to JOC Cockpit. The deployment step is performed inline with the import step.

...