Workflow object settings

The following table describes the certificate workflow object settings.

Certificate Settings

Field

Description

Conditions

If Stage Is

Applies the workflow actions at the designated stage of the object lifecycle.

The default lifecycle stages are as follows. Individual stages may vary per application. For information on certificate lifecycle stages for each application, see Protecting server platforms and keystores.

If the private key and CSR are locally generated on the server, stages 0-700 are performed by the default X.509 Certificate Application driver. Stages 0-700 are only performed by the certificate’s consumer Application driver if the private key and CSR are remotely generated on the certificate’s consumer application.

NOTE The private key and CSR are remotely generated on the certificate’s consumer applications if the Generate Key/CSR on Application option is enabled in the Certificate object.

Certificate Stage Codes

Workflow Stage codes
Stage Code	Friendly Name	Description
0	StartProcessing	Prepares the certificate for lifecycle processing.
100	CheckStore	Applies only to remote generations. If the private key and CSR are generated remotely, Trust Protection Platform compares the keystore or Directory configuration parameters specified in the Application object with the actual configuration on the application.
200	CreateConfigureStore	Applies only to remote generations. If the certificate keystore does not exist, Trust Protection Platform creates the keystore as per the configuration parameters defined in the Application object.
300	CreateKey	Creates the private key. DID YOU KNOW? Stage 300 is used for key generation only when the API of a target device separates keypair and CSR generation. When they're combined, both key and CSR generation are always done at stage 400.
400	CreateCSR	Creates the Certificate Signing Request (CSR). If Service Generated CSR is enabled and the certificate is associated with multiple applications, the CSR will be centrally generated so Trust Protection Platform can push the private key to multiple applications.
500	PostCSR	Submits the CSR to the Certificate Authority (CA). If you post a manual CSR, this is the first stage of the certificate lifecycle.
600	ApproveRequest	Approves the certificate renewal at the CA.
700	RetrieveCertificate	Retrieves the certificate from the CA.
800	InstallCertificate	Installs the certificate on the target application. This provisioning happens in several stages, such as 801, 802, etc. All stages between 800-899 are provisioning stages.
900	CheckConfiguration	Reserved for future use. You cannot apply this stage to a workflow.
1000	ConfigureApplication	Reserved for future use. You cannot apply a stage to this workflow.
1100	RestartApplication	Used for command injection workflow that must be executed after a certificate has been successfully provisioned.
1200	EndProcessing	Completes the certificate processing and, if configured, runs a Validation check on the certificate and application.
1400	Revocation	Submits a revocation request to the CA. Certificate revocation is a certificate operation; it does not involve the application driver.
1500	UpdateTrustStore	Updates the Trust Store at the host to comply with the effective bundle. To learn more, see Viewing the Effective Bundle.
1600	EndTrustStoreProcessing	Completes the processing of the Trust Store.

If Application or Trust Store Is

Applies the workflow actions only to certificates installed on a specific type of application.

Actions

Inject Commands

Under the designated conditions, Trust Protection Platform executes the defined commands on the certificate’s consumer application.

Trust Protection Platform is able to run local SSH commands against the following applications:

A10 AX Traffic Manager
Apache
F5 LTM Advanced
IBM GSK
Imperva MX
JKS

Layer 7 SSG
Oracle iPlanet
PEM
PKCS#12
Tealeaf PCA

Trust Protection Platform is able to run PowerShell commands over WinRM for the CAPI application.

After Trust Protection Platform executes the command, the application driver logs an Inject Command Success or Inject Command Failure event so you can determine if the command successfully executed on the target application. The Inject Command Success event returns a value of zero (0) in the event’s Value2 field. An Inject Command Failure event returns a non-zero numeric value in the Value2 field. To provide automatic notification for Inject Command Failure events, you can create a Notification Rule that triggers on a value greater than zero in the event’s Value2 field.

For more information, see Creating notification rules.

Request Approval From

Under the designated conditions, Trust Protection Platform submits an approval request to the workflow approver.

You can request approvals for certificate renewals or workflow injection commands.

The following options allow you to define the workflow approver.

Approver Assigned to Object

Defines a dynamic approver for the current Workflow object. Depending on which stage of the certificate lifecycle triggers the Workflow, Trust Protection Platform reads the workflow approvers from the certificate’s Certificate object or consumer Application object or from the Certificate or Application tab of the certificate’s parent Policy object.

The rules for where Trust Protection Platform reads the workflow approver are as follows:

If the private key and CSR are locally generated on the Trust Protection Platform server and the workflow is triggered at stages 0-700 of the certificate lifecycle, Trust Protection Platform reads the approver from the Certificate object. At stages 800-1200, Trust Protection Platform reads the approver from the certificate’s consumer Application objects.
If the private key and CSR are remotely generated on the certificate’s consumer applications, Trust Protection Platform always reads the approver from the certificate’s consumer Application objects.

The private key and CSR are remotely generated on the certificate’s consumer applications if the Generate Key/CSR on Application option is enabled in the Certificate object.

For example, if the Workflow object is triggered at stage 100 of the certificate lifecycle and the private key and CSR are centrally generated, Trust Protection Platform reads the approver from the certificate’s associated Certificate object. If the Workflow object is triggered at stage 800 of the certificate lifecycle, Trust Protection Platform reads the approver from the certificate’s consumer Application objects.

Specified Approver

Defines a static approver for the current Workflow object.

To select the workflow approvers:

In the Specified Approver(s) field, click the Browse button.

The Identity Selector dialog opens.

If the Identity Selector dialog is not populated, enter a search query to retrieve the Identity list. The administration console does not automatically display external users and groups.

IMPORTANT The group must be a Security group.

You must first enter a search string so Trust Protection Platform can query the external Identity store and return the list of requested users or groups.If you want to display all user or group entries, enter the wildcard character (*).
Select a Security Group Identity, and then click Select.

Press Shift+click to select multiple, contiguous certificates.

Press Ctrl+click to select multiple, discontiguous certificates.

NOTE If you change the approver for an item that is pending approval, the update may take up to four hours to complete. Changing this setting can adversely affect performance of the system. If you need to change this setting contact Venafi Support.

Specify approver via macro

Allows you to enter a macro to dynamically select the workflow approver when the workflow is triggered.

For more information on the Trust Protection Platform macro language, see the Venafi Trust Protection Platform Macro Guide.

Approval Reason Code

Reason Code you want to include with the notification that is sent to the workflow approver. The maximum Approval Reason Code value is 999.

IMPORTANT This option is required if you select Request Approval From.

Approval Reason Codes also accompany customized explanations or instructions for workflow approvers. The drop-down list displays the Reason Codes defined in the Workflow tree. For more information, see Defining reason codes for certificate approvals.

General Tab

Log

Provides a view of all events triggered for the current object.

An administrator must have a minimum of the Read permission to view this tab.

For more information on the Log tab options, see General configuration options.

Permissions

On the object permissions tab, you select the users or groups you want to have permissions to the current object, then you select which permissions you want the users or groups to have.

You can also manage object permissions via parent objects, including folder.If you configure Permissions in a parent object, those permissions are inherited by all subordinate objects.