Skip to content

Managing Discovered Certificates

Certificates found by discovery scans are imported into your certificate inventory alongside certificates provisioned through the platform. This page covers how to view and interpret discovered certificates, understand how deduplication and host tracking work, and act on the findings.

Certificate Inventory

Discovered certificates are accessible under CLM → Certificates in the web portal. Each certificate in the inventory includes a source field that indicates its origin:

Source Meaning
managed Certificate was provisioned through the Zaita platform.
discovered Certificate was found by a Bridge-based Discovery Job or CT log scan.

Use the source filter to view only discovered certificates, or view the full inventory across both sources for a complete picture of your certificate estate.

What Is Recorded for Each Certificate

When a Bridge reports a certificate, the platform extracts and stores:

  • Common name and subject details
  • Issuer and certificate chain information
  • Validity period (not before / not after) and days until expiry
  • Key algorithm and size
  • Subject alternative names (SANs)
  • SHA-256 fingerprint
  • The Discovery Job that found the certificate
  • The IP address and port where the certificate was found

Deduplication

Certificates are deduplicated by SHA-256 fingerprint within your tenant. If a scan finds a certificate that already exists in the inventory (same fingerprint), no duplicate record is created. Instead, the existing record is updated:

  • last_seen_at is refreshed to the time of the latest scan.
  • The source IP address and port are updated to reflect the most recent discovery location.

This means the inventory count reflects unique certificates, not scan sightings. A certificate discovered weekly for six months will appear as a single inventory entry.

Multi-Host Tracking

The same certificate is often deployed across multiple hosts — for example, on the members of a load balancer cluster, or on multiple servers sharing the same wildcard certificate. The platform tracks every unique IP address and port combination where a certificate has been found.

For each certificate in the inventory, the Discovered Hosts section on the detail page lists:

Column Description
IP Address The host where the certificate was found
Port The port on which the certificate was presented
Hostname Resolved hostname, if available
First Seen When the certificate was first discovered on this host
Last Seen When the certificate was most recently confirmed on this host

A host entry is created the first time a certificate is found on a given IP:port pair. Subsequent scans update the Last Seen timestamp rather than adding a new row, so the history remains clean regardless of scan frequency.

Reviewing Discovered Certificates

Certificates discovered outside your provisioning workflows — by CT log scanning or by Bridge-based scanning — should be reviewed to understand their origin and assess whether they are operating within your policies.

Recommended review workflow:

  1. Filter for discovered certificates — navigate to CLM → Certificates and filter by source: discovered.
  2. Check the issuer — is the certificate issued by a known and trusted CA? Unexpected issuers may indicate shadow PKI or a misconfigured third-party integration.
  3. Check the subject and SANs — does the certificate cover only the domains or services it should?
  4. Check the validity and algorithm — certificates with weak algorithms, very short, or very long validity periods may fall outside your policy.
  5. Check for expiry — certificates approaching expiry that are not under platform management will not be renewed automatically. If they should be, bring them under management.

Certificates Not Provisioned Through the Platform

Certificates discovered that were not provisioned through the Zaita platform are flagged for investigation. These may represent:

  • Certificates legitimately issued by another team or via a different tool.
  • Certificates issued by a CDN or cloud provider on your behalf.
  • Certificates that pre-date your adoption of the platform.
  • Unexpected or unauthorised issuance that warrants investigation.

Review flagged certificates promptly. If a certificate is legitimate and should remain under management, it can be associated with the appropriate provisioning workflow going forward.

Discovery Job Metrics

Each Discovery Job records the following metrics, visible on the job detail page:

Metric Description
Status Current job state: active, inactive, running, or abandoned.
Last Run At Timestamp of when the most recent scan completed.
Next Run At Timestamp of the next scheduled scan (if a schedule is configured).
Discovered Certificates Count Total unique certificates found across all runs of this job.

The discovered_certificates_count is derived from the actual number of certificates associated with the job, not a running tally, so it remains accurate even if certificates are deleted from the inventory.

A job in running status is actively being executed by the Bridge. If the Bridge stops sending heartbeats while the job is running, the platform automatically transitions the job to abandoned after 60 seconds. An abandoned job can be re-activated and re-triggered once the underlying Bridge issue is resolved.

Next Steps