docs/documentation/platform/pki/code-signing/signers.mdx
A Signer is a single signing identity inside Code Signing. It bundles three things:
You'll typically have one Signer per real-world signing concern, such as mobile-app-prod, firmware-release, or ci-staging-builds.
| Role | Capabilities |
|---|---|
| Administrator | Edit settings, manage members, edit the approval policy, pre-approve signing for others, sign, and export the certificate. |
| Operator | Sign artifacts and submit signing requests. Export the certificate. Cannot manage members or the policy. |
| Auditor | View members, activity, and the audit log. Export the certificate. Cannot sign or change anything. |
In Certificate Manager → Code Signing → Signers, click Create Signer. The wizard walks you through four steps in order.
<Steps> <Step title="Basics"> Pick a name for the Signer and (optionally) describe what it's for.| Field | Description |
|-------|-------------|
| **Signer name** | A short, slug-friendly identifier (lowercase, dashes). Example: `mobile-app-prod`. The PKCS#11 module shows this as the **token label**. |
| **Description** | Optional. What this Signer is for, in plain English. Example: *iOS and Android production bundles*. |
Click **Next** to move on to the certificate.
| Field | Description |
|-------|-------------|
| **Certificate Authority** | The CA that issues the certificate. Internal CAs issue immediately. External CAs (AWS Private CA, Azure AD CS) issue asynchronously and the Signer enters **Pending** until the cert lands. |
| **Common Name** | The legal name shown on the certificate, for example `Acme Mobile, Inc.`. Fixed once the certificate is issued. To change it you must reissue. |
| **Key algorithm** | The key for the signing certificate: `RSA-2048`, `RSA-3072`, `RSA-4096`, `ECDSA P-256`, `ECDSA P-384`, or `ECDSA P-521`. |
| **Validity (days)** | How long each issued certificate is valid for. Default 365. |
| **Renew before (days)** | Optional, 1 to 30. Auto-renew this many days before expiry. Must be less than Validity. Leave empty to disable auto-renewal. |
Click **Next** to add members.
- **User**
- **Machine Identity**: a non-human caller (CI runner, build job, deploy script). Operator is the typical role.
- **Group**: a directory group. Everyone in the group inherits the role on this Signer.
The user who creates the Signer is added as Administrator automatically and cannot be removed at creation time. You can manage members later from the Signer's **Members** tab.
Click **Next** to set up the approval policy.
- **No approval required**: leave the policy empty. Members with sign rights can sign immediately. Recommended for dev and internal Signers.
- **Add approval steps**: require one or more sign-offs. See [Approvals → Configure the approval policy](/documentation/platform/pki/code-signing/approvals#configure-the-approval-policy) for the step editor and per-approval limits.
Press **Create Signer** to finish. Infisical issues the certificate (synchronously for internal CAs, asynchronously for external CAs) and the Signer appears in the list with a status badge.
| Status | Meaning |
|---|---|
| Pending | The Signer is created but the certificate has not been issued yet. Most common with external CAs that take time to respond. The PKCS#11 module sees this slot but signing is rejected until the certificate lands. |
| Active | Certificate issued and bound. Signing works, subject to the approval policy. |
| Failed | Issuance failed. Hover the badge to see the reason. Use Retry issuance from the Options menu, or Edit a Signer to change the CA, Common Name, or Validity and try again. |
| Disabled | Manually disabled. Signing is blocked. Re-enable from the Options menu. |
| Expired | The certificate's notAfter has passed and no auto-renewal was configured (or the renewal failed). Reissue with a new validity period. |
Open the Signer and choose Options → Edit settings. The edit sheet walks you through two steps.
<Steps> <Step title="Edit basics"> Update the Signer's identifying information.- **Signer name**: rename freely. The PKCS#11 token label updates on the next refresh.
- **Description**: edit at will.
Click **Next** to edit the certificate.
**Always editable**
- **Certificate Authority**: swap to another CA. Saving with a different CA reissues the certificate immediately from the new CA.
- **Renew before (days)**: edit any time, 1 to 30, must be less than Validity.
**Locked once the Signer is Active**
Once a certificate is bound, the **Common Name**, **Validity (days)**, and **Key algorithm** are all locked together so the issued cert and the Signer's stored intent can't drift apart.
- While the Signer is **Pending** or **Failed** (no certificate bound yet), **Common Name** and **Validity (days)** are editable so you can fix bad inputs and try issuance again. **Key algorithm** is still read-only here.
- Once **Active**, all three fields show as read-only.
To change any of them on an Active Signer: swap the CA (reissues with the new CN/Validity if you also fix those before going Active again) or, for **Key algorithm**, create a new Signer with the algorithm you want.
<Note>
Renewals always issue a new certificate from the same CA with a fresh key pair. Old artifacts remain valid under the old certificate; new sign operations use the new one.
</Note>
Press **Save** to apply the changes.
To sign with a Signer, use the PKCS#11 module (works with jarsigner, cosign, osslsigncode, signtool, and more) or call the Sign API directly.
**Delete** is permanent. The Signer and everything attached to it (members, policy, access records, audit log) is removed. The certificate object remains in the inventory unless you delete that separately.