Certificates¶

To issue and install certificates with the Agent, see certificate workflows and Agent workflow usage.

The Certificates page unifies public endpoint probes, internal scanners, and ACME renewals, deduplicated by fingerprint within each organization. A certificate seen by more than one source shows every sighting on its detail view. Certificate Transparency discoveries remain on the separate Certificate Transparency page (CT Log Watch) until another source observes that certificate; that page marks each entry CertIntel issued or that this inventory already holds.

Search¶

• The default Search in setting is All fields (issuer, serial, SHA-256, DN): the term matches the subject common name, SANs, issuer, serial number, SHA-256 fingerprint and the subject/issuer distinguished names.
• Switch Search in to CN / SAN to match only the subject common name and SANs - the common case of "find the cert for this hostname" without hits on issuer or distinguished-name text.

Filtering¶

Filter by Source (Public endpoint, Internal scan, ACME renewal, CT log, Imported, Private CA - certificates issued by a CertIntel Private CA), Expiry (Needs attention, Expired, Expiring soon, Critical or Warning under the organization's policy, Outside warning window, or the fixed 30-day views) and Acknowledged (No, Yes or All). Certificates you've acknowledged are hidden by default until you explicitly ask to see them. Agent-managed renewals carry a Managed badge. When a newer certificate replaces an older one and no current source still points to the old certificate, the old row is marked superseded and leaves current-certificate views; its history remains available. A monitored target that has been deleted no longer keeps its old certificate current.

Certificate detail and CA policy¶

Open a certificate to see its observed sources, public leaf and chain, and X.509 details such as key usage, extended key usage, policies, authority identifiers, AIA/OCSP and CRL locations when present. The detail drawer opens on an at-a-glance verdict and is organised in tabs: Overview, Certificate (X.509 details), Trust (path validation and policy), Chain, Sightings (every source that reported it, with Pause this host on each internal-scanner row) and Actions (acknowledge or resume alerting, and delete; the tab only appears for roles that can acknowledge or delete). Trust this CA and Ignore this CA sit on each CA member in the Chain tab. A chain member that is a trust anchor for this organization is labelled Trusted CA in the chain view; a member on the ignore list or in the public CCADB catalogue is labelled Alerts ignored. The Trust tab also summarises the issuing CA's CCADB root-store status (for example Unanimous inclusion or No CCADB record). CertIntel's organization trust decision validates the observed X.509 chain against the organization's effective CA certificates, including signatures, validity, CA constraints, and server-authentication usage. A recognized CA fingerprint in the chain display alone is not proof of a valid path, and revocation (CRL/OCSP) is not checked: a revoked but otherwise valid chain still shows as trusted.

Hostname coverage is checked separately from chain trust. When DNS SANs are present, they determine hostname coverage; a matching subject CN does not override nonmatching SANs. A successfully collected certificate can therefore still be expired, untrusted, or for the wrong host. Inspect these validation results as well as collection status.

Each CA member of the chain offers Ignore this CA (for this organization, for this tenant, or platform-wide, as your role allows). Ignoring affects expiry alerts and acknowledgement queues; it does not assert trust. Each CA member that is not yet trusted also offers Trust this CA with the same scope choices, followed by Trust. The leaf certificate itself cannot be ignored - acknowledge it instead. See Trusted CAs and the ignore list.

Renewal schedule¶

For an Agent-managed certificate the Overview tab has a Renewal schedule block, taken from what the managing Agent last reported (Agent 1.4.0 and later):

An older Agent shows Not reported by this agent. The Agent re-sends the schedule with its heartbeat when it changes and at least once a day, so the block can lag a change on the device by up to an hour. Certificates waiting for a deployment window are also listed under Deferred deployments on the Agent's host detail.

Served versus issued¶

CertIntel can check that a public endpoint actually serves the certificate a renewal produced. A monitored endpoint is linked to a managed certificate - the renewals one Agent or ACME client integration reports for one certificate ID - rather than to one fingerprint, so the link carries over from renewal to renewal:

• Automatically, when a successful renewal's subject or SANs cover the endpoint's hostname in the same organization.
• By hand, from the Expected certificate section of the endpoint's detail on Public Endpoints: choose the certificate under Link a managed certificate. Linking and unlinking need targets.update.
• Unlink removes a link made by hand. Unlinking an automatic match keeps a record of the decision, so later renewals do not link it again.

After every probe of the endpoint, and hourly, CertIntel compares what the endpoint served with the latest successful renewal:

The Public Endpoints list shows the status as a pill and filters on it with Expected certificate. On a certificate's Sightings tab, Served by N linked endpoint(s), M stale counts the linked endpoints and those still renewed-not-served or serving an old certificate. An endpoint serving an old certificate raises the monitor.served_mismatch digest alert (Endpoint still serving an old certificate, see Alerts); it drops out of the next digest once the endpoint serves the renewed certificate.

The check covers endpoints monitored by the platform. Internal endpoints that an Agent probes are not linked yet; the Agent's own post-install re-check still reports what they serve.

TLS grade¶

On a platform build that offers it, CertIntel grades the TLS configuration of every endpoint it monitors on Public Endpoints, from A to F.

How it is measured. Every regular probe records the negotiated protocol, cipher suite and key-exchange group of its handshake, without an extra connection. A separate, slower assessment then tests TLS 1.3 and TLS 1.2 with one handshake each: within an hour of an endpoint's first successful check, then about once a day (an hourly sweep assesses at most 500 endpoints, each at most once every 24 hours, and follows the same pause, suspension and plan limits as the regular probes). Until then the endpoint reads Not assessed yet. The protocol versions are tested within an hour of a successful check, then once a day.

The grade. The first matching cap wins, and every reason that applies is listed as : :

An endpoint is not graded when no certificate has been captured yet (No certificate has been captured yet.) or no protocol version could be negotiated (No protocol version could be negotiated.). A network error during the TLS 1.3 test is not counted as "TLS 1.3 not offered". Revocation does not affect the grade, and a grade change raises no alert.

Post-quantum badge. Separately from the grade, the key exchange is shown as Post-quantum key exchange (an ML-KEM hybrid group such as X25519MLKEM768), Classical key exchange or Key exchange group unknown; the list shows a PQ badge next to the grade for the first. It shows only the group CertIntel's own TLS client negotiated: other clients may get a different group, the groups a server supports cannot be listed, and members behind a load balancer may answer differently.

TLS 1.0 and 1.1. These are not tested by default and show as not tested, which does not affect the grade. With targets.update, Test TLS 1.0/1.1 too on the endpoint's detail turns legacy probing on for that endpoint (Stop testing TLS 1.0/1.1 turns it off) after the warning Testing TLS 1.0 and 1.1 makes extra handshakes with deliberately weak settings; it may trigger IDS or Windows SChannel events on the target. The change is in the activity log.

Where it shows.

• Public Endpoints list: a sortable TLS grade column (A to F, not graded last) and a TLS grade filter (any, A, B, C, F, not graded).
• The endpoint's detail: the section TLS configuration - grade with Grade, TLS 1.3, TLS 1.2, TLS 1.1 and TLS 1.0 (offered, not offered or not tested), Negotiated, Cipher, Key exchange with the post-quantum label, Chain (complete, incomplete, out of order or extra certificates), Key, Assessed, the reasons and the legacy probing switch. The Recent checks table gains a Protocol column.
• The API: monitored targets carry a tls block (grade, grade_reasons with cap, code and text, supported_versions, legacy_tested, negotiated_protocol, cipher_suite, key_exchange_group, post_quantum (yes, no, unknown), chain_complete, chain_ordered, assessed_at); grade is "" when not graded. probe_legacy_tls can be set when creating or updating a target.

Grading covers platform-monitored endpoints only; internal endpoints an Agent probes are not graded.

Certificate paths¶

Certificate Path shows a preferred route from the leaf certificate to a trust anchor. When alternatives are found, expand them to see the other routes and their validation results. Multiple valid paths are normal and do not themselves cause a warning.

Server Presented shows the certificates the endpoint actually transmitted, in order. This may differ from the built path: CertIntel can find an issuer in its repository or trust dataset. A file or local-store bundle is labeled Supplied certificates instead. Incomplete captures and older unknown evidence are identified.

When an Agent reported the certificate, the chain section also shows the agent's chain evidence: how many chain members it captured, how many it submitted, and the reason if it withheld the chain (for example a malformed member or a size limit). Agents 1.3.71 and later submit every well-formed chain; earlier agents also withheld chains containing an ignored CA, so a Server presented list that is shorter than expected usually means an older agent rather than a misbehaving endpoint.

A trust anchor is a certificate explicitly trusted in the named dataset. Self-signing alone does not establish trust. Cross-signing lets the same CA key appear in different certificates: a new root might be self-signed in one certificate and signed by an older CA in another. Each is a distinct certificate, and each may lead to a different path. Different clients can build different paths because their trusted anchors and available intermediates differ.

Trust labels describe the datasets CertIntel actually evaluated; they do not promise compatibility with every browser or device. Leaf expiration remains separately monitored. An expiring intermediate on an optional path does not mean the leaf expires then. Check the observation timestamp and path diagnostics when troubleshooting.

Expiry severity¶

Certificate severity uses the owning organization's effective expiry thresholds. The defaults are 21 days for warning, 7 days for critical, and a 20% lifetime factor. Administrators can override them from Organizations → Edit; see expiry severity settings.

When both validity dates are known, short-lived certificates have smaller thresholds: critical is the smaller of the configured critical days and the configured fraction of total lifetime, and warning shrinks by the same ratio. For example, with the defaults a six-day certificate has a critical cutoff of 1.2 days and a warning cutoff of 3.6 days. Classification uses the integer days remaining, so these are not hour-precise notification schedules. Longer-lived certificates retain the configured day limits. Without a known total lifetime, the day limits apply directly.

The Overview tiles follow each organization's expiry policy; the per-organization counters on the Organizations page (expiring within the critical day limit or below the lifetime percentage) use the platform defaults. These aggregate counters need not equal the number of critical-colored rows; an attention item and a certificate's severity badge answer different questions. Expiry classification does not change an Agent's renewal schedule.

Last seen¶

Every row shows how long ago it was last reported, from any source - the most recent of a public probe, an internal scan, or an ACME renewal touching that exact certificate. A certificate that stops being reported (a decommissioned host, a retired scanner) will show a growing "last seen" age even if nothing else about it changes.

Acknowledging and pausing¶

• Acknowledge (in the Alerts block of the detail drawer's Actions tab, with an optional reason) hides a certificate from the dashboard overview and alert webhooks everywhere - use it for a certificate you know about and don't need reminders on (a deliberately long-lived internal root, for example). The row shows an acknowledged pill; Resume alerting undoes it. Operators and Administrators can acknowledge.
• For an internally-scanned certificate specifically, you can pause alerts from just one reporting host without acknowledging the certificate everywhere else - useful when one machine's scan is noisy but the certificate itself still matters elsewhere.

An effective CA ignore policy is shown as policy ignored on the row and ignored by CA policy in the detail header. Only CA certificates can be policy-ignored; a site (leaf) certificate is never policy-ignored even if its fingerprint were added to a list, so acknowledge leaves instead. The Agent can receive the ignore policy and skip uploading a matching certificate observation; a platform-assigned endpoint then records a neutral Skipped by certificate policy check instead of a failed probe.

Bulk actions¶

Select multiple rows with the checkboxes to Acknowledge selected or Delete selected in one action, with an optional shared reason for a bulk acknowledge. Deleting a certificate here doesn't block it from reappearing - if a scanner or agent reports it again, it's simply re-added to the inventory.

Exporting¶

Export CSV… opens a column picker; Download CSV then downloads the currently filtered/searched list (capped at 5,000 rows) for further analysis outside the dashboard. Any cell that begins with =, +, - or @ (or with a tab or line break) is prefixed with an apostrophe so spreadsheet programs treat it as text rather than a formula. Spreadsheets hide the apostrophe; scripts reading the CSV will see it.