Skip to content

Certificates and Signing API

Kunal Priyadarshi edited this page Oct 3, 2026 · 1 revision

Certificates and signing API

These APIs require user authentication and the relevant certificate or signature permissions. Cryptographic signing additionally needs configured signing services and keys. Never include real key material in a public example or support report.

Certificate routes

Prefix paths with /api/v1/certificates.

Method Suffix Permission / purpose
GET /, /{id}, /default certificates:read; list, detail, or default
POST /generate certificates:manage; generate an offered self-signed certificate
POST /upload certificates:manage; register supported certificate material
PUT /{id}/default certificates:manage; choose default
DELETE /{id} certificates:manage; remove under service rules

Generation requires name (1–255 characters). Optional input includes commonName, organization, organizationUnit, algorithm (RSA_2048, RSA_4096, ECDSA_P256, ECDSA_P384), validity days (30–3,650, default 730), country, state, locality, and email. Defaults and selectable values do not guarantee a deployed signer supports every algorithm.

Upload requires name and certificatePem. The schema also supports chain, algorithm, and timestamp-service URL. Private-key provisioning, where required, must follow the deployment operator's approved secure process; it is intentionally not illustrated with key material here. Registering a public certificate alone does not guarantee the signing service possesses its usable private key.

Seal or verify

Prefix paths with /api/v1/signing.

Method Suffix Input
POST /seal/{agreementId} Optional certificateId, pdfData; requires signatures:sign and eligible state
POST /batch Required agreementIds UUID array, 1–100; optional certificateId; requires signatures:sign
POST /verify token, hash, or fileData; authenticated verification

Sealing creates evidence on a real document. Do it only through an approved workflow and check the actual result. A completed agreement state, a stored certificate, or a successful HTTP request does not independently prove a particular PAdES level or trusted timestamp.

Public verification and report download routes are in REST API Reference. Read Cryptographic Signing and Verification before interpreting results.

CSC-style protocol routes

The /csc/v2 family exposes POST routes /info, /credentials/list, /credentials/info, /credentials/authorize, /signatures/signHash, and /signatures/timestamp. Credential operations and signature hash operations have relevant authorization requirements. The protocol label alone does not certify CSC conformance; validate interoperability with the operator before adopting this interface.

Clone this wiki locally