Introduction

The Certificate Authority available from the JOC Cockpit provides the following functions:

• creation of a Root CA private key and certificate, self-signing of the Root CA certificate,
  • The Root CA private key and certificate are stored in the JS7 - Database.
• creation of private keys and certificates for each Controller and Agent instance, signing the resulting certificates.
  • The private keys and certificates are not stored with the JS7 database, instead, they are requested by Controller and Agent instances, are created on-the-fly and are forwarded to the requester.
• creation of 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 once or if their lifetime has been exceeded.

Certificate Management includes performing the following steps:

• managing the Root CA private key and certificate with JOC Cockpit,
• creating security tokens for Controller and Agent instances with JOC Cockpit,
• requesting private keys and certificates to be created on-the-fly by the Controller and Agent instances.

Manage Root CA Private Key and Certificate

To set up the Certificate Authority (CA), a Root CA private key and self-signed certificate have to be created in an initial step.

The JS7 - Profiles - SSL Key Management sub-view of the JS7 - Profiles can be accessed by user accounts that are assigned the administrator role. To be more precise, this sub-view is available to user accounts that are assigned the sos:products:joc:adminstration:manage role - see JS7 - Default Roles and Permissions for more information.

Explanation:

• Operations offered from this sub-view include:
  • generating the Root CA private key and certificate and self-signing the certificate,
  • importing and updating private keys and self-signed certificates which have been generated by an external Certificate Authority.
• Note that updates to the Root CA private key and certificate require new private keys and certificates to be created for the Controller instances and Agents.
  • 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 that new private keys and certificates are created and rolledout within a foreseeable time.
• JOC Cockpit only supports ECDSA key algorithms as RSA key algorithms are not considered secure for the future.

If the Root CA private key and certificate are to be generated by the 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

For details see the JS7 - Profiles - SSL Key Management article.

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, the Start Script that ships with each Controller and Agent instance requests that they are created by the Certificate Rollout Client. The Certificate Rollout Client:

• does not require user/password authentication for JOC Cockpit but is started with a security token that authenticates the client.
• requests that the JOC Cockpit creates a private key and certificate on-the-fly which 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 a TLS/SSL certificate and is ready to accept HTTPS connections.

The JOC Cockpit's User->Manage Controllers/Agents menu is used to create security tokens for individual Controller and Agent instances:

• 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 that short lifetimes such as 30 minutes which are sufficient to perform the steps for rollout of certificates to the respective Controller and Agents are used.
  • 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 an Agent might differ.
• Security tokens become invalid after one-time use. Cleanup of expired security tokens is performed automatically by the JOC Cockpit.
• Security tokens are shown in the user interface once they have been generated.
  
  

Explanation:

• The expiration date and a key symbol are displayed for each Agent for which a security token has been created:
  • hitting the key symbol causes the security token to be displayed,
  • the security token is displayed along with a button to copy the security token value to the user's clipboard.
• Once the security token has been copied to the clipboard, a session (SSH, RDP) to the server that hosts the Controller instance or Agents should be established and the steps for JS7 - Certificate Authority - Rollout Certificates for HTTPS Connections performed that are required for specification of the security token for authentication with the JOC Cockpit.