Skip to main content

POST /api/trusted-cas

Add ONE CA certificate to the trusted list.

Adds one CA and verifies by a fresh list read -- never by the call returning, which is the key server echoing what it decoded.

ONE certificate per call, not an array. The key server rejects the WHOLE call when any submitted CA is already trusted, so a vector form would hand you an all-or-nothing refusal you could not attribute to an entry.

A CA that is already trusted is answered 409 ALREADY_TRUSTED and nothing is sent to the key server -- established by reading the list first. That is deliberate: the key server's own duplicate refusal matches no classified pattern and would reach you as a 500, making a harmless repeated request look like a defect in this Gateway.

matchedBy in the response says how the stored row was identified, strongest first: certificate-body compares the DER the key server STORED against the DER you SENT and is independent of what the add resolved; echoed-id uses the id the add echoed; sole-new-entry is the weakest and means only that one row appeared.

WARNING: the running TLS listener does not fully track this list. An ADD takes effect immediately. A REMOVE does not. And RE-ADDING a CA that was removed on the same running process leaves the listener refusing with an unknown-CA alert while this list says the CA is trusted. A key server restart makes all three agree again. So this answer is a statement about the key server's LIST -- which is what a re-read can honestly verify -- and not about what the listener will do until it is restarted.

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​

FieldTypeRequiredDescription
certificatestringyesONE DER X.509 CA certificate, base64. Not an array, not PEM. Required -- an absent value would be answered 200 having stored nothing, because the underlying call guards an empty vector and never reaches the wire.

Example

{
  "certificate": "..."
}

Responses​

200​

The CA is in the trusted list, verified by a fresh read.

FieldTypeRequiredDescription
savedtrue (constant)yes
matchedBystring (certificate-body, echoed-id, sole-new-entry)yes
wasAlreadyPresentbooleanno
listCountBeforeintegeryes
listCountAfterintegeryes
appearedCountintegerno
trustedCACertificateyesA certificate object as the key server holds or parses it.
echoedCountintegernoWhat the add itself resolved. Reported as information, NOT as evidence.
detailstringno

Certificate

FieldTypeRequiredDescription
certificateIdstring or nullnoCanonical base64 of an 8-byte id. This is the spelling the trust routes take. It is NOT the lower-case hex a thick client renders for the same field; the two do not interoperate byte-for-byte.
classNamestring or nullno
subjectstring or nullnoThe FULL stored DN, slash-prefixed and slash-separated, e.g. /CN=teFileX509/O=ERUCES.
issuerstring or nullno
publicKeyTypestring or nullno
serialNumberstring or nullnobase64
certHashstring or nullnobase64
effectiveDatestring or nullno
expirationDatestring or nullno
statusinteger or nullnoThe certificate-object status WORD, not an ok/error flag. See statusLabel.
statusLabelstring or nullnoOne of: CA, Regular, Saved request, Saved PKCS#7.
certificatestring or nullnoThe DER body, base64. Present only when includeBodies was true.
requeststring or nullnoThe stored CSR, base64. Present only when includeBodies was true.

Example

{
  "saved": true,
  "matchedBy": "certificate-body",
  "wasAlreadyPresent": true,
  "listCountBefore": 0,
  "listCountAfter": 0,
  "appearedCount": 0,
  "trustedCA": {
    "certificateId": "...",
    "className": "...",
    "subject": "...",
    "issuer": "...",
    "publicKeyType": "...",
    "serialNumber": "...",
    "certHash": "...",
    "effectiveDate": "...",
    "expirationDate": "...",
    "status": 0,
    "statusLabel": "...",
    "certificate": "...",
    "request": "..."
  },
  "echoedCount": 0,
  "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​

ALREADY_TRUSTED -- that CA is already in the list. Established by READING the list; nothing was sent to the key server.

NOT_SAVED -- the add resolved and a fresh list read does not contain the certificate you sent. This is a 409, not a 500: nothing errored. Compare listCountBefore and listCountAfter.

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.

StatusMeaning
400The 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.
401No 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.
403Authenticated, 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.
409ALREADY_TRUSTED -- that CA is already in the list. Established by READING the list; nothing was sent to the key server. NOT_SAVED -- the add resolved and a fresh list read does not contain the certificate you sent. This is a 409, not a 500: nothing errored. Compare listCountBefore and listCountAfter.
500A 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.
503A 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.