Issuance backends

Backends and scopes

A signing backend decides who holds the key that signs, or which external private CA issues, for the deployment (the platform default) and optionally for one trust space (an override). Sectigo staff configure backends in the staff console; the customer portal shows each space's backend and pinned CA chain fingerprints read-only.

Only non-secret configuration is stored in the database. The EAB HMAC key, the ACME account key and the signer's evidence key live in the signer's own secret store (a KV namespace bound only to the signer, sealed with AES-GCM under a signer KEK); the database holds a reference and a fingerprint.

Testing and activation

• Test connection runs inside the signer and is stored as evidence: an mt.signing-backend-evidence.v1 statement signed (ES256) by the signer evidence key, append-only. For Cloud HSM each key version signs a fresh challenge digest that is verified locally.
• Activation needs a passing test of the current configuration from the last 24 hours, which the signer re-verifies, and a second, independent staff member. Any configuration change invalidates earlier evidence.
• Deactivation and key-version disabling are audited. There is never a software fallback and never a fallback to another CA.

Sectigo Private CA through ACME

Mutual Trust still decides policy: which grant and workload may receive a certificate, the canonical URI SAN, the environment and the validity bound. The signer submits the workload's own CSR on an ACME order of the space's account; the workload key never leaves the workload.

The workload identity is a URI SAN

RFC 8555 identifiers are dns and ip; there is no URI identifier, and an order needs at least one. Each order therefore carries a single placeholder dns identifier that names the issuance intent under a configurable domain (default acme.invalid, which can never resolve), and the CA's certificate profile takes the URI SAN from the CSR. The SCM private CA profile must:

• take the subject alternative name from the CSR (one URI SAN) and keep the placeholder out of the certificate;
• issue clientAuth as the only extended key usage, digitalSignature as the only key usage and CA:false;
• use a term no longer than the configured leaf lifetime (default 24 hours) and honor the order's validity window;
• pre-authorize the EAB account for the placeholder domain (Mutual Trust never answers challenges).

Confirm these settings with Sectigo PKI Operations before activation. Workloads put the URI SAN into their CSR: the enrollment challenge returns it as csr_uri_san, and the mt CLI does this automatically, also on renewal.

Every certificate is checked before it is stored

The signer and then the API independently check the returned certificate against mt.workload.clientauth.v1: exactly the canonical URI SAN, clientAuth only, CA:false, digitalSignature only, only allowed extensions, the CSR's public key, validity inside the policy bounds and the issuing CA, a serial unique per issuer, and a signature by the pinned issuing CA under the pinned root. A certificate that fails is never delivered: the intent fails, the signer alerts (external_ca_certificate_rejections) and revokes it at the CA.

Revocation and trust bundles

Revoking a certificate writes the Mutual Trust deny set first, which gateways enforce whatever the CA reports, and then calls ACME revokeCert at the CA (retried with backoff). The space's trust anchors in the signed manifest are the pinned external chain. Activation and later CA changes use the staged rollover: the chain enters the bundle, every gateway acknowledges it, issuance switches, and the previous chain drains. A successor chain is registered on the active backend before its rollover.

SCM REST API

ACME is the supported integration. A direct SCM REST enrollment adapter is not offered for activation until its endpoints and URI SAN handling are verified with Sectigo.