Skip to content

Trust Anchor Rejected

URI: https://docs.ankatech.co/errors/trust-anchor-rejected
HTTP Status: 400 Bad Request

When you see this

The LDAPS trust-anchor material you submitted with an identity-provider configuration was refused — either by the pre-decode bounds and private-key discrimination that run before any parsing, or by the per-element CA and validity rules that run after. Every refusal is total: nothing is accepted and nothing is persisted, not even the elements of a bundle that individually passed. The detail is server-authored and prefixed with the wire field name trustAnchors:; it carries bounds, positions, counts and — for an expired element — the expiry date, but never a fragment of the submitted material.

Common Causes

  • No PEM certificate material was supplied where trust anchors were expected.
  • The aggregate submission exceeds 65536 bytes, or a single PEM block exceeds 16384 bytes; both are refused before any decode is attempted.
  • The material contains a PEM private-key block. Trust anchors are public CA certificates only, and the submission is refused before parsing so private-key bytes never reach the parser.
  • No PEM CERTIFICATE block was found, or the material is not a parseable X.509 sequence.
  • The submission carries more than 5 certificates, or the resulting anchor set would exceed 5 — the bound is enforced on the resulting set, so growth across two writes fails exactly as the same total pasted at once would.
  • An element is not a CA: BasicConstraints says CA=false and KeyUsage does not assert keyCertSign.
  • An element's validity window has already ended.
  • Trust anchors were supplied on a provider kind that does not consume them; they are configurable on LDAP identity providers only.

Response Example

{
  "type": "https://docs.ankatech.co/errors/trust-anchor-rejected",
  "title": "Trust Anchor Rejected",
  "status": 400,
  "detail": "trustAnchors: element 2 of 3 is not a CA (BasicConstraints CA=false and KeyUsage does not assert keyCertSign). The whole submission was rejected; no anchor was accepted.",
  "instance": "/api/v3/admin/platform/idp",
  "timestamp": 1730000000,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

How to Resolve

  1. Read the detail: it names the position of the offending element and the rule it broke, which is enough to find it without the server echoing any certificate content.
  2. Submit only CA certificates. Export the directory server's issuing CA and root, not the server's own end-entity certificate.
  3. Strip any PRIVATE KEY block from the pasted PEM before submitting.
  4. Replace an expired element with a current CA certificate; the detail gives the expiry date of the element that failed.
  5. Keep the resulting set within 5 certificates, and remember the bound applies to the set that would result, not to the number you are adding.
  6. Configure trust anchors only on an LDAP identity provider; other provider kinds do not consume them, so supplying them there is inert configuration and is refused.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.