How It Works
- A Signer is created and bound to a certificate with the
codeSigningextended key usage. - Optionally, a Signing Policy is attached to govern who can use the signer and under what conditions. Without a policy, authorized users and identities can sign immediately.
- When a policy is configured, users or machine identities request signing access through the signing workflow. Once approved, the caller receives a grant that authorizes signing operations.
- The signing tool (e.g., jarsigner) calls the Infisical API, either directly or through the PKCS#11 module, and the signature is computed server-side.
- Every signing operation is recorded as an immutable audit entry on the signer.
Core Concepts
Signers
A signer is a named code-signer bound to a certificate. It represents a signing capability within a project. Private keys are stored securely on the Infisical server and never leave it. All cryptographic operations are performed server-side.Signing Policies
Signing policies optionally define the rules that must be satisfied before signing can occur. Policies support constraints that can be combined:- Max Window Duration: Limits how long a signing grant remains valid.
- Max Signings: Limits the total number of signing operations a grant allows.
Signing Operations
Every call to sign data, whether it succeeds, fails, or is denied, is recorded as a signing operation. This provides a complete audit trail of who signed what, when, and using which grant.PKCS#11 Module
The Infisical PKCS#11 module implements the PKCS#11 v2.40 standard, allowing standard signing tools to use Infisical signers without code changes. The module supports RSA (PKCS#1 v1.5 and PSS) and ECDSA signing mechanisms.Getting Started
Create a Signer
Set up a code-signer and bind it to a certificate.
Configure Signing Policies
Define signing policies to control who can sign and when.