Skip to main content

​
Approval Workflow

The approval workflow is CertForge’s governance layer. When a Domain Trust Profile requires approval, every certificate request is queued for human review before any certificate is issued. No certificate reaches a CA without sign-off.

​
Why approval matters

Without a governance layer, any authorized device or script can request and receive a certificate immediately. The approval workflow ensures that:
  • A human reviews what domain is being requested and why
  • The requester’s justification is recorded in the audit trail
  • Mistakes (wrong domain, wrong CA, wrong environment) are caught before issuance
  • Compliance requirements for change management are met

​
Request lifecycle

1. Request submitted (device, dashboard, API)
         │
         ▼
2. DTP matched → approval required?
         │
    Yes  │  No
         │   └──► Certificate issued immediately
         ▼
3. Request enters pending queue
         │
         ▼
4. Approvers notified (if notification channels configured)
         │
         ▼
5. Approver reviews: domains, requester, justification, AI risk score, policy
         │
    ┌────┴────┐
    │         │
Approve    Reject (with reason)
    │         │
    ▼         ▼
6. Certificate    Request closed
   issued         Requester notified
         │
         ▼
7. Audit event written (actor, domains, justification, reason, outcome)

​
What approvers see

The Approvals page shows pending, approved, and rejected requests. Each request includes a pipeline step visualization showing where the request is in its lifecycle.
FieldDescription
Request IDUnique identifier for the approval chain
Requested byUsername / email of the requester
DomainsThe certificate’s subject alternative names
Trust ProfileWhich DTP matched
EnvironmentProduction, staging, dev, etc.
JustificationText the requester provided
Requested atTimestamp
AI risk scoreRisk level assessed by the AI engine (if enabled)
StatusPending / Approved / Rejected

​
AI risk assessment

When the AI engine is enabled by the platform administrator, CertForge scores each incoming approval request and displays a risk level (low, medium, high) along with reasoning. Risk factors include the domain name pattern, requested environment, requester history, and CA type. The AI score is advisory — approvers can approve or reject regardless of the score. The score and reasoning are stored permanently in the audit trail.

​
Predefined approval reasons

Approval reasons provide a controlled vocabulary for approval and rejection decisions. There are two reason types:
TypeWhen used
approvalSelected by the approver when approving or rejecting a request
requestedSelected by the requester when submitting a request
Reasons are configured in Admin → Approval Reasons. When Mandatory approval reason is enabled on a DTP (or enforced by a compliance framework), the approver must select a reason before the decision can be submitted. If no active reasons of the appropriate type are configured, a free-text field is shown instead.

​
Comments

Approvers can leave a comment on any request. Comments are visible to other approvers and to the requester once the decision is made. Comments are stored permanently in the audit trail.

​
Mandatory reason enforcement

The mandatory approval reason requirement can be enforced in two ways:
  • Per DTP: Enable Mandatory approval reason in the DTP’s Access Control settings. Applies only to requests matched to that DTP.
  • Via compliance framework: Assign a compliance framework (SOC 2, ISO 27001, PCI-DSS, HIPAA) at the org level. All four frameworks enforce mandatory approval reasons across all DTPs.

​
Escalation

When a request remains pending past the configured thresholds, CertForge notifies escalation contacts and shows an escalation badge on the request in the Approvals page. Escalation thresholds and contacts are configured per DTP.

​
Justification

When Require request justification is enabled on a DTP, the requester must provide a plain-text justification when submitting the request. The justification is stored permanently in the audit trail and is visible to all approvers.

​
Who can approve

Any user with the following roles can approve requests:
  • Org admin — can approve any request in the org
  • Org operator — can approve requests for DTPs they have admin-level DTP access on
Platform admins and superusers can approve across all organizations.

​
Audit chain integrity

Every approval action (submit, approve, reject, void) is written to an append-only ledger with a cryptographic hash chain. Each record includes the hash of the previous record. This makes the audit trail tamper-evident — any modification to a past record breaks the chain, which is detected on startup and on-demand. You can verify the chain integrity at Compliance → Audit Chain.

​
Void

An admin can void a pending request — this closes it without issuing a certificate. Voiding is logged with the actor’s identity and reason.

​
Notifications

When notification channels are configured, approvers receive notifications on new pending requests and requesters receive notifications on approval outcomes. Configure channels (Webhook, Slack, Microsoft Teams, Webex) in Admin → Settings → Notifications.

​
API-driven requests

Automated systems can submit requests via the mTLS API: 
POST /v1/enroll
Content-Type: application/json

{
  "domains": ["api.internal.corp.com"],
  "environment": "production",
  "justification": "New service deployment — ticket #1234"
}
The response includes the approval_id. The system can poll /approvals/{id} for status, or rely on the certificate being written to a known path once approved.