Certificate Configuration

The following API commands enable you to configure certificates on SSL-configured Agents and manage and rotate Certificate Authorities (CA):

config server:agent:crt:expiration::get

The config server:agent:crt:expiration::get command enables you to get the expiration date of an SSL certificate from an SSL-configured Agent. The date is returned exactly as it appears in the certificate.

You can use this API command in a script that automates certificate updates, as described in Automating SSL Certificate Updates on Agents.

  • CLI

  • REST

ctm config server:agent:crt:expiration::get <server> <agent>

The following example shows the REST API syntax for the config server:agent:crt:expiration::get command in cURL.

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token"  #for a session token

curl -H "$AuthHeader" "$endpoint/config/server/$server/agent/$agent/crt/expiration"

To determine the correct AuthHeader value—"Authorization: Bearer $token" or "x-api-key: $token"—see Authentication Tokens.

The following table describes the config server:agent:crt:expiration::get command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

agent

Defines the Agent name.

config server:agent:csr::create

The config server:agent:csr::create command enables you to create a certificate signing request (CSR) for an SSL-configured Agent.

(Control-M/Agent 9.0.21.306 or Control-M/Agent 9.0.22.004 and higher) You can run this API command before the Agent is configured to communicate via SSL/TLS.

You can use this API command in a script that automates certificate updates, as described in Automating SSL Certificate Updates on Agents.

  • CLI

  • REST

ctm config server:agent:csr::create <server> <agent> -f <configuration file>

The following example shows the REST API syntax for the config server:agent:csr::create command in cURL.

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token"  #for a session token

curl -X POST -H "$AuthHeader" -H "Content-Type: application/json"
--data "@examples\configuration.json"  "$endpoint/config/server/$server/agent/$agent/csr"

To determine the correct AuthHeader value—"Authorization: Bearer $token" or "x-api-key: $token"—see Authentication Tokens.

You can append the following line to the end of the command to save the output in a CSR file:

Copy
-o $file_path$file_name

To save the CSR output (a block of encoded text) in a file, you can append the following to the end of the CLI command: > <fileName>

The following table describes the config server:agent:csr::create command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

agent

Defines the Agent name.

configuration file

JSON file that contains required parameters for the CSR.

Here is an example for the content of this file:

Copy
{  
   "organization": "example_organization",  
   "organizationUnit": "example_unit",  
   "cityLocality": "example_city",  
   "stateProvince": "example_state",  
   "country": "CO",  
   "emailAddress": "[email protected]"
}

For country, use the two-letter code abbreviation of the country where your organization is located. For example, CO is Colombia.

Note that the CN property is set automatically by the Agent. Do not include the CN property in this configuration file.

keyAlgorithm

(Optional) Determines the Key algorithm configured for the CSR creation.

Valid Values:

  • rsa

  • ec

keyAlgorithmStrength

(Optional) Determines the Key algorithm strength.

Valid Values:

  • rsa:

    • 2048

    • 3072

    • 4096

  • ec:

    • P-256

    • P-384

    • P-521

signatureAlgorithm

(Optional) Determines the signature algorithm.

Valid Values:

  • rsa:

    • sha256

    • sha384

    • sha512

    • sha3-256

    • sha3-384

    • sha3-512

  • ec:

    • sha256

    • sha384

    • sha512

config server:agent:crt::deploy

The config server:agent:crt::deploy command enables you to deploy a signed certificate to an SSL-configured Agent. This is supported only if the signed certificate was created using the config server:agent:csr::create command. The new certificate that you deploy replaces the existing certificate.

  • For the new certificate to take effect after the deployment, recycle the Agent, either using the config item::recycle command or through the Configuration domain (as described in Agent Management). If the new certificate was signed by a new CA, ensure that this CA is also recognized by the associated Control-M/Server.

  • (Control-M/Agent 9.0.21.306 or Control-M/Agent 9.0.22.004 and higher ) You can run this API command before the Agent is configured to communicate via SSL/TLS.

You can use this API command in a script that automates certificate updates, as described in Automating SSL Certificate Updates on Agents.

  • CLI

  • REST

ctm config server:agent:crt::deploy <server> <agent> <crt_filepath> <ca_chain_filepath>

The following example shows the REST API syntax for the config server:agent:crt::deploy command in cURL.

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token"  #for a session token

curl -X POST -H "$AuthHeader" -F "crtFile=@examples/crt.pem"
-F "caChainFile=@examples/ca_chain.pem" "$endpoint/config/server/$server/agent/$agent/crt"

To determine the correct AuthHeader value—"Authorization: Bearer $token" or "x-api-key: $token"—see Authentication Tokens.

The following table describes the config server:agent:crt::deploy command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

agent

Defines the Agent name.

crt_filepath

Defines the certificate file pathname.

ca_chain_filepath

Defines the Certificate Authority (CA) chain file pathname.

Automating SSL Certificate Updates on Agents

As the administrator, you can automate updates to SSL certificates on multiple Agents by incorporating API commands in scripts.

In this method, you use two scripts to automatically update SSL certificates on multiple Agents:

  • The first script creates CSRs for certificates that are close to expiration.

    This script contains the following API commands in the following order:

    1. config servers::get: Gets a list of Control-M/Servers.

    2. config server:agents::get: Gets a list of Agents for each server.

    3. config server:agent:crt:expiration::get: Determines which of the Agents has a certificate that is close to its expiration date.

    4. config server:agent:csr::create: Creates a Certificate Signing Request (CSR) for each agent that is about to expire, and stores all CSR files in one directory.

    After running this script, you must get the security team at your organization to sign the CSRs that were created by the script.

  • The second script deploys signed certificates to Agents.

    This script contains the following API commands in the following order:

    1. config servers::get: Gets a list of Control-M/Servers.

    2. config server:agents::get: Gets a list of Agents for each server.

    3. config server:agent:crt:expiration::get: Determines which of the Agents has a certificate that is close to its expiration date.

    4. config server:agent:csr::create: Deploys each of the signed certificates to its relevant Agent.

    5. config item::recycle: Recycles the Agent.

    6. config server:agent::ping: Checks that the Agent recycle has completed and the Agent is available.

    7. config server:agent::update: Sets SSL/TLS communication (if relevant) between the Control-M/Server and Agent, as in the following command:

      ctm config server:agent::update <server> <agent> sslState Enabled

config ca:server:agent:list::get

The config ca:server:agent:list::get command retrieves a list of CAs from the trusted keystore of the Control-M/Agent.

CA management commands are supported on Control-M/EM versions 21.200 and later with Control-M/Agent 9.0.22.100 or later.

Before the first time that you use CA management commands, you must run the actions_auth_patch_installer script in Control-M/EM, as follows:

  1. Log in to the primary Control-M/EM machine.

  2. Download a compressed package that contains the script from an S3 storage location, and extract it to a temporary directory.

    On Windows, ensure that the path to the temporary directory does not contain spaces.

  3. Prepare the script file for execution, as follows:

    • Windows: Unblock the actions_auth_patch_installer.bat script file through the file properties.

    • Linux/UNIX: Grant Execute permissions to the actions_auth_patch_installer.sh script file.

  4. Run the script and follow the on-screen instructions.

  • CLI

  • REST

ctm config ca:server:agent:list::get <server> <agent>

The following example shows the REST API syntax for the config ca:server:agent:list::get command in cURL:

Copy
server=controlm
agent=quickstart
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json" "$endpoint/config/ca/server/$server/agent/$agent/list"

To determine the correct AuthHeader value—"Authorization: Bearer $token" or "x-api-key: $token"—see Authentication Tokens.

The following table describes the config ca:server:agent:list::get command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

agent

Defines the Agent hostname or alias. This is the logical name of the Agent.

If annotation is enabled for the Configuration Management category in the CCM or Configuration domain, you must also provide an annotation to justify your action. For more information, see Annotation Input.

Response

The following example shows the config ca:server:agent:list::get response parameters.

Copy
{
  "ca_list": [
    {
      "alias": "ca1",
      "owner": "o=test org intermediate2,cn=test intermediate2 ca2",
      "issuer": "o=test org intermediate1,cn=test intermediate1 ca1",
      "valid_from": "wed sep 24 13:34:52 idt 2025",
      "valid_until": "mon sep 23 13:34:52 idt 2030"
    },
    {
      "alias": "ca2",
      "owner": "o=test org intermediate1,cn=test intermediate1 ca1",
      "issuer": "o=test org root,cn=test root ca",
      "valid_from": "wed sep 24 13:34:52 idt 2025",
      "valid_until": "mon sep 23 13:34:52 idt 2030"
    },
    {
      "alias": "ca3",
      "owner": "o=test org root,cn=test root ca",
      "issuer": "o=test org root,cn=test root ca",
      "valid_from": "wed sep 24 13:34:51 idt 2025",
      "valid_until": "sat sep 22 13:34:51 idt 2035"
    }
  ]
}

The following table describes the config ca:server:agent:list::get command parameters that are shown in the above response.

Parameter

Description

alias

The alias name of the CA.

owner

The owner of the CA.

issuer

The Issuing CA.

valid_from

The CA validity start date.

valid_until

The CA validity end date.

config ca:server:agent::add

The config ca:server:agent::add command enables you to add a new CA or CA chain to the trusted keystore of the Control-M/Agent based on the provided aliases.

Before the first time that you use CA management commands, see the note in config ca:server:agent:list::get and ensure that you have performed the necessary setup.

  • CLI

  • REST

ctm config ca:server:agent::add <server> <agent> <caFile> <aliases>

ctm config ca:server:agent::add server1 agent1 "/home/CA_chain.pem" '{"aliases":[{"name":"AliasName1"},{"name":"AliasName2"},{"name":"AliasName3"}]}'

The following example shows the REST API syntax for the config ca:server:agent::add command in cURL:

Copy
server=controlm
agent=quickstart
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json" -X POST "$endpoint/config/ca/server/$server/agent/$agent" \
--form 'caFile=@"/C:/Temp/CA_chain.pem"' \
--form 'aliases=@"/C:/Temp/aliases.json"' 

To determine the correct AuthHeader value—"Authorization: Bearer $token" or "x-api-key: $token"—see Authentication Tokens.

The following table describes the config ca:server:agent::add command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

agent

Defines the Agent hostname or alias. This is the logical name of the Agent.

caFile

Defines the name of the CA chain file. The file must be in a valid PEM format.

aliases

Defines the names of aliases for the new CA or CA chain in JSON format, as in the following example:

Copy
{"aliases":
  [
    {"name":"AliasName1"},
    {"name":"AliasName2"},
    {"name":"AliasName3"}
  ]
}

The number of aliases must be the same as the number of CAs in the CA chain file.

Aliases must not contain space characters.

If annotation is enabled for the Configuration Management category in the CCM or Configuration domain, you must also provide an annotation to justify your action. For more information, see Annotation Input.

config ca:server:agent::delete

The config ca:server:agent::delete command deletes a CA from the trusted keystore of the Control-M/Agent based on the provided aliases.

Before the first time that you use CA management commands, see the note in config ca:server:agent:list::get and ensure that you have performed the necessary setup.

  • CLI

  • REST

ctm config ca:server:agent::delete <server> <agent> <aliases>

ctm config ca:server:agent::delete server1 agent1 '{"aliases":[{"name":"AliasName1"},{"name":"AliasName2"},{"name":"AliasName3"}]}'

The following example shows the REST API syntax for the config ca:server:agent::delete command in cURL:

Copy
server=controlm
agent=quickstart
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json" -X DELETE "$endpoint/config/ca/server/$server/agent/$agent" \
--form 'aliases=@"/C:/Temp/aliases.json"' 

To determine the correct AuthHeader value—"Authorization: Bearer $token" or "x-api-key: $token"—see Authentication Tokens.

The following table describes the config ca:server:agent::delete command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

agent

Defines the Agent hostname or alias. This is the logical name of the Agent.

alias

Defines the names of aliases for the CA or CA chain that you want to delete. The list is in JSON format, as in the following example:

Copy
{"aliases":
  [
    {"name":"AliasName1"},
    {"name":"AliasName2"},
    {"name":"AliasName3"}
  ]
}

Aliases must not contain space characters.

If annotation is enabled for the Configuration Management category in the CCM or Configuration domain, you must also provide an annotation to justify your action. For more information, see Annotation Input.