POST Certificate Stores Approve

The POST /CertificateStores/Approve method is used to approve one or more certificate stores currently in the pending state—having been discovered using the certificate store discover option (see PUT Certificate Stores Discovery Job). If more than one certificate store is included in the array, all stores must be of the same store type (e.g. Java keystore). This endpointClosed An endpoint is a URL that enables the API to gain access to resources on a server. returns 204 with no content upon success.

Tip:  The following permissions (see Security Roles and Claims) are required to use this feature:
/certificate_stores/modify/
OR
/certificate_stores/modify/#/ (where # is a reference to a specific certificate store container ID)

Permissions for certificate stores can be set at either the global or certificate store container level. See Container Permissions for more information about global vs container permissions.

Table 398: POST Certificate Stores Approve Input Parameters

Name In Description
Id Body

Required. The GUID of the pending certificate store.

Use the GET /CertificateStores method (see GET Certificate Stores) with a query of “Approved -eq false” to retrieve a list of all your unapproved certificate stores to determine the GUID of the store.

ContainerId Body

An integer that identifies the container in which the certificate store should be placed on approval. Use the GET /CertificateStores/Containers method (see GET Certificate Store Containers) to retrieve a list of your defined certificate store containers to determine the container ID to use.

CertStoreType Body Required. An integer indicating the ID of the certificate store type, as defined in Keyfactor Command, for this certificate store. Built-in certificates store types are: (0-Javakeystore, 2-PEMFile, 3-F5SSLProfiles,4-IISRoots, 5-NetScaler, 6-IISPersonal, 7-F5WebServer, 8-IISRevoked, 9-F5WebServerREST, 10-F5SSLProfilesREST, 11-F5CABundlesREST, 100-AmazonWebServices, 101-FileTransferProtocol). Any custom extensions for the Keyfactor Universal Orchestrator you add will have certificate store types numbered 102+.
Properties Body

Required*. Some types of certificate stores have additional properties that are stored in this parameter. The data is stored in a series of, typically, key value pairs that define the property name and value (see GET Certificate Store Types for more information).

When reading this field, the values are returned as simple key value pairs, with the values being individual values. When writing, the values are specified as objects, though they are typically single values.

For example, on a GET request for a PEM store configured with a separate private key, the contents of this field might be:

"{
  \"privateKeyPath\":\"/opt/app/mystore.key\",
  \"separatePrivateKey\":\"true\"
}"

However, the syntax used when updating the properties sets the value as a key value pair using value as the key. For example, on a POST or PUT request for a PEM store configured with a separate private key, the contents of this field might be:

Copy
{
   \"privateKeyPath\":{\"value\":\"/opt/app/mystore.key\"},
   \"separatePrivateKey\":{\"value\":\"true\"}
}

An example server properties parameter POST for an F5 or Citrix NetScaler store would contain:

Copy
"{
   \"ServerUsername\":{\"value\":{\"SecretValue\":\"KEYEXAMPLE\\\\jsmith\"}},
   \"ServerPassword\":{\"value\":{\"SecretValue\":\"MySuperSecretPassword\"}},
   \"ServerUseSsl\":{\"value\":\"true\"}
}"

An example server properties parameter POST for an F5 or Citrix NetScaler store with the username and password stored as PAM secrets would contain (where the Provider value—1 in this example—is the Id value from GET PAM Providers):

Copy
"{
   \"ServerUsername\":{\"value\":{\"Provider\":\"1\",\"Parameters\":{\"SecretId\":\"MyUserID\"}}},
   \"ServerPassword\":{\"value\":{\"Provider\":\"1\",\"Parameters\":{\"SecretId\":\"MyPasswordID\"}}},
   \"ServerUseSsl\":{\"value\":\"true\"}
}"
Note:  There are three standard properties that are used for certificate store types that require server credentials (e.g. F5):
  • ServerUsername
  • ServerPassword
  • ServerUseSsl

These replace the separate certificate store server records that existed in previous versions of Keyfactor Command. For legacy support, if credentials are not provided through store properties during creation or editing of a certificate store, Keyfactor Command will attempt to find a certificate store server record and copy the credentials from it into the store properties for future use.

This field is required for certificate store types that store additional properties in this parameter.

InventorySchedule Body

An object indicating the inventory schedule for this certificate store. ClosedShow schedule details.

Password Body

Required. An object indicating the source for and details of the credential information Keyfactor Command will use to access the certificates in a specific certificate store (the store password). This is different from credential information Keyfactor Command uses to access a certificate store server as a whole. The former (this setting) is typically used for Java keystores; the latter is typically used for certificates stores in Windows certificate stores and on Citrix NetScaler and F5 devices and set at the server level, not the certificate store level.

Certificate stores that require credentials support up to three possible credential options:

  • Use no store password.

    This option is supported for Java keystores that would normally require a password, but can be configured with the no password option (see Value, below).

  • Store the credential information in the Keyfactor secrets table.

    A Keyfactor secret is a user-defined password that is encrypted and stored securely in the Keyfactor Command database.

  • Load the credential information from a PAM provider.

    See Privileged Access Management (PAM) and PAM Providers for more information.

ClosedShow password details.

This field is required for Java keystores.

Tip:  See the Keyfactor API Reference and Utility which provides a utility through which the Keyfactor APIClosed An API is a set of functions to allow creation of applications. Keyfactor offers the Keyfactor API, which allows third-party software to integrate with the advanced certificate enrollment and management features of Keyfactor Command. endpoints can be called and results returned. It is intended to be used primarily for validation, testing and workflowClosed A workflow is a series of steps necessary to complete a process. In Keyfactor Command, it refers to the workflow builder, which allows you to automate event-driven tasks such as when a certificate is requested, revoked or found in a certificate store. development. It also serves secondarily as documentation for the API. The link to the Keyfactor API Reference and Utility is in the dropdown from the help icon () at the top of the Management Portal page next to the Log Out button.