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 guide documents a code-signing workflow that is driven entirely through the CryptoHub REST API, with no CI tooling, no PKCS #11 client, and no web UI. Every step is a curl call against the CryptoHub v2 API, from authentication through to retrieving and verifying a detached CMS signature. The walkthrough was verified end-to-end against a live CryptoHub 7.3 instance. The flow has seven stages:
  1. Authenticate (dual login) and obtain a bearer token.
  2. Mint a self-signed signing CA with POST /api/v2/x509/generate.
  3. Deploy a PKI Signing service with an embedded signing certificate.
  4. Read back the signing policy the deployer auto-created.
  5. Submit a signing request with a base64 payload.
  6. Retrieve the resulting signature.
  7. Verify the signature with OpenSSL.
Throughout this guide, the CryptoHub host is referenced as https://localhost:8443. Replace it with your own host. All certificate-profile, key-type, service, and policy UUIDs are environment-specific: the values shown are examples and will differ on yours. Always list them dynamically rather than copying UUIDs verbatim.

​
Code signing formats

CryptoHub’s PKI Signing service can emit signatures in several formats. The signingFormat field on a signing policy accepts the following enum values:
signingFormatDescription
RawRaw signature over the input bytes.
CMSCMS / PKCS #7 detached signature (used in this guide).
AuthenticodeMicrosoft Authenticode for Windows executables and DLLs.
JavaJarEmbedded signature for Java JAR files.
PowershellPowerShell script signature.
MsiWindows Installer (MSI) signature.
This guide uses CMS because it produces a standalone, detached PKCS #7 structure that is trivial to verify with OpenSSL on any platform.

​
Prerequisites

Before you begin, make sure you have the following:
  • CryptoHub 7.3 reachable over HTTPS. This guide uses https://localhost:8443.
  • Two administrator identities (referred to as Admin1 and Admin2) whose combined permissions satisfy CryptoHub’s dual login requirement.
  • curl with -k available (the verification instance uses a self-signed TLS certificate).
  • openssl and base64 on the client for payload encoding and signature verification.
  • Permissions to generate certificates, deploy services, and submit signing requests.
The CryptoHub v2 API returns a consistent envelope on every endpoint:
{
  "success": true,
  "errorCode": "Success",
  "errorField": "",
  "errorString": "",
  "response": { /* endpoint-specific payload */ }
}
On failure, success is false and errorCode carries a specific value such as NotAuthorized, NotFound, ArgumentMissing, or AuthFailure. Check success/errorCode on every call.