AwsLambda
Invoke an AWS Lambda function using IAM credentials or an assumed role. You can call the function directly using an AWS access key and secret, or optionally assume an IAM role using a Role ARN. The Lambda response is saved to a specified property for use in later workflow steps.
AzureFunction
Run a REST (API) request against an Azure Function supporting either anonymous or function key authentication. The REST request contents are embedded within the step and do not reference an external file. The function can be accessed anonymously if no key is provided or secured by supplying a function access key.
AzureFunctionOAuth
Run a REST (API) request against an Azure Function protected by OAuth authentication. The request includes OAuth tokens to authenticate the caller. The REST request contents are embedded within the step and do not reference an external file. A function access key is required. The key serves as a shared secret to verify that the request comes from a trusted system, adding an extra layer of security.
RESTRequest
Run a REST (API) request using Active Directory as an identity provider and Basic or Windows authentication. The REST request contents are embedded within the step and do not reference an external file.
OAuthRESTRequest
Run a REST (API) request using an OAuth identity provider and Token authentication. The REST request contents are embedded within the step and do not reference an external file.
EnrollStep (Enrollment Only)
Enroll for a certificate through Keyfactor Command. The enroll step may occur at any point during the workflow, but only one enroll step may be included in a given workflow. Conditions are not supported on an enroll step. If an enroll step is not added to an Enrollment workflow, one will be included automatically at the end of the workflow. No configuration parameters are required for this step type.
ExpirationRenewal (Expiration Only)
Renew an expired certificate through Keyfactor Command as part of an expiration alert workflow. A separate enrollment workflow is automatically initiated to enroll for the renewed certificate, and the renewal workflow will only be considered complete and successful if that enrollment step completes successfully.
Note: The Keyfactor Command Service (timer service) needs permissions to enroll on the CA and template used for renewal when this step is used.
Tip: To renew certificates against an EJBCA CA, the
Enforce unique DN setting needs to be turned off in the CA configuration both on the EJBCA instance and in
Keyfactor Command (see
The Basic Tab).
RevokeStep (Revocation Only)
Revoke a certificate through Keyfactor Command. The revoke step may occur at any point during the workflow, but only one revoke step may be included in a given workflow. Conditions are not supported on a revoke step. If a revoke step is not added to a Revocation workflow, one will be included automatically at the end of the workflow. No configuration parameters are required for this step type.
RequireApproval
Require approval for a workflow step before the step can be completed. The Require Approval step can require approval from a single approver or from multiple approvers. Approvers are determined by security roles specified directly in the step configuration or by tokens that resolve to security roles at runtime.
When this step runs, workflow execution pauses until the required number of approvals is received from users who are permitted to submit approval decisions, or until a single denial is received. After the approval decision is made, the workflow continues to the next step.
As part of this step, an email message is sent indicating whether the step was approved or denied, typically to the requester. This step does not include logic to send an email initiating the approval process. Use an Email step to notify users that approval is required.
When requiring approval for enrollment using workflow definitions in Keyfactor Command, templates should not be configured to require manager approval at the CA level in the certificate template. This is because the approval handling is fully controlled within Keyfactor Command. Configuring templates to require CA manager approval at the CA level when using a Keyfactor Command workflow require approval step would require approval both at the Keyfactor Command level and at the CA level, which can lead to unexpected behavior.
Important: Workflows that include approval steps are not supported with CA delegation. For more information, see
Delegation Section.
Note: Users who receive email notifications requesting approval must belong to a security role, or be resolved through a token, that is permitted to submit approval decisions for the workflow.
Email
Send an email message. This is a separate email message from those typically sent as part of a Require Approval step. You might send an email message as part of an enrollment request to notify approvers that a new request needs approval. The email messages can be customized to provide detailed information about, for example, the certificate request.
PowerShell
Run PowerShell commands within the confines of the workflow to populate variables with information to pass back to the workflow. The PowerShell script contents are embedded within the step. This step does not call out to an external script stored in the database. This provides a high level of security by limiting the number of standard PowerShell cmdlets that can be executed by the workflow step. A small number of PowerShell cmdlets have been made available in workflow steps of this type, including:
- ConvertFrom-Csv
- ConvertFrom-Json
- ConvertFrom-Markdown
- ConvertFrom-SddlString
- ConvertFrom-StringData
- ConvertTo-Csv
- ConvertTo-Html
- ConvertTo-Json
- ConvertTo-Xml
- ForEach-Object
- Get-Command
- Group-Object
- Select-Object
- Where-Object
- Write-Error
- Write-Host
- Write-Information
Write-Verbose
Note: By default, PowerShell suppresses Verbose messages. Add the following to your script to allow verbose messages:
$VerbosePreference = 'Continue'
- Write-Warning
Note: Output from PowerShell Write-* cmdlets is written to the Keyfactor Command API log.
Important: This step uses PowerShell 7 to run.
EnrollmentAgent (Enrollment Only)
On an enrollment (either CSR or PFX), create a resigned CSR to prepare an updated enrollment request for delivery to a Microsoft CA after a previous step in the workflow has been used to update either the SANs in the initial request, subject (DN) in the initial request or both. This step must be placed later in the workflow any steps to modify the SANs and/or subject. The SANs and subject may be modified with either of the PowerShell step types or a custom step type. The step creates a new CSR using the same public key as the original CSR using the updated SAN and/or subject values. It signs the new CSR with the certificate provided in the step's configuration.
For this type of step you will need an enrollment agent certificate available as a PKCS #12 (.PFX) file with included private key to import into Keyfactor Command. This can be a user certificate or a computer certificate (for example, generated from a copy of the Enrollment Agent template or the Enrollment Agent (Computer) template) and must have a Certificate Request Agent EKU.
Note: The built-in Enrollment Agent and Enrollment Agent (Computer) templates do not allow private keys to be exported by default. To create a PKCS #12 (.PFX) file, you must use a template that allows private key export or manually override the private key export setting.
Important: This step applies to Microsoft CAs only. If this step is added to workflow for requests directed to an EJBCA CA, it will fail on enrollment. Note that EJBCA supports submission of updated SAN or subject details as part of standard functionality.
UpdateMetadata
Update a metadata field in Keyfactor Command with either a static value or a value from a token from the worklow (see Substitutable Text Tokens for Workflow). If you use a token, it needs to be populated before the Update Metadata step runs.
CustomPowerShell
Run a PowerShell script that has been imported into the Keyfactor Command database. All scripts in the database that have been configured with the workflow category will be available for use.
Important: This step uses PowerShell 7 to run by default. Some cmdlets that run in earlier versions of PowerShell are not compatible with PowerShell 7. If you need to use a PowerShell cmdlet that is not compatible with PowerShell 7, you may need to activate the PowerShell 5.1 option. PowerShell 5.1 is not supported on Keyfactor Command servers running in a non-Windows environment.
Important: This step type is not supported when running Keyfactor Command in containers under Kubernetes. Use step type Set Variable Data instead.
SubjectFormatter (Enrollment Only)
When an enrollment is performed through the Keyfactor Windows Enrollment Gateway using a client-side template configured with Build from this Active Directory information, this workflow step formats the incoming subject, SANs, and/or SID so that the certificate request is accepted by the target CA and the mapped Keyfactor Command template, which is not configured to build from Active Directory.
Any client-side template used by the Keyfactor Windows Enrollment Gateway that builds the subject from Active Directory must have a workflow step of this type configured on the corresponding Keyfactor Command template mapped in the gateway.
This workflow step has no configuration parameters
NOOPStep
An entry or exit step in which no operation occurs. Steps of this type indicate the start and end of the workflow.
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./Definitions/Steps/{extensionName} operation retrieves the workflow definition step structure for the step with the specified extensionName. Its primary use case is to populate the Management Portal dialog in which step information is configured. When you are developing a custom workflow step, it can be used to confirm that the workflow step will display correctly in the Management Portal. On success, the operation returns HTTP 200 OK with information about the structure of the workflow definition step.
) in the Management Portal.