Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.futurex.com/llms.txt

Use this file to discover all available pages before exploring further.

This walkthrough used numApprovals: 0 and signingFormat: CMS for a clean, self-contained verification. In production, consider the following:
  • Approvals enforce separation of duties. Set numApprovals to 1 or more on the signing policy so that submitting a request and authorizing the signature are distinct actions. Requests then remain in the Pending / Approval state until enough approvers call POST /api/v2/x509/signing-requests/{uuid}/approve; any approver can reject with POST /api/v2/x509/signing-requests/{uuid}/deny, and bulk decisions are available via POST /api/v2/x509/signing-requests/batch-approve-deny.
  • Choose the signing format for your artifact. CMS and Raw produce detached signatures suitable for arbitrary payloads, while Authenticode, JavaJar, Powershell, and Msi produce format-specific embedded or platform-native signatures for Windows executables, Java JARs, PowerShell scripts, and MSI installers respectively. The format is fixed by the signing policy created at deploy time, so deploy one PKI Signing service (or policy) per format you need to support.
  • Match the hash algorithm to the key. Sha2_256 is a sound default for RSA. For larger RSA keys or stricter compliance regimes, Sha2_384 or Sha2_512 are available via the hashAlgorithm field, and rsaPss can be enabled on the signing policy for RSA-PSS padding.