Trusted CAs and the certificate ignore list¶
Open Trusted & Ignored CAs to manage two independent lists:
| List | Effect |
|---|---|
| Trusted CAs | Register an internal/private root or intermediate CA certificate so chain validation and the chain view treat it as a trust anchor for one organization or for every organization in the tenant. |
| Ignore list | Exclude a CA certificate from expiry alerts and acknowledgement queues for one organization or for the whole tenant. It never changes trust. |
A CA may appear on either list, both, or neither. Adding or removing an ignore entry does not edit a trusted CA registration, and registering a CA as trusted does not silence its expiry alerts.
Platform defaults and the Common CA Database¶
The platform's default trust is the Common CA Database (CCADB), the public catalogue of root and intermediate CA certificates and their status in the Apple, Chrome, Microsoft and Mozilla root programs. CertIntel synchronizes it daily, and the platform administrator reviews records whose root-store statuses disagree. The Common CA Database section of the page lets every tenant browse the catalogue: search by name, owner, CCADB ID or SHA-256 and filter by decision (Trusted, Not trusted, Awaiting platform review, Review ignored, All current). Only the platform administrator can change a decision, queue a sync, or download the source JSON.
Two things follow from CCADB membership:
- Every record whose effective decision is Trusted is a platform-default trust anchor for each tenant that inherits platform defaults.
- Every current record, whatever its decision, is excluded from expiry alerts. Public CAs therefore never need an ignore entry, and there is no platform-wide ignore list.
Under Platform defaults, a tenant administrator can tick Trust the platform defaults (on by default) so those roots count as trust anchors for every organization in the tenant and appear as Platform default rows in the trusted CA table, where they are read-only. If there is a public CA the tenant must not trust, untick it: the platform defaults disappear from the tenant's policy, and the tenant registers the public roots it does want under Trust a new CA certificate, like any other CA. Public CA expiry stays excluded from alerts either way. The CCADB table is still shown while inheritance is off, for reference.
Platform administrators can additionally register a CA platform-wide for a public root that CCADB does not list; Platform Certificates in the platform console sorts observed CAs by how many tenants present them and marks the ones CCADB already covers.
Scopes¶
Both forms offer the same Scope choices, depending on your role:
| Scope choice | Who can use it | What it means |
|---|---|---|
| One organization | Organization or tenant administrators | Applies to that child organization only. When you have an organization selected in the top bar, the form pre-selects it. |
| This tenant (all organizations) | Tenant administrators | A trust anchor (or ignore entry) for every organization in the tenant - use it for a company-wide root CA that should be registered once. Trust never crosses a tenant boundary. |
| Platform default (inheriting tenants) | Platform administrators only, trust form only | An extra platform-wide trust anchor, applied to every tenant that has not turned off platform inheritance. |
Older rows
Before the ignore list became a separate table, tenant-wide rows created through the trust form were ignore-only. Those legacy rows were moved to the ignore list automatically and never became trust anchors. A trusted CA row that shows alerts also ignored has both effects (a private CA's own trust anchor, or a row created before the lists were split); removing it removes both. The platform-wide ignore list and the platform trust anchors seeded from the server's operating-system CA bundle were removed in October 2026 - CCADB replaces both.
Trusting a CA¶
Under Trust a new CA certificate, paste the root or intermediate into Certificate (PEM) (a bare base64 DER body is also accepted), optionally give it a Label, choose the scope and click Trust this CA. There is no file upload. Click a trusted CA row to open its detail drawer, which shows the subject, issuer, SHA-256 fingerprint and its CCADB root-store status per browser program. Only a certificate with the CA basic constraint is accepted; a site certificate is rejected with This certificate isn't a CA certificate (no CA basic constraint) - only a root or intermediate issuing certificate can be trusted here.
The trust decision validates the observed leaf and intermediates against the organization's effective CA certificates. It checks signatures, certificate validity, CA constraints/path length, and server-authentication usage. Merely appending a trusted CA to an unrelated or invalid chain does not make it trusted. Fingerprint annotations and public CA catalog metadata remain useful for chain display but are not, by themselves, a cryptographic trust result. Revocation (CRL/OCSP) is not checked.
Hostname matching is a separate result, so a valid chain may still be served by the wrong host. Registering a CA here does not install it into an Agent machine's or application's operating-system trust store.
Ignoring a CA¶
Ignoring a CA also tells Agents not to report that CA certificate as inventory of its own (for example from a Windows store scan). It does not remove it from the chains Agents submit for the certificates it issued: agents 1.3.71 and later always send the observed chain, so certification paths through an ignored public root still display and validate normally.
Only CA certificates can be ignored. A specific site's own certificate changes on every renewal, so the ignore list refuses it with Only CA certificates (roots/intermediates) belong on the ignore list - a specific site's own certificate changes on every renewal. Acknowledge that certificate instead of ignoring it. Use Acknowledge on the certificate itself for that case (see Certificates).
Add an ignore entry from:
- Trusted & Ignored CAs → Add certificate to the ignore list (paste the CA certificate, choose the scope, click Add to ignore list);
- a certificate's detail dialog, where each CA member of the chain offers Ignore this CA for this organization or for this tenant (as your role allows), followed by Ignore.
Tenant administrators manage tenant-wide entries; organization administrators manage entries for their own child organization. Trying to use a scope you are not allowed to use shows Only a tenant administrator can change the tenant ignore list. or Your role in that organization cannot manage the ignore list.
Remove takes a certificate off the list; it will start appearing in alerts again unless another policy (another scope, or the public CA catalog) also ignores it.
Removing a trusted CA or an ignore-list entry you cannot see - another
tenant's, or one in an organization you cannot reach - answers Not found.
(404), exactly like an id that does not exist; only an entry you can see but
may not remove answers 403.
An ignored CA's certificates show policy ignored in the inventory. The Agent periodically receives the effective ignore policy for its reporting organization and may skip uploading a matching certificate; for an internal endpoint configured in the dashboard, that produces a neutral Skipped by certificate policy check after the TLS handshake identifies the certificate.