About certificate approval workflows¶
Certificate Approval Workflows offer a structured approach to validating certificate requests. These workflows support rule-based approvals, role-specific permissions, and automated notifications, among other features.
The certificate approval workflow includes the following key features:
- Rule-based workflow: Define rules that are applied to CA accounts, applications, or certificate issuing templates.
- Role-specific access: Only the System Administrator and PKI Administrator roles can manage rules.
- Sequential evaluation: Requests are evaluated in the order of rule priority, which you can easily change using drag-and-drop.
- Approval types: Choose from "All," "At Least," and assign an optional "Final Approver" for different approval scenarios.
- Exceptions: Override rules based on specific applications or requestors.
- Continue processing on exceptions: If a certificate matches an exception, you can stop processing further rules, or continue processing rules further down the sequential list.
- Rule immutability: Conditions within a triggered rule remain fixed for the request's lifecycle.
- Notifications: Automated emails are sent to relevant parties throughout the approval process.
- Auto rejection: If an approval is not acted on within a specified time frame, it will be rejected automatically. The default setting for this duration is three calendar days (inclusive of weekends, not limited to business days). However, this period can be adjusted to suit individual Approval Rule requirements.
Who can create approval workflows?¶
Control Plane administrators with Admin or PKI Administrator roles can create, edit, and delete approval workflows. They can also approve or reject certificate requests, regardless of rules set in a given workflow.
Users with the Resource Owner role can approve or reject requests if they are added as approvers, or are members of a team that has been added as an approver.
Users with the Guest role can only monitor certificate request statuses.
Understanding the approval and rejection process¶
After creating a certificate approval workflow, incoming requests that meet your approval's rules pass through the workflow.
- Approve/reject actions: any user with the Resource Owner role who is added as an approver or is a member of a team that has been added as an approver, can approve or reject a certificate request. System Administrator and PKI Administrator can approve or reject any request regardless of whether or not they were added as approvers.
- Notifications: automated emails are sent to relevant parties throughout the approval process. Email notification is dispatched to all approvers that need to approve or reject a request. The requester will receive notifications in the following scenarios: when their certificate request requires approval, when the request has been rejected, and when it has been approved and forwarded to the certificate authority (CA) for issuance.
- Status transitions: requestors view the status from the same inventory page. The status appears as In Approval, Pending, In Final Approval, and Rejected Approval. These statuses guide the approval journey.
- Rejection mechanics: approvers must confirm their rejections and enter a rationale.
- Auto Rejection: If an approver doesn't take action within the specified time frame, the request will be rejected automatically. Be aware that the timer doesn't take weekends or holidays into account.
- Resubmission: Approved, but failed certificate requests can be resubmitted. They bypass the approval workflow when resubmitted. Requests that were rejected cannot be resubmitted.
Take a look at the following table to quickly see how the combination of decisions from initial approvers and the Final Approver impacts a certificate request's final status:
| Approvers' Choices | "All" Condition | "At Least" Condition | Final Approver's Role | Final Outcome |
|---|---|---|---|---|
| All Approve | Moves to Final Approver if set | Moves to Final Approver if set | Approves | Approved |
| All Approve | Approved immediately | Approved immediately | Not Set | Approved |
| Some Approve | Stays in Approval | Moves to Final Approver if set | Approves | Approved |
| Some Approve | Stays in Approval | Moves to Final Approver if set | Rejects | Rejected |
| At Least One Rejects | Rejected immediately | Rejected immediately | N/A | Rejected |
| Final Approver Rejects | N/A | N/A | Rejects | Rejected |
In this table: - "All" Condition: All specified Approvers must approve the request. - "At Least" Condition: At least a certain number of Approvers must approve the request. - Final Approver's Role: The last step in the approval chain.
Understanding approval workflow notifications¶
Here's a list of scenarios when email notifications are sent throughout the certificate approval process. This can help you understand when and how you'll be notified about request statuses, approvals, rejections, and other key events.
- Initial notifications: sent to the requestor and the approvers when a certificate request matches a rule in a certificate approval workflow.
- Final approver: notified only after initial approvals are done.
- Reminders: sent to non-responsive approvers after 24 hours, for up to 3 days. (The default is 3 days, but this can be configured for each approval rule.)
- Automatic rejection: sent to the requestor if the request hasn't been approved in time.
- Approval/rejection: specific notifications are dispatched based on approver actions.
- Issuance: An email is sent to the requestor after the request is approved and has been sent to the CA.
Next steps¶
Review prerequisite steps and create a certificate approval workflow.