Core recertification phases

Core Recertification has several phases. Which phases are required depends on your Multimaster configuration.

The following table describes the Core Recertification phases:

Core recertification phases

Phase

Description

1-3

Back up existing crypto material, generates new crypto material, and distributes the new CAs to all the Core Components. These three phases occur sequentially during the first run of the Core Recertification tool. All the existing crypto materials are backup into the crypto.<session number> directories. Each Core component has its own backup directory.

Create /etc/opt/opsware/crypto/security.conf if it is missing. Update existing /etc/opt/opsware/crypto/security.conf.

4

Distribute the new Agent CAs to all the Agents so that Agents will trust both the new and old Agent CA at the same time. This is a mandatory step.

Important : Skipping Phase 4 will lead to SWR communications tests failures and Phase 8 will not recertify the agent.

6a

Mesh Restart: Restart the Mesh so that it trusts both the new and old CA hierarchies.

6b

Set up the Public Key Infrastructure (PKI) on the primary Spins so that they'll start issuing certificates generated with the new Agent CA.

7

Recertify the Gateways.

8

Recertify the Agents.

Note Make sure all managed servers are functioning and reachable throughout phase 8, or the Core will fail to communicate with the servers after the Core Recert process is complete.

9a

Recertify the Core components, Mesh restart, Regenerate User Signatures.

9b

Check Mesh Restart status. If the Mesh has successfully restarted, all the Core components are now using the new crypto material while still trusting the old crypto material.

11

[Optional] Re-signs data in the Model Repository, packages/files in the Software Repository and recurring job tokens and audit streams. (Available in SA 10.10 or later.)

12

[Optional] Remove old Agent CAs. Required only when Agent CAs have been compromised or you no longer trust the old CAs.

Note When a managed server that has both an older and a newer CA is not recerted during the Agent Recert phase (Phase 8), that server will not be able to communicate with another managed server that only has an older CA.

Note For Core Recert with custom certificate, HPE recommends that you go through phase 12 so the old certificate is removed from the agent trusted CA store, and, therefore, only the customer certificate is used for verification.

13a

[Optional] Remove the old Core component CAs. Required only when Core component CAs have been compromised or you no longer trust the old CA hierarchies.

Note For Core Recert with custom certificate, HPE recommends that you go through phase 13 so the old Core-component certificate is removed from the trusted CA store, and, therefore, only the customer certificate chain is used for verification

13b

[Optional] Mesh restart. Required only when 13a is also required.

A Mesh Restart means restarting the SA services on all Core and Satellite boxes. The restart has to be performed manually. The following is the startup sequence for multi-host cores:
Model Repository (MR) -> Infrastructure -> Software Repository (SR) -> Slice -> OSProv

The following figure shows the flow and phases of the recertification process: