Signers - Infisical — ContextQMD

A Signer is a named code-signing identity bound to an X.509 certificate with the codeSigning extended key usage (EKU). Signers represent signing capabilities—for example, release-signer for production releases or ci-signer for CI pipeline artifacts.

<Info> Signers are created by product admins. Team members are assigned to Signers and can then request signing access or sign directly (depending on policy). </Info>

Private keys never leave the Infisical server. When a signing operation is requested, the server retrieves the key, computes the signature, and returns only the signature bytes.

Key Characteristics

Feature	Description
Bound to certificate	Every signer must be linked to a certificate with the `codeSigning` EKU
Optional signing policy	Attach a signing policy to require approval before signing
RSA and ECDSA	Supports RSA (2048, 3072, 4096-bit) and ECDSA (P-256, P-384, P-521)
Audit trail	Every signing operation is recorded with actor, algorithm, and grant information

Create a Signer

<Steps> <Step title="Issue a code-signing certificate"> You need a certificate with the `codeSigning` extended key usage. Follow the [certificate issuance guide](/documentation/platform/pki/applications/certificates#issuing-certificates) and specify `codeSigning` in the extended key usage field.

<Note>
  Only certificates with the `codeSigning` EKU appear when creating a signer.
</Note>

</Step> <Step title="(Optional) Create a signing policy"> To require approval before signing, create a [Signing Policy](/documentation/platform/pki/code-signing/signing-policies) first.

Without a policy, any authorized user or identity can sign immediately.

</Step> <Step title="Create the signer"> Go to **Certificate Manager → Code Signing → Signers** and click **Create Signer**.

Fill in the following fields:

- **Name**: A slug-friendly name for the signer such as `release-signer`.
- **Description**: An optional description of the signer's purpose.
- **Certificate**: The code-signing certificate to bind to this signer.
- **Signing Policy** (optional): The signing policy that governs signing access for this signer. If omitted, signing is allowed without approval.

Press **Create** to save the signer.

</Step> </Steps>

Supported Signing Algorithms

The available signing algorithms depend on the certificate's key type:

RSA

Algorithm	Description
`RSASSA_PKCS1_V1_5_SHA256`	RSA PKCS#1 v1.5 with SHA-256
`RSASSA_PKCS1_V1_5_SHA384`	RSA PKCS#1 v1.5 with SHA-384
`RSASSA_PKCS1_V1_5_SHA512`	RSA PKCS#1 v1.5 with SHA-512
`RSASSA_PSS_SHA256`	RSA-PSS with SHA-256
`RSASSA_PSS_SHA384`	RSA-PSS with SHA-384
`RSASSA_PSS_SHA512`	RSA-PSS with SHA-512

ECDSA

Algorithm	Description
`ECDSA_SHA256`	ECDSA with SHA-256
`ECDSA_SHA384`	ECDSA with SHA-384
`ECDSA_SHA512`	ECDSA with SHA-512

Signing via API

You can also sign data programmatically by making an API request to the Sign endpoint:

bash

curl --request POST \
  --url https://app.infisical.com/api/v1/pki/signers/{signerId}/sign \
  --header 'Authorization: Bearer <access-token>' \
  --header 'Content-Type: application/json' \
  --data '{
    "data": "<base64-encoded-data>",
    "signingAlgorithm": "RSASSA_PKCS1_V1_5_SHA256",
    "isDigest": true,
    "clientMetadata": {
      "tool": "custom-pipeline",
      "hostname": "build-server-1"
    }
  }'

<Note> - The `data` field must be base64-encoded and no larger than 128 bytes (the digest of what you want to sign). - Set `isDigest` to `true` if the data is already a hash digest, or `false` if you want the server to hash it. - The `clientMetadata` field is optional and recorded in the signing operation audit log. </Note>

FAQ

<AccordionGroup> <Accordion title="Can I use the same certificate for multiple signers?"> Yes. Multiple signers can reference the same certificate, each with a different signing policy. This is useful if you want different approval workflows for different teams using the same signing key. </Accordion> <Accordion title="What happens if my certificate expires?"> Signing requests will be rejected if the signer's certificate has expired. You should issue a new certificate and update the signer's certificate binding before expiry. </Accordion> <Accordion title="Can machine identities sign without human approval?"> Yes, depending on the signing policy configuration. If the policy allows machine identity bypass, machine identities can sign without human intervention after obtaining a grant. </Accordion> </AccordionGroup>

What's Next?

<CardGroup cols={2}> <Card title="Configure Signing Policies" icon="file-contract" href="/documentation/platform/pki/code-signing/signing-policies"> Add approval workflows before signing operations. </Card> <Card title="PKCS#11 Module" icon="plug" href="/documentation/platform/pki/code-signing/pkcs11-module"> Use standard signing tools with your signer. </Card> </CardGroup>