Applies to:
All versions of Venafi
Docs site regarding Workflow Setup
Summary:
Workflow processes can be used to halt the provisioning of a certificate while a specific application is rebooted, or to require approval for the purchase of a new certificate from a public Certificate Authority. Almost any trigger can be set at any stage of the certificate life cycle to ensure necessary approval is given, special ssh command are run, or an application is restarted thereby ensuring a healthy, viable Certificate rollout.
Application Workflows are defined in Workflow objects , but applied via Policy objects. Workflow and Policy objects are created and managed in the Policy tree. Each workflow object references a reason code, which is defined in the workflow tree. The Policy tree hierarchy is used to allow the influence of Workflow objects to flow down through the tree.
Venafi™ Encryption Director allows you to integrate workflow management processes with its management of certificate lifecycles. Using Workflow objects, you can require approvals or run SSH commands at stages of the certificate lifecycle. You can apply the workflows to an entire policy, or limit their action to only certificates associated with a specific application type such as a GSK keystore or Apache web server.
A workflow process can be configured to run commands, through the use of a SSH connection, against an application. We expect these commands will commonly be used to restart the application so as to bring the new certificate into production. Currently, Director is only able to run local commands against these applications:
- Apache
- Brocade
- Cisco ACE
- CSS
- IIS5
- GSK
- iPlanet
- JKS
- NetScaler.
More info:
This article attempts to layout the steps required to setup workflow object(s) in the Certificate Manger tree system.
You can broadly summarize the steps into three main stages:
- Creating your reason codes in the workflow tree.
- Creating and linking your workflow objects to certificates.
- Using the WebAdmin interface to approve your workflow processes.
1: Creating the reason codes in the workflow tree:
- Navigate to the workflow tree, and create a workflow ticket with reason code. This reason should make sense to the approver to which the request will be sent.
- This screenshot shows an approval code object being created in the workflow tree called "stop for approval" with a reason for stopping as 'Restart Apache". This would mean that the workflow would stop, and notify the approver reminding him to Restart Apache.
- Some other examples of text for reason codes may be:
- Please review this Certificate issuance request.
- This will restart the Apache server.
- This will restart the Tomcat application.
- This will restart linux.mydomainname.com
2: Creating and linking workflow objects in the policy tree:
- Once the approval codes have been created in the workflow tree, Navigate to the policy tree, and select where your workflow object will be created. It will need to be below a policy object.
- Click ADD > Workflow, and give the workflow object a name.
- Each workflow object will be triggered by one of these lifecycle stages, as listed in the appendix below. You will need to choose one per object.
- In this example we have chosen the 600 stage, and selected the previously created reason code object called stop for Approval. We have also chosen to request for approval from the object settings.
- Navigate to the policy object above the certificate objections in your tree. You will be configuring your workflow settings here so you can affect the certificates below.
- Select the workflow tab on this object which will bring you to this screen.
- In the Applied workflow area press 'add' and select the object created above.
- TIP: The area allows to choose you a workflow you want to block at this policy level.
3: Using the Webadmin interface to approve your workflow processes:
- The Webadmin user interface is the only way to work with ( approve/deny) pending workflow processes. You, however, must login with the right account. (Logging with the admin account will not help) This account is configured on the workflow object. See the workflow screenshot above for more details.
- Once you have logged in, navigate to the workflow tree and click on the pending requests.
- Read and approve as per the below screenshot.
Appendix:
Lifecycle triggers you can choose from:
TIP1: The numbers below are chosen with each workflow object. They allow you stop the the process at any of these chosen stages in the certificate lifecycle.
TIP2: The numbers 100 though to 500 are for keys created outside of the Certificate Manager software.
0 |
StartProcessing |
Prepares the certificate for lifecycle processing. |
100 |
CheckStore |
Applies only to remote generations. If the private key and CSR are generated remotely, Director 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, Director creates the keystore as per the configuration parameters defined in the Application object. |
300 |
CreateKey |
Creates the private key. |
400 |
CreateCSR |
Creates the Certificate Signing Request (CSR). |
500 |
PostCSR |
Submits the CSR to the Certificate Authority (CA). Note: 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. |
900 |
CheckConfiguration |
Reserved for future use. |
1000 |
ConfigureApplication |
Reserved for future use. |
1100 |
RestartApplication |
Reserved for future use. |
1200 |
EndProcessing |
Completes the certificate processing and, if configured, runs a Validation check on the certificate and application. |
Comments