Space banner

   

This version of the product has reached end of support. The documentation is available for your convenience. However, you must be logged in to access it. You will not be able to leave comments.

Configuring a local certificate authority

BCM agents use a private key infrastructure (PKI) that is described in SSL certificates. The PKI includes a preferred certificate authority, a server certificate, an integration certificate and one or more trusted authorities. When a BCM agent starts, it generates a server certificate using the configured certificate authority. 

In BCM versions before 12.0, the certificate authority was shared across installations. This is now referred to as AMP legacy certificate authority.

In BCM versions 12.0 and later, each installation generates a local BCM certificate authority instead. This means that each BCM environment has a different authority. Consequently, an agent from BCM system Example1 cannot communicate with an agent from BCM system Example2 as they do not use or trust the same authority. This communication was possible using the AMP legacy certificate.

For BCM systems that were installed before 12.x, the AMP legacy certificate was not replaced at subsequent upgrades, so they still use the legacy authority. The first dashboard item determines whether this AMP legacy certificate is still being used. If so, the Master generates the following elements:

  • A new local BCM certificate authority
  • A deployment package including this newly created authority
  • Three operational rules you should use to deploy the package

You should only deploy the new authority if you are using the AMP legacy certificate. If the AMP legacy certificate is not in use, the dashboard displays a green configured message. Otherwise, you should deploy the new authority by executing the three operational rules. 

Considerations for deploying the new certificate authority

  • The operational rules should be assigned to all devices (unless one or more devices are not expected to get this new authority). The Master can be included in the target population.
  • Rules are executed in sequence.
  • Ensure that each operational rule is completed successfully on all agents before assigning and executing the next operational rule.
    • The first operational rule deploys the package and to starts trusting the new authority. The AMP legacy authority is still in use and trusted.
    • The second operational rule starts using the newly deployed BCM authority. The AMP legacy authority is not used anymore but it is still trusted.
    • The last operational rule stops trusting the legacy AMP legacy authority.

Once all these rules have been executed, the entire environment is using a new local authority. Communication attempts from agents using the legacy AMP authority will fail as the agents:

  • have no knowledge about the environment local authority
  • use the legacy AMP authority that is no longer trusted

To update existing rollouts

The AMP legacy certificate can no longer be used in the environment. Each BCM agent uses and trusts the local BCM authority. The new authority must also be used for existing rollouts. If an existing rollout is not updated, it continues to use the AMP legacy authority and does not trust the new local BCM certificate authority. To update rollouts, once the new authority has been deployed, select the rollouts to updates, and click Update Certificate Authority from the context sensitive menu:

 

Was this page helpful? Yes No Submitting... Thank you

Comments