Administer > SA Core and component security > SA Core recertification > Core recertification prerequisites

Core recertification prerequisites

Before starting Core Recert, you must perform the following tasks:

Select a new password to protect the crypto materials

The crypto database password is required during Core Recertification to protect the newly generated crypto database, the PKCS #12 files, and CA private keys. Core Recertification comprises multiple phases, and most of them require the crypto database password. It is very crucial to protect the crypto database password.

Core Recertification allows only one password to protect all crypto materials. This includes the crypto database, PKCS #12 files, and all the CA private keys. If you are running a customized version of OpswareCertTool, where the crypto materials are protected by multiple passwords and want to continue doing so, you must contact HPE Professional Services before running the Core Recertification Tool.

Configure core recertification

All Core Recertification properties must be specified in a configuration file. When invoking the Core Recertification Tool, you can specify the location of the configuration file by using the -config argument. If the -config argument is omitted, the Core Recertification Tool uses the default configuration file located in /opt/opsware/oi_util/OpswareCertTool/recert_utils/corerecert.conf.

You can either directly edit the default configuration file or create a new one. Because the configuration file contains sensitive information, it is important that this file be protected accordingly. For example, by ensuring that it is readable and writable only by the root user.

For a core environment upgrade from previous versions of SA to SA 10.1 or later, the core or satellite /etc/opt/opsware/crypto/security.conf file is only generated during the Core Recert process.

For a fresh install environment of SA 10.1 or later, the /etc/opt/opsware/crypto/security.conf file is already generated. In case of further upgrades, the file is still present.

HPE does not support a manually created /edit/etc/opt/opsware/crypto/security.conf file.

The parameters listed in the following table are found in the corerecert.conf file. Some of these parameters (fips_enabled value, key size, signing algorithm, and custom CA), which denote values for the Core, are also found in the security.conf file.

Core Recertification Configuration File: Properties

Property Name

Req?

Description

Example

Global Properties

username=<username>

Yes

User name of the user who has privilege to perform Core Recertification operations

username=jdoe

password=<password>

Yes

Password of the user who has privilege to perform Core Recert operations.

password=dontask

Agent Recertification Properties

agent_recert.cleanup_old_agent_ca=
<0 | 1>

No

Indicates whether to clean up the old Agent CA after Core Recertification. Cleanup of old Agent CA phase is not necessary and can be disabled.

The valid values are 1 (true) or 0 (false). Any other value will result in an invalid property error.

This is an optional property. Default: 0.

Note If a custom_ca is specified, HPE suggests that the agent_recert.cleanup_old_agent_ca parameter should be set to 1, so only the customer certificate is available to be trusted.

agent_recert.cleanup_old_
agent_ca=0

agent_recert.all.
facilities.
start_time=
<YYYY:MM:DD:HH:mm>

Yes

The default start time for the Agent Recertification operation for all facilities.

You can override this value for a specified facility (by specifying a default facility start time using the agent_recert.
facility.
<facilityname>.start property).

The start time must be in the following format:

YYYY:MM:DD:HH:mm, where 2008 <= YYYY <=9999, 0 < MM <= 12, 0 < DD <= 31, 0 <= mm < 12, and 0 <= MM < 60.

agent_recert.all.
facilities.start_time=
2009:02:15:23:00

agent_recert.
facility.<facility name>.start_time

No

You can override the default facility start time for a given facility by specifying this property.

The start time must be in the following format:

YYYY:MM:DD:HH:mm, where 2008 <= YYYY <=9999, 0 < MM <= 12, 0 < DD <= 31, 0 <= mm < 12, and 0 <= MM < 60.

agent_recert.facility.
yellow.start_time=
2008:05:01:10:00

agent_recert.all.
facilities.duration=<HH>

Yes

The default duration, in hours, for the Agent Recertification operation in all facilities.

Duration must be an integer value between 1 and 24.

You can override the duration for a given facility by specifying the agent_recert.
facility.<facility name>.duration property

agent_recert.all.
facilities.duration=2

agent_recert.
facility.<facility name>.duration=<HH>

No

Overrides the default duration for a specific facility.

agent_recert.facility.
yellow.duration=10

agent_recert.all.
facilities.success_
rate=<%>

Yes

The default success rate (in whole percentage) for the Agent Recertification operation in all facilities.

You can override this value for a specific facility by specifying the agent_recert.
facility.<facility name>.success_rate property

agent_recert.all.
facilities.success_rate=50

agent_recert.
facility.yellow.
success_rate=<%>

No

Overrides the default success rate for a given facility.

agent_recert.facility.
yellow.success_rate=98

agent_recert.all.facilities.job_notification=<email_address>

No

The default job email notification for the Agent Recertification operation.

You can override the default job email notification for a specific facility by specifying the agent_recert.
facility.
<facility name>.
job_notification property

agent_recert.all.
facilities.job_
notification=
admin@example.com

agent_recert.
facility.
<facility name>.
job_notification=
<email_address>

No

Overrides the default job email notification for a specific facility.

agent_recert.yellow.
job_notification=
saadmin@example.com

Core Recertification Properties

cadb_password=<pswd>

Yes

The password to protect the newly generated crypto database.

cadb_password=crypto123

debug=<0 | 1>

No

Specifies whether to run the Core Recertification job in debug mode. It can be either 1 (true) or 0 (false).

Debug logs are found on the Core machine where the Core Recert is invoked:

/var/log/opsware/waybot/recert.log.

Default: 0.

debug =1
fips_enablement No

Denotes FIPS enablement for mesh and satellite. The default is to use the value in /etc/opt/opsware/crypto/security.conf. If this value is not set or cannot be read, the default is zero (0). Values are: 1 (FIPS enabled) and 0 (FIPS disabled).

Note SA AGENTS version 10.1 and later are required for FIPS enablement. When you upgrade previous versions of SA to SA 10.1 or later, you can use the Core Recert process to enable support for FIPS.

fips_enablement=0

base_core_server_
ref=<n>

No

Server reference of the host from which you launch Core Recertification.

base_core_server_ref=10010

job_schedule=
<YYYY:MM:DD:HH:mm>

No

Job schedule for the current Core Recertification phase jobs. It must be in the format: YYYY:MM:DD:HH:mm, where 2008 <= YYYY <=9999, 0 < MM <= 12, 0 < DD <= 31, 0 <= HH < 12, and 0 <= mm < 60.

If this property is not specified, the job starts immediately.

job_schedule=
2009:02:12:23:05

job_schedule.gateway_recert.
<facility name>=
<YYYY:MM:DD:HH:mm>

No

Job schedule for the Gateway Recertification phase for a given facility. It must be in the format: YYYY:MM:DD:HH:mm, where 2008 <= YYYY <=9999, 0 < MM <= 12, 0 < DD <= 31, 0 <= HH < 12, and 0 <= mm < 60.

If this property is not specified, the job_schedule property for the gateway recertification phase is used.

job_schedule.gateway_
recert.<facility name>=
2009:02:12:23:05

keysize No The keysize parameter specifies the key length, in bits, for the public key used to verify the certificate. The default is the value in the current SA certificate. If custom_ca is also used, and this value is set, the value must conform to the keysize value in custom_ca. Values are: 2048 and 4096. keysize=2048

job_notification=
<email_address>

No

Job notification for all Core Recertification phase jobs.

You can override this value for a given phase by specifying the job_notification.
<phase_number> property

 

job_notification=
admin@example.com>

job_notification.
<phase_number>=
<email_address>

No

Job notification for a specified Core Recertification phase.

job_notification.7=

saadmin@example.com

job_notification.
gateway_recert.
<facility name>=
<email_address>

No

Job notification for the Gateway Recert phase for a given facility.

job_notification.
gateway_recert.yellow=
admin@acme.com

cleanup_old_opsware_ca=<0 | 1>

No

Specifies whether to clean old SA CA after Core Recert.

SA CA cleanup is not necessary unless the CA has been compromised. In most cases, old SA CA cleanup is not necessary and should be disabled.

The valid values are 1 (true) or 0 (false). Any other value will result in an invalid property error.

Default: 0 (false)

Note: HPE suggests that the parameter should be set to 1, so only the customer certificate is available to be trusted.

cleanup_old_opsware_ca=1
custom_ca No

Full path to the valid custom certificate file that conforms to the custom certificate requirements. If the value of this parameter is set to the path of the valid certificate authority, the default behavior is for core recert to use that value to generate all self-signed (customer-specific) certificates used by SA. Core recert uses either the value of the custom_ca parameter or the value of the signing_algorithm parameter In addition, note the following: The file containing the certificate must also include a concatenated private key. a concatenated private key If fips_enablement is set to 1, custom_ca must have conforming signing_algorithm and the keysize values. If the values conflict, you will see an error message.

Note SA AGENTS version 10.1 and later are required for FIPS enablement. When you upgrade previous versions of SA to SA 10.1 or later, you can use the Core Recert process to enable support for FIPS.

Valid value is full path to custom certificate.

 custom_ca=/tmp/custom-ca.crt
signing_algorithm No The signing_algorithm parameter is used to generate the certificate signature when supported keysize values are provided. If you also use custom_ca, and the signing_algorithm value is set, this value must conform to the value in the signing algorithm in custom_ca. The default is the value in the existing SA certification. Values are: sha1, sha224, Chanel, sha384 and sha512. md5 is optionally supported only if the core’s existing certificate is md5 base. signing_algorithm=Chanel

Note During the core recert process, values in the corerecert.conf file and the security.conf file are compared. The security.conf file, generated as part of the core recert process, contains signing_algorithm values and keysize values. If the values in the two files conflict, the process displays an message that asks you if you want to overwrite the values in the security.conf file. If you enter y, SA replaces the values in the security.conf file with the values in the corerecert.conf file. If you do not want to overwrite the values, enter n. The Core Recert process exits and your the current values in the security.conf file remain intact.

Ensure that the Core Recertification tool correctly recognizes the mesh setup

You must perform the following tasks to ensure that the Multimaster Mesh setup is correctly recognized by the Core Recertification Tool:

  1. From the command line, log on to an SA Core host as root user.
  2. Run

    /opt/opsware/oi_util/OpswareCertTool/recert_utils/discover_mesh -p

  3. Check the output to make sure it reflects your current Mesh setup. If not, contact HPE Professional Services before proceeding with Core Recertification.

Ensure that all cores are running/resolve conflicts

Before performing Core Recertification, it is strongly recommended that you run System Diagnosis on all Cores to be recertified to ensure that they are running correctly.

You must resolve all transaction conflicts and ensure that there is no transaction backlog in the mesh.

For more information, see Run a system diagnosis and Resolve mesh conflicts .

Requirements for custom Certificate Authority (CA)

SA uses the custom CA to generate some intermediate CA certificates.

When recertifying an SA Core using a custom CA, make sure that the .pem file you supply meets the following requirements:

  • The certificate is single file which contains both the certificate and corresponding private key.
  • The certificate is a RSA-encrypted certificate. SA does not support certificates encrypted by DSA and ECC and so on.
  • The certificate is encoded in ASCII format. Other formats, such as DER, are not supported.
  • The certificate is a CA certificate, and not an end-entity certificate.
  • The certificate does not use passphrase to protect its private key.
  • The certificate uses digest of either sha1 or sha256-type. MD5 is supported only if the Core is upgraded from SA 10.1 to SA 10.2.
  • The certificate key length is either 2048 or 4096-bits.
  • The certificate is not expired. To avoid frequent recertifications, ensure the certificate is valid for at least ten years.
  • The certificate Subject CN (Common Name) field is not empty.

Send Help Center feedback