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. An Agent's certificate is listed as soon as the Agent reports it issued. Until it is installed it carries one more pill: Issued, not installed yet, Issued, waiting for its deployment window or Issued, installation failed (the Agent tries again by itself; ACME Renewals has its message). 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; internal-scanner and ACME-renewal rows fold out the certificate metadata that report carried, including the decoded X.509 extensions) 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.

A certificate is marked revoked when a monitored CRL lists it or when the Agent that manages it reports that it revoked it at the CA. Its expiry chip then says revoked instead of the days left - in the inventory, in the certificate page's header, and on a site or internal endpoint that serves it (hover it for the revocation time and the days it would have had) - and its Lifetime reads Revoked. The certificate enters the certificate.revoked alert, its renewal shows as stopped, and its detail shows Revoked: replace or remove with the command that replaces it on the Agent host (certintel certificates issue ID). For a revocation the Agent reported, that block also shows Revoked by - the local account that asked on the Agent host, for example root (uid:0) - and Reason given to the CA (None given without one), which the Agent reports (revoke --reason). For Key compromise it adds that the replacement needs a new key, which certintel certificates issue generates. Revoking does not remove the certificate from the server or delete deployed files; see Revoking a certificate.

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 or for this tenant, 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 for this organization, for this tenant or (platform administrators) platform-wide, 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:

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.

A planned renewal happens only while the Agent reports. When the Agent that planned it is late or offline, or its key cannot report (disabled, expired or unregistered), the certificate list shows a renewing agent late or renewing agent offline pill (renewing agent disabled, and so on) next to the expiry, with the Agent's state as its tooltip, and the certificate's page adds … is late: Last report 3 h ago, expected every hour. The planned renewal happens only while it reports; inspect the agent - the Agent's name and the link only for a role that can read Agents. See An Agent shows Late or Offline. 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 an endpoint, public or internal, 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.
• When the endpoint is added, if a managed certificate's latest successful renewal in the same organization already covers its hostname.
• 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 alert (Public or internal endpoint still serving an old certificate, see Alerts): it is alerted once and then listed in the daily summary until the endpoint serves the renewed certificate.

Internal endpoints, which an Agent probes, are linked and compared the same way, with their own Expected certificate section and filter on Internal Endpoints. Because CertIntel only knows what the Agent's last probe saw, they have one more status, renewed, not checked since the renewal; see Served versus issued for internal endpoints. The public list filtered to serving an old certificate says how many internal endpoints do the same, with a link, and the internal list says it of the public ones.

CAA records¶

Before a renewal, the CA that issued an endpoint's certificate checks the domain's CAA records again. On Public Endpoints, a badge under an endpoint's status says when they would stop it: CAA blocks <CA>, or CAA: check when the lookup failed or a record cannot be compared (nothing is shown when CAA allows the CA). The endpoint's details have a CAA records for <CA> section, open when CAA blocks it, with the records that decide and the exact record to add. The CA is taken from the served certificate's issuer; a private or unknown CA cannot be checked, and internal names and IP addresses are not applicable. A host covered only by a wildcard certificate is checked for the wildcard (issuewild). See CAA records.

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 <cap>: <text>:

The reasons name what is actually wrong. The chain is incomplete means a path to a trusted root needs a certificate the server did not send; a server that sends its whole chain up to a root that is not trusted gets No trusted certification path. and nothing about completeness. An expired certificate whose chain reaches a trusted root gets only the expiry reason, not No trusted certification path. A leaf for another name that is also sent without its intermediate is listed with the status hostname mismatch (the worse problem), as its grade says.

An endpoint whose host is an IP address (192.0.2.10:443) is checked against the certificate's IP address SANs, so a certificate that names that address is not a hostname mismatch.

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 server that offers only TLS 1.1 or older cannot complete the regular TLS 1.2+ probe; with legacy probing on (see below) it is graded F with Only TLS 1.1 or older is offered. 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 <X> 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). The Agent submits every well-formed chain.

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.

The day limits count whole days left, as the certificate list shows them: a certificate with 21.9 days left shows 21d, so a warning at 21 days starts 22 days before expiry, and a critical cutoff at 7 days starts 8 days before.

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. With the defaults this applies to a certificate valid for less than 35 days; for example, a six-day certificate has a critical cutoff of 1.2 days and a warning cutoff of 3.6 days. These shorter windows compare the exact time left, not whole days. Longer-lived certificates retain the configured day limits. Without a known total lifetime, the day limits apply directly. The organization's Edit form and each alert destination's First expected say when the windows start in these words.

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.