Approvals¶

When a request needs a human decision, it waits in the approval queue of the certificate's organization. Any approver of that organization can decide. The requester never chooses who approves.

When a request needs approval¶

Situation	Approval
The certificate profile requires approval	Required for a new certificate, a renewal and a revocation
An issuance policy rule requires approval	Required, even if the profile does not; the approver sees the reason ("Approval required by a policy")
The issuance policy cannot be evaluated (internal error)	Required on interactive requests (fail-closed), and the error is audited (`POLICY_EVAL_ERROR`)
The request arrives through ACME, EST, SCEP or CMP, on a profile enabled for that protocol	Not required: the protocol's own proof replaces it (ACME challenge, EST client authentication, CMP message protection, single-use SCEP challenge)

Details on the protocol case:

The exemption applies only to requests that actually arrive through the protocol gateway. A request made in the web interface on the same profile still needs approval.
A policy rule that blocks applies to protocol requests too. A rule that requires approval cannot stop an automated request: it is let through and recorded as POLICY_AUTO_ALLOWED (outcome failure, so that it stands out in the SIEM).

Requests from ServiceNow follow exactly the same rules as a request made by the person in PKIFactor.

A request that needs approval must have an organization, and that organization must be active.

Who can decide¶

Person	Can approve or reject
An approver assigned to the organization (Organizations and teams)	Requests of that organization
A deputy, during an active delegation (below)	Requests of the delegated organizations
An administrator who is also an approver of the organization	Requests of that organization, like any approver
An administrator who is not an approver of the organization	Only if Approval decisions by a non-validator administrator is set to Allowed, with a mandatory reason (below); forbidden by default
Operators, auditors, users	No

The normal way to let an administrator approve is to assign them as an approver of the organization (an account can hold both roles).

Segregation of duties: nobody can approve their own request, administrators included. For a revocation, the person who asked for the revocation cannot approve it either. The attempt is refused with the message "Séparation des rôles : vous ne pouvez pas approuver votre propre demande." (code POLICY_VIOLATION).

An organization with a single approver is blocked whenever that approver is the requester or is away: assign at least two approvers, or use delegations.

Administrator decision¶

An administrator is not part of an organization's approval queue unless they are one of its approvers, and does not receive its notifications. To unblock a situation (approver and deputy both away), an administrator can still decide on a request of an organization where they are not an approver, under these conditions:

The setting Approval decisions by a non-validator administrator (System > Settings, General section) is set to Allowed, with a mandatory reason. The default is Forbidden (strict separation of duties).
The administrator gives a Reason for the decision of at least 10 characters (500 at most). For a rejection, the rejection reason can serve as the reason.
The decision is recorded separately in the audit trail (APPROVAL_OVERRIDE, with the reason), and the organization's approvers receive the approval_override_notice e-mail.

When the setting allows it, administrators who are not approvers see Requests > Approvals in the RA workspace. In that queue, requests of organizations where they are not an approver show Decide instead of Approve and Reject; it opens the review page, which shows the Administrator decision notice and the reason field. When the setting forbids it, the attempt fails with "Decisions by a non-approver administrator are disabled: only the organisation's approvers can decide (Settings → Security).".

Notifications¶

When a new request, a renewal or a revocation enters the queue, the organization's approvers receive the approval_pending e-mail, and the requester of a new certificate receives cert_requested. See E-mail and notifications.

Who is not notified

Deputies during a delegation, and administrators who are not approvers of the organization, do not receive the approval_pending e-mail. Deputies should check Approver Inbox > Pending regularly.

Work the queue¶

Approvers find the queue in the RA workspace under Approver Inbox > Pending (also Approved and Rejected). An administrator who is not an approver finds it under Requests > Approvals, only when administrator decisions are allowed.

The list shows the Organization, Action, Common Name, Template, Risk (Low for a new request, Medium for a renewal, High for a revocation), Requested date and Claimed by. Optional columns can be added: Requester, Profile, Key algorithm and Issuing CA. Each row's menu offers View Details, Claim or Release, and quick Approve and Reject buttons.

Claim a request¶

Claim marks a request as yours, so that the other approvers know someone is on it. It is advisory: any approver of the organization can still decide. A request claimed by someone else cannot be claimed again until that person (or an administrator) clicks Release.

Review and decide¶

Click View Details. The review page shows:

Section	Content
Request Information	Common name, profile, requester, date, action. Origin, when the request came from the ServiceNow catalogue, with the ticket number. The policy reason, when a policy forced the approval
Requested Changes	For a renewal, the fields that differ from the previous certificate (Before / After)
Immutable Request Snapshot	The request as submitted, with its SHA-256 hash
Approver Decision	The approval and rejection buttons, the Rejection Reason field and, for an administrator decision, the Reason for the decision field

A banner gives the risk of the action: Standard Request, Medium-Risk Action (renewal) or High-Risk Action (revocation, irreversible).

Then:

Approve Request: a new certificate or a renewal is issued, and the deployments bound to the certificate are triggered; a revocation is carried out at the authority. The requester receives cert_issued or cert_revoked.
Reject Request, with a Rejection Reason: a new certificate or a renewal is marked rejected. Rejecting a revocation leaves the certificate valid and issued.

Before issuing, PKIFactor checks that the snapshot has not been altered, and that what will be issued is what was approved, by the same authority. A mismatch stops the approval and is audited (APPROVAL_DEMANDE_ALTEREE, APPROVAL_LIAISON_ROMPUE, APPROVAL_LIAISON_ABSENTE).

Requesters follow their own requests under Requests > My requests.

Delegations¶

A delegation lets an approver lend their own approval authority to a deputy while away. It is meant for organizations with a single approver; with several approvers, the shared queue already covers an absence.

Open Approver Inbox > Delegations and click New delegation.
Deputy (email): the person must already hold the Approver role (or be an administrator). A delegation lends a scope, never a role.
Organization: one of your organizations, or All my organizations.
Start and End (optional): outside this window the delegation has no effect.
Reason (optional), then Create delegation.

Rule	Effect
Own authority only	You delegate only organizations where you are an approver yourself. An administrator can create a delegation on behalf of an approver
No escalation	The deputy gets only the organizations where the delegator is an approver at the time of the check. If the delegator loses that assignment, the delegation stops counting
No chaining	A deputy cannot pass the borrowed authority on to someone else
Segregation of duties	A deputy cannot approve their own request either
Revocation	The delegator or an administrator clicks Revoke; the effect is immediate

The page lists the delegations you granted or received (all of them for an administrator), with their window and status.

Emergency revocation by an operator¶

An operator who holds the Revoke permission (granted by default, see Users and roles) can revoke an issued certificate within their scope immediately, without going through the queue. A certificate outside their scope is refused ("Certificat hors de votre périmètre"). If the authority cannot be reached, the certificate is still marked revoked in PKIFactor and the error is kept in the record. The revocation is audited (CERTIFICATE_REVOKED with operator_override).

Via the API

# Queue of my organizations (PENDING, APPROVED or REJECTED)
curl -s -b jar "https://clm.example.com/api/v1/certificates/approvals?status=PENDING"
curl -s -b jar https://clm.example.com/api/v1/certificates/approvals/88    # detail by approval id

# Decisions take the CERTIFICATE id
curl -s -b jar -X POST https://clm.example.com/api/v1/certificates/486/claim
curl -s -b jar -X POST https://clm.example.com/api/v1/certificates/486/approve
curl -s -b jar -X POST https://clm.example.com/api/v1/certificates/486/reject \
  --data-urlencode "comment=Wrong common name"                             # form field
curl -s -b jar -X POST https://clm.example.com/api/v1/certificates/486/release

# Administrator decision outside their own organizations (when allowed)
curl -s -b jar -X POST https://clm.example.com/api/v1/certificates/486/approve \
  --data-urlencode "override_reason=Approver on leave, go-live blocked"

# Emergency revocation by an operator (form fields)
curl -s -b jar -X POST https://clm.example.com/api/operator/certificates/486/revoke \
  --data-urlencode "reason=keyCompromise"

# Delegations (form fields; dates in ISO 8601)
curl -s -b jar -X POST https://clm.example.com/api/v1/validator-delegations \
  --data-urlencode "delegate_email=alice@example.com" \
  --data-urlencode "organization_id=12" \
  --data-urlencode "starts_at=2026-11-02T00:00:00" --data-urlencode "ends_at=2026-11-13T23:59:00" \
  --data-urlencode "reason=Leave"
curl -s -b jar -X POST https://clm.example.com/api/v1/validator-delegations/5/revoke

Audit¶

Decisions and their context are recorded: CERTIFICATE_REQUEST_PENDING, APPROVAL_CLAIMED, APPROVAL_RELEASED, CERTIFICATE_APPROVED_ISSUED, CERTIFICATE_REJECTED, CERTIFICATE_REVOKED, POLICY_REQUIRE_APPROVAL, APPROVAL_OVERRIDE, VALIDATOR_DELEGATION_CREATED, VALIDATOR_DELEGATION_REVOKED. Each approval record keeps its snapshot and hash, which the audit trail can re-verify at any time.

Troubleshooting¶

Symptom	Cause and fix
The approver does not see the request	The approver is not assigned to the certificate's organization. Assign them on the organization page
"Séparation des rôles : vous ne pouvez pas approuver votre propre demande."	The approver is the requester (segregation of duties). Another approver or a deputy must decide
"Decisions by a non-approver administrator are disabled…"	The administrator is not an approver of this organization and administrator decisions are forbidden. Assign them as approver, or allow administrator decisions in System > Settings
"State the reason for your decision (at least 10 characters)."	Administrator decision without a sufficient reason
"Demande déjà prise en charge par un autre validateur."	Someone else claimed the request. You can still approve or reject it; to claim it, ask them (or an administrator) to release it
The request was refused at submission: "Une organisation cible (organization_id) est requise pour ce profil à approbation."	The profile requires approval but no organization could be determined. Check the profile's visibility and the requester's organizations
Approval fails with an integrity error	The request or the profile's authority changed after submission. Reject the request and have it submitted again
A deputy cannot create a delegation: "Le suppléant doit avoir le rôle validateur pour traiter des approbations."	Give the deputy the Approver role first
A delegation exists but the deputy sees nothing	The window has not started or has ended, the delegation was revoked, or the delegator is no longer an approver of that organization
Requests pile up after an approver left	Assign another approver to the organization; the queue is shared, nothing is lost