...

• 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 Agents 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 workflow 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 private key Signing Certificate has to be in place or
      • the user's certificate Signing Certificate has to be in place.
      • Using the Root CA Certificate or Intermediate CA Certificates simplifies certificate management as only a single certificate file has to be present for any Controller or Agent instanceinstances. At the same time, security-aware administrators might prefer to deploy individual user certificates 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 workflow 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 workflow scheduling object then deployment is denied.will be denied.

For creation of certificates for digital signing see JS7 - How to create X.509 Signing Certificates.

Security Levels

The JOC Cockpit is installed for one of the following security levels, see the JS7 - Security Architecture article for more information.

• 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
  • Workflows Scheduling objects are signed outside of JOC Cockpit:
    • Workflows 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 workflow scheduling object file included is signed individually. 
      • 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 workflow scheduling object file with the same name and the extension .sig (using X.509 certificates) .asc (using PGP keys).
    • The signed workflow scheduling object files and signature files are added to the same or to a new archive file.
  • The archive file that includes the workflows and signatures scheduling object files and signature files is imported to JOC Cockpit. The deployment step is performed inline with the import step.

...

• JS7 - Deployment of Workflows for High Security Level
• JS7 - Signing Workflows for High Security Level
• JS7 - How to create X.509 Signing Certificates