Upgrade Impacts - CLA2 Certificates and Key Management

There are several upgrade impacts to certificate and key management:

  • The authentication option in CLA2 requires a private key to be checked into the system certificate UI. The private key is referenced when you configure the adapter. The public key must be made available to the CLA2 server through a JKS file.
  • The SSL option in CLA2 requires a CA certificate to be checked into the CA certificates UI. The CA is referenced when you configure the adapter. The private key must be made available to the CLA2 server through a JKS file.
  • Updates to all of these keys and certificates can be made through the UI and any tool that supports modifying the JKS file, such as the keytool in the JDK.
  • When you apply the patch, default keys are created in the database and exported to a JKS file so that they are available to the local CLA2 server. The same keys can be used for remote CLA2 servers.
  • The certificates and keys are not checked for expiration.
  • All remote CLA2 servers must use the same keys. The CLA2 adapter must be configured to use only one signing key and one CA certificate.

The following diagram shows the relationship between the ASI JVM, with a JKS database store, and a remote CLA2 server, with a file system JKS store.

This diagram shows a large box that represents the ASI JVM as Host 1. There is a box inside Host 1 that represents the JKS store as a database and an arrow connects it to the CLA2 adapter. There is an arrow from the CLA2 adapter box to another box, outside of the large ASI JVM box, that represents Host 2. This is where the CLA2 JVM is located. From there, an arrow points from the CLA2 server, by way of a program fork, to a small box representing a custom script, all within Host 2. There is a box inside Host 2 that represent the JKS store as a file system and an arrow connects it to the CLA2 server.