Introduction

The built-in certificate authority offers the functionality

• to create a Root CA private key and certificate, to self-sign the Root CA certificate,
  • The Root CA private key and certificate are stored with the JS7 - Database.
• to create private keys and certificates per Controller 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, 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 CA private key and certificate with JOC Cockpit,
• to create security tokens for Controller and Agent instances with JOC Cockpit,
• to request private keys and certificates to be created on-the-fly by Controller and Agent instances.

Manage Root CA Private Key and Certificate

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

The User->Profile menu of JOC Cockpit offers user accounts that are assigned the administrator role the sub-tab CA Management. This sub-tab is available to users that are assigned the sos:products:joc:adminstration:manage role.

Explanation:

• 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 CA private key and certificate require new private keys and certificates for Controller instances and Agents to be created.
  • 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 the future.

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

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 Controller 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.
• 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 are visible from the user interface.

Explanation:

• Each Agent for which a security token has been created displays the expiration date and offers a key symbol:
  • when hitting the key symbol the security token will be displayed,
  • display of the security token offers a button to copy the security token value to the clipboard.
• Having copied the security token to the clipboard, proceed by switching to the Controller instance's or Agents server and perform the steps for JS7 - Certificate Authority - Rollout Certificates for HTTPS Connections that require to specify the security token for authentication with JOC Cockpit.