Skip to main content
A Signer is a single signing identity inside Code Signing. It bundles three things:
  • A code-signing certificate issued by a Certificate Authority
  • A list of members who are allowed to use it
  • An optional approval policy that decides whether signing needs sign-off
You’ll typically have one Signer per real-world signing concern, such as mobile-app-prod, firmware-release, or ci-staging-builds.

​
What’s in a Signer?

Certificate

The X.509 code-signing certificate the Signer uses, backed by an internal or external CA.

Members

Users, machine identities, and groups. Each member has an Administrator, Operator, or Auditor role on this Signer.

Approval policy

Optional. Decides whether signing needs approval, who approves, and how each approval is bounded. See Approvals.

Activity

Audit trail of every successful, failed, and denied signing operation.

​
Signer roles

RoleCapabilities
AdministratorEdit settings, manage members, edit the approval policy, pre-approve signing for others, sign, and export the certificate.
OperatorSign artifacts and submit signing requests. Export the certificate. Cannot manage members or the policy.
AuditorView members, activity, and the audit log. Export the certificate. Cannot sign or change anything.
The user who creates a Signer becomes its Administrator automatically.

​
Create a Signer

In Certificate Manager → Code Signing → Signers, click Create Signer. The wizard walks you through four steps in order.
1

Basics

Pick a name for the Signer and (optionally) describe what it’s for.
FieldDescription
Signer nameA short, slug-friendly identifier (lowercase, dashes). Example: mobile-app-prod. The PKCS#11 module shows this as the token label.
DescriptionOptional. What this Signer is for, in plain English. Example: iOS and Android production bundles.
Click Next to move on to the certificate.
2

Certificate

Infisical issues a fresh code-signing certificate for the Signer from one of your Certificate Authorities.
FieldDescription
Certificate AuthorityThe 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 NameThe legal name shown on the certificate, for example Acme Mobile, Inc.. Fixed once the certificate is issued. To change it you must reissue.
Key algorithmThe 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.
3

Members

Add the people and machine identities who will work with this Signer:
  • 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.
4

Approval policy

Decide whether this Signer needs approval before signing.
  • 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 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.

​
Signer statuses

StatusMeaning
PendingThe 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.
ActiveCertificate issued and bound. Signing works, subject to the approval policy.
FailedIssuance 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.
DisabledManually disabled. Signing is blocked. Re-enable from the Options menu.
ExpiredThe certificate’s notAfter has passed and no auto-renewal was configured (or the renewal failed). Reissue with a new validity period.

​
Edit a Signer

Open the Signer and choose Options → Edit settings. The edit sheet walks you through two steps.
1

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.
2

Edit certificate

Change the certificate parameters. Saving here can trigger a fresh issuance, so what’s editable depends on the Signer’s current status.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 ActiveOnce 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.
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.
Press Save to apply the changes.

​
Signing with a Signer

To sign with a Signer, use the PKCS#11 module (works with jarsigner, cosign, osslsigncode, signtool, and more) or call the Sign API directly.

​
FAQ

No. Every Signer has its own certificate. If you want different teams or different approval workflows against the same CA, create one Signer per team or workflow. Each gets its own certificate from that CA.
Disable is reversible. The Signer, its members, its policy, its history, and the certificate are all preserved; sign calls just get rejected. Re-enable to resume.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.
External CAs (AWS Private CA, Azure AD CS) issue asynchronously. Infisical polls the CA in the background and flips the Signer to Active once the certificate is delivered. If it stays Pending for more than a few minutes, hover the badge; the failure reason appears there once the polling job gives up.
Artifacts already signed remain valid as long as the certificate they were signed with is still valid and the verifier trusts the issuing CA’s chain. Deleting the Signer in Infisical only removes Infisical’s ability to sign new artifacts with that certificate; it doesn’t invalidate past signatures.

​
What’s next?

Approvals

Add approval steps and per-approval limits to a Signer.

PKCS#11 Module

Use jarsigner, cosign, osslsigncode, and friends with this Signer.