Seal under your own name (BYOC)

The platform certificate gets you sealing in minutes, with Sigill's identity on the seal. But when the seal is the statement — contracts, certificates, official documents — recipients should see your organisation's name in the signature panel, backed by a certificate authority your industry recognises. That's bring-your-own-certificate: your identity, your CA, our key custody.

How the trust is split

The design keeps each party doing what it's best at:

• Your CA vouches for your identity — you choose the authority and the certificate profile your use case demands.
• AWS KMS guards the private key — generated inside a hardware-backed key store, signs inside it, and is not exportable. Nobody — not your staff, not ours — can walk away with it.
• Sigill does the ceremony — CSR generation, chain resolution, revocation capture, timestamp embedding — so a seal under your name is still one API call.

The flow

Everything below is available in Settings → Certificates in the app; the API equivalents are shown for automation (reference).

1. Provision. Sigill generates an RSA-4096 key pair in KMS and returns a PKCS#10 CSR carrying your subject details:

curl -s -X POST https://api.sigill.ai/seal/certificates \
  -H "Authorization: Bearer $SIGILL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"commonName":"Acme Corp Seal 2026","organization":"Acme Corp AS","countryCode":"NO"}'
# → { "id": "…", "csrPem": "-----BEGIN CERTIFICATE REQUEST-----…" }

2. Take the CSR to your CA. Any CA, any profile — organisation validation, eIDAS advanced-seal certificates, an industry-specific authority. The private key never travels with it; a CSR contains only the public half and your subject.

3. Activate with the issued certificate chain:

curl -s -X POST https://api.sigill.ai/seal/certificates/$CERT_ID/activate \
  -H "Authorization: Bearer $SIGILL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"certificatePem":"-----BEGIN CERTIFICATE-----…"}'

Activation is checked, not trusted: the certificate's public key must match the KMS key it was provisioned for (a mismatched or expired certificate is rejected), and the chain is pre-resolved so your first seal doesn't pay the lookup cost.

4. Seal. Pass the certificate's id anywhere a certificateId goes — PDF, CAdES, JAdES, SDKs, MCP. Verification reports now show your subject:

"certificate": { "subject": "CN=Acme Corp Seal 2026, O=Acme Corp AS, C=NO", "trust": "trusted_chain" }

Lifecycle

• Rotation: provision the successor certificate ahead of expiry and switch the certificateId your integrations use; already-issued seals remain valid — they embed the chain and revocation evidence from their sealing time (why that works).
• Revocation: revoking a certificate entry schedules the KMS key for deletion with a grace period. Existing seals stay verifiable; new seals with that identity stop.
• Roles and plans: certificate management requires the owner role; BYOC is available on Business and Scale plans.