POST /api/certificates/enroll

Enrol leaf certificates, creating transport principals.

Enrols the submitted DER certificates, which creates a transport principal per new identity. Verified by DIFFING the transport-principal list before and after -- a DIFFERENT operation on a different module, because the enrolment call resolves a receipt that is not evidence.

WARNING: the match is a SET DIFFERENCE ON IDS, not on a subject string. The name on the returned principal is the KEY SERVER'S OWN rendering of the certificate DN and need not equal the subject you generated the certificate with. Comparing them is how a correct enrolment gets reported as a defect.

WARNING: the new principal holds NO roles and therefore NO operations -- it can authenticate and do nothing. Roles are a second call: PUT /api/principals/{id}/roles. Enrolment also does not set the DELEGATION flag, so an identity intended to impersonate others needs PUT /api/principals/{id}/flags with {"delegation": true}. Without it a delegated login fails with a refusal that names neither the flag nor the fix.

Which id to use next: id (16 hex digits) is what the principal routes take; principalId (decimal) plus systemId are what the ACL and export routes take.

This route is in the trust family rather than the certificate-lookup family despite its /api/certificates/ path, because enrolment is what makes a trusted CA usable.

Authentication

Send the session id as Authorization: Bearer <session id>, and an RFC 9449 DPoP proof in the DPoP header if your session is bound to a key. The two are required together, not as alternatives — see Authenticating and Proving you hold your key.

This surface sets no cookie

There is no session cookie on any response and none is read on any request. Do not set credentials: "include" on a browser fetch.

Request

Field	Type	Required	Description
certificates	array of string	yes	base64 of one raw DER X.509 certificate. Not PEM.

Example

{
  "certificates": [
    "..."
  ]
}

Responses

200

At least one new transport principal appeared.

Field	Type	Required	Description
submitted	integer	no
accepted	boolean	no	That the enrolment call resolved. NOT evidence that anything was enrolled -- enrolled is, and it comes from a different operation.
echoedObjects	integer or null	no
principalCountBefore	integer	no
principalCountAfter	integer	no
enrolled	array of Principal	no	The transport principals that APPEARED, by set difference on ids. Empty is the 409 case, not a success.
detail	string	no

Example

{
  "submitted": 0,
  "accepted": true,
  "echoedObjects": 0,
  "principalCountBefore": 0,
  "principalCountAfter": 0,
  "enrolled": [
    {
      "id": "...",
      "principalId": "...",
      "systemId": 0,
      "className": "...",
      "name": "...",
      "disabled": true,
      "roleIds": [
        "..."
      ],
      "groupIds": [
        "..."
      ]
    }
  ],
  "detail": "..."
}

400

The request was refused before anything was sent to the key server.

Most 400s on this surface carry code: BAD_REQUEST and a detail naming the field and saying what the key server would otherwise have done with it. A large share of them exist because the value would have been ACCEPTED downstream and quietly meant something else -- an empty string that reaches the wire as "mint a new key", a zero-length identifier that names no object, a numeric flag word that clears bits the caller did not name.

401

No live session, or a DPoP proof that did not verify.

SESSION_NOT_FOUND -- the credential names no session this Gateway holds. SESSION_EXPIRED -- it aged out. Both carry reauth: true; obtain a new credential rather than retrying.

PROOF_* -- the sender constraint refused. See the DPoP section of this document for the full table; PROOF_MALFORMED is a 400 and PROOF_REPLAY_CACHE_FULL a 503, and the rest are here.

SCOPED_CREDENTIAL_EXPIRED -- a scoped browser credential passed its fixed lifetime. Use does not extend it: an idle timeout would be refreshed by exactly the traffic a stolen handle produces.

403

Authenticated, and refused. The codes differ in what they say about where the refusal came from: ACCESS_DENIED and PRINCIPAL_DISABLED are the key server's, while NOT_WRITABLE, BUILT_IN_PRINCIPAL, OWN_ACCOUNT and OBJECT_NOT_IN_CREDENTIAL_SCOPE are decided by the Gateway before anything is sent.

409

NO_PRINCIPAL_APPEARED -- the call resolved and a fresh transport-principal list shows NO new principal. This is a 409, not a 500: nothing errored. Two ordinary causes: the certificate was ALREADY enrolled (the identity exists; find it with GET /api/principals?type=certificate), or its issuing CA is not trusted (add it with POST /api/trusted-cas first).

500

A fault rather than a refusal.

OP_FAILED is the catch-all: the key server refused in words that match no classified pattern, so the Gateway cannot say more than that the operation did not happen. Some key server refusals that are conceptually a caller error arrive here rather than as a 4xx, because the wire carries no distinguishing code -- where a route can recognise one from its message it maps it, and each such mapping is documented on the operation.

503

A capacity ceiling or a missing deployment prerequisite. retryable says which.

A scope of session or process names the ceiling that was hit, and the response carries Retry-After.

Error handling

Every failure answers JSON carrying at least code and detail. Match on code — detail is written for a human debugging the call and its wording is not part of the contract. See the error model.

Status	Meaning
400	The request was refused before anything was sent to the key server. Most 400s on this surface carry code: BAD_REQUEST and a detail naming the field and saying what the key server would otherwise have done with it. A large share of them exist because the value would have been ACCEPTED downstream and quietly meant something else -- an empty string that reaches the wire as "mint a new key", a zero-length identifier that names no object, a numeric flag word that clears bits the caller did not name.
401	No live session, or a DPoP proof that did not verify. SESSION_NOT_FOUND -- the credential names no session this Gateway holds. SESSION_EXPIRED -- it aged out. Both carry reauth: true; obtain a new credential rather than retrying. PROOF_* -- the sender constraint refused. See the DPoP section of this document for the full table; PROOF_MALFORMED is a 400 and PROOF_REPLAY_CACHE_FULL a 503, and the rest are here. SCOPED_CREDENTIAL_EXPIRED -- a scoped browser credential passed its fixed lifetime. Use does not extend it: an idle timeout would be refreshed by exactly the traffic a stolen handle produces.
403	Authenticated, and refused. The codes differ in what they say about where the refusal came from: ACCESS_DENIED and PRINCIPAL_DISABLED are the key server's, while NOT_WRITABLE, BUILT_IN_PRINCIPAL, OWN_ACCOUNT and OBJECT_NOT_IN_CREDENTIAL_SCOPE are decided by the Gateway before anything is sent.
409	NO_PRINCIPAL_APPEARED -- the call resolved and a fresh transport-principal list shows NO new principal. This is a 409, not a 500: nothing errored. Two ordinary causes: the certificate was ALREADY enrolled (the identity exists; find it with GET /api/principals?type=certificate), or its issuing CA is not trusted (add it with POST /api/trusted-cas first).
500	A fault rather than a refusal. OP_FAILED is the catch-all: the key server refused in words that match no classified pattern, so the Gateway cannot say more than that the operation did not happen. Some key server refusals that are conceptually a caller error arrive here rather than as a 4xx, because the wire carries no distinguishing code -- where a route can recognise one from its message it maps it, and each such mapping is documented on the operation.
503	A capacity ceiling or a missing deployment prerequisite. retryable says which. A scope of session or process names the ceiling that was hit, and the response carries Retry-After.