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

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 five steps in order: Basics, Certificate, Signing Key, Members, and Approval Policy.
1

Basics

Pick a name for the Signer and (optionally) describe what it’s for.Click Next to move on to the certificate.
2

Certificate

Choose which Certificate Authority issues the Signer’s certificate and the identity on it.
Some CAs add extra fields on this step. Check your CA’s documentation for any CA-specific options.
Click Next to choose the signing key.
3

Signing Key

Decide where the signing key lives and which algorithm to use.Click Next to add members.
4

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

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.

​
HSM-backed Signers

When you pick Key source = HSM on the Signing Key step, pick the HSM Connector Infisical should use. The Key algorithm choices narrow to the HSM-supported subset. The private key never leaves the HSM and every sign operation routes through the linked Connector. Infisical only holds the public key and the issued certificate. You can later switch an existing Signer between Infisical and HSM by reissuing the certificate with a different key source. Hit the reissue endpoint with a certificate.keySource body, plus hsmConnectorId when switching to HSM. The signer keeps its name, members, policy, and CA. Only the underlying key and the cert wrapping it change. See HSM Connectors for the setup.

​
Signer statuses

​
Edit a Signer

Open the Signer and choose Options → Edit settings. The edit sheet walks you through three steps: Basics, Certificate, and Signing Key. Changing the CA, identity, validity, or key triggers a fresh issuance, and the signer switches to the newly issued certificate.
1

Basics

Update the Signer’s identifying information. These never reissue the certificate.
  • 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

Certificate

Change which CA issues the certificate and its identity.
  • Certificate Authority: swap to another CA. Saving with a different CA reissues the certificate immediately from the new CA.
  • Reuse an existing order: offered by some CAs (DigiCert code signing). Point the Signer at an existing order to reuse that order slot instead of placing a new one. Common Name and Validity are inherited from the order.
  • Common Name and Validity (days): edit them to change the identity on the certificate. Saving reissues the certificate with the new values, and the signer switches to the new certificate.
  • Renew before (days): edit any time, 1 to 30, must be less than Validity.
Click Next to edit the signing key.
3

Signing Key

Change where the key lives or which algorithm it uses. Both reissue the certificate with a new key.
  • Key source: switch between Infisical and HSM. Switching to HSM requires picking an HSM Connector and a supported algorithm. CAs that require an HSM-backed key (such as DigiCert code signing) lock this to HSM.
  • HSM Connector: shown when Key source is HSM.
  • Key algorithm: pick a different algorithm. Changing it generates a new key and reissues the certificate.
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, pick the integration that matches your tooling:
  • PKCS#11 module for cross-platform tools (jarsigner, cosign, osslsigncode, apksigner, openssl, gpg, and more).
  • Windows KSP for native signtool Authenticode signing on Windows.
  • Sign API to sign directly over HTTP.

​
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, and 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, DigiCert) issue asynchronously. Infisical polls the CA in the background and flips the Signer to Active once the certificate is delivered. AWS and Azure usually take seconds. DigiCert takes minutes to hours for an already-validated organization, and up to 3 business days the first time an organization is used for code signing while DigiCert validates it. If it stays Pending well beyond those windows, 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 does not invalidate past signatures.
Yes. From the Signer detail page, open Edit Signer > Signing Key and change Key source. When switching to HSM, pick an HSM Connector and a supported algorithm (RSA-2048, RSA-4096, ECDSA P-256, or ECDSA P-384). Saving reissues the certificate with the new key. The signer keeps its name, members, approval policy, and CA. Only the key and the cert wrapping it change.The same operation is available via the reissue endpoint by passing certificate.keySource and (when switching to HSM) hsmConnectorId.The previous certificate stays in the inventory. Delete or retire the old certificate before you try to delete the HSM Connector it referenced.

​
What’s next?

Approvals

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

HSM Connectors

Route the Signer’s key operations to your own HSM.

PKCS#11 Module

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

Windows KSP

Sign with native signtool on Windows.