...

The built-in certificate authority offers the functionality

• to create a root Root CA private key and certificate, to self-sign the root Root CA certificate,
  • The root Root CA private key and certificate are stored with the JS7 - Database.
• to create private keys and certificates per Controller instance and Agent instance, to sign the resulting certificates.
  • The private keys and certificates are not stored with the database, instead, they are requested by Controller and Agent instances and Agents, are created on-the-fly and are forwarded to the requester.
• to create security tokens that allow Controller instances and Agents to authenticate their request for a private key and certificate.
  • Security tokens are applied during JS7 - Certificate Authority - Rollout Certificates for HTTPS Connections.
  • Security tokens are created for one-time use, they are invalidated after being used a single time or if their lifetime is exceeded.

Certificate Management includes to perform the following steps:

• to manage the root Root CA private key and certificate with JOC Cockpit,
• to create security tokens for Controller and Agent instances and Agents with JOC Cockpit,
• to request private keys and certificates to be created on-the-fly by Controller and Agent instances and Agents.

Manage Root CA Private Key and Certificate

The root To setup the certificate authority (CA) a Root CA private key and self-signed certificate have to be created from an initial step:

...

• Operations offered from this sub-tab include
  • to generate the Root CA private key and certificate and to self-sign the certificate,
  • to import and to update the private key and self-signed certificate in case that they are generated by an external certificate authority.
• Consider that updates to the root Root CA private key and certificate require new private keys and certificates for Controller instances and Agents to be created.
  • The Existing private keys and certificates remain in place with Controllers and Agents, they continue to work but cannot be verified by a user.
  • It is therefore recommended to create and to roll-out new private keys and certificates within a foreseeable time.
• JOC Cockpit supports ECDSA key algorithms only as RSA key algorithms are not considered secure for a longer future.the future.

If the Root CA private key and certificate is to be generated by JOC Cockpit then the following popup window appears:

Image Added

The requested Distinguished Name (DN) is a unique identifier for the certificate.

• The DN can include any attributes allowed.
• The DN has to include the CN attribute
• Example
  • CN=JS7 Root CA, OU=IT Operations, O=SOS, L=Berlin, S=Berlin, C=DE

Manage Private Keys and Certificates for Controllers and Agents

For security reasons private keys and certificates of Controllers and Agents are not stored with JOC Cockpit. Instead, they are requested to be created by use of a command line client that ships with each Controller and Agent instance. The command line client

• does not require user/password authentication for JOC Cockpit but is started with a security token that authenticates the client.
• requests JOC Cockpit to create a private key and certificate on-the-fly that are returned to the client as a response to its request.
• adds the private key to the Controller or Agent instance's keystore and adds the certificate to the respective truststore.
• updates the Controller or Agent instance's configuration to use the updated keystore and truststore.

As a result the Controller or Agent instance is equipped with an SSL certificate and is ready to accept HTTPS connections.

The User->Manage Controllers/Agents menu of JOC Cockpit offers to create security tokens for Controller instances and Agents instances individually:

• You can use the Controller's action menu to create one-time security tokens for Controller instances.
• You can select one or more Agents to create one-time security tokens per Agent. Then use the Create one-time Token button.
• After selection of the Controller or Agents a popup window is displayed that asks for the lifetime of the token.

Explanation:

• The security token is valid until its lifetime expires. 
  • It is recommended to use short lifetimes such as 30 minutes that are sufficient to perform the steps for roll-out of certificates to the respective Controller and Agents.
  • The lifetime is specified for a time zone as the user browser's time zone and the time zone of the server operating a Controller instance or Agent might differ.
• Tokens Security tokens become invalid after one-time use. Cleanup of expired security tokens is performed automatically by JOC Cockpit.
• Once the security tokens are generated they become accessible are visible from the user interface.

Explanation:

...