Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Server Automation10.50

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 and decide how that password is to be provided. See Select a new password to protect the crypto materials
Configure Core Recertification configuration file with the correct values. See Configuring core recertification
Ensure that all your Cores are up and running. See Ensure that the Core Recertification tool correctly recognizes the mesh setup
Ensure that the Core Recertification tool correctly recognizes your Mesh setup. See Ensure that all cores are running/resolve conflicts
Check that all managed servers are reachable by running a Communications test against all managed servers before Core Recert is invoked.

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.

Some of the Core Recertification tasks are accomplished by Automation Platform Extension (APX) jobs. Therefore, the crypto database password, though obfuscated, may briefly appear in the job parameters or in the job audit logs.

To avoid having the crypto database password appearing in job parameters or audit logs, you may convey the crypto database password using a file by following this procedure:

Before invoking the Core Recertification Tool on the Core host, determine the Core host’s Server ID. You can obtain the Server ID from either the SA Client or by looking in
/etc/opt/opsware/agent/mid. You must specify the Server ID value for base_core_server_ref in the Core Recertification configuration file.
Create a file, /var/opt/opsware/crypto/cadb/__recert_overwrite__, which contains the new crypto database password. for example cadb_password=<new crypto database password>. Ensure that this file is read-only to the root user.
Remove the /var/opt/opsware/crypto/cadb/__recert_overwrite__ file after Core Recertification has successfully completed.

Because the crypto database password is required in the Core Recertification configuration file, you can specify an invalid password in that file as a security measure.

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.

Configuring 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:

From the command line, log on to an SA Core host as root user.
Run
/opt/opsware/oi_util/OpswareCertTool/recert_utils/discover_mesh -p
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 Running a system diagnosis and Resolving mesh conflicts .

Send Help Center feedback