Approval workflows add a human review step before certificates are issued. Use them to enforce separation of duties, ensure oversight of sensitive certificates, or meet compliance requirements.Documentation Index
Fetch the complete documentation index at: https://infisical.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
When to Use Approvals
Separation of duties
Different people must request and approve certificate issuance.
Sensitive certificates
Production or customer-facing certificates need additional review.
Compliance requirements
Regulatory frameworks require documented approval before issuance.
Prevent unauthorized issuance
Ensure certificates are only issued after proper validation.
For fully automated workloads (e.g., using Infisical Agent), enable the machine identity bypass option so automated systems can issue certificates without waiting for approval.
How Approval Policies Work
An approval policy defines the workflow that must be completed before certificates are issued. Policies are configured per Application and can be scoped to specific profiles attached to that Application. When a certificate request is made through an enrollment method:- Request enters pending state
- Approvers are notified (if configured)
- Each approval step must be completed in sequence
- Once all steps are approved, the certificate is issued
Create an Approval Policy
In your Application, go to the Settings tab and find the Approval Policies section. Click Create Policy.Configure basic settings
| Field | Description |
|---|---|
| Policy Name | A descriptive name like production-cert-approval |
| Max. Request TTL | How long a request can remain pending before expiring |
| Certificate Profiles | Which profiles require approval |
| Bypass for machine identities | Allow automated systems to skip approval |
Configure approval steps
Each step defines who can approve and how many approvals are required:
Example multi-step workflow:
| Field | Description |
|---|---|
| Step Name | Optional name like Security Team Review |
| Approvers | Users or groups eligible to approve |
| Required Approvals | How many must approve (e.g., 2 of 5) |
| Notify Approvers | Send notification when approval is needed |
- Team Lead Review — Requires 1 approval from team leads
- Security Review — Requires 2 approvals from security team
Managing Approval Requests
View Requests
In the Certificate Manager sidebar, go to Approval Requests to see all pending and completed requests:| Status | Meaning |
|---|---|
| Open | Pending approval |
| Approved | All steps completed, certificate issued |
| Rejected | An approver rejected the request |
| Cancelled | Requester cancelled the request |
| Expired | Request exceeded max TTL |
Approve a Request
Review certificate details
Verify the request information:
- Requester name and email
- Certificate profile
- Common name and SANs
- Key usages and validity period
Reject a Request
When a request is rejected, the workflow ends and no certificate is issued.
FAQ
I approved a request but the certificate wasn't issued
I approved a request but the certificate wasn't issued
If the policy has multiple steps, your approval may have completed only one step. The certificate is issued only after all approval steps are completed. Check the request details to see which step is currently pending.
I don't see the Approve button
I don't see the Approve button
Can I use approvals with ACME or EST?
Can I use approvals with ACME or EST?
Yes, approval policies work with any enrollment method. However, automated clients like Certbot typically can’t wait for human approval. Consider using the machine identity bypass for automated workloads.
What happens when a request expires?
What happens when a request expires?
The request moves to Expired status and no certificate is issued. The requester must submit a new request.
Can requesters approve their own requests?
Can requesters approve their own requests?
By default, yes — if they’re listed as an eligible approver. For separation of duties, configure approver groups that exclude potential requesters.