Skip to content

Certificate Discovery

Certificate discovery is the process of identifying and cataloguing certificates across your organisation's infrastructure. Without comprehensive discovery, certificates can go untracked — leading to unexpected expiries, outages, compliance gaps, and security blind spots.

The Zaita platform provides automated discovery mechanisms that continuously scan for certificates and import them into your centralised certificate inventory, giving you a single view across your entire certificate estate.

Why Certificate Discovery Matters

Most organisations have far more certificates deployed than they realise. Certificates are issued by internal CAs, public CAs, cloud providers, and third-party services — often by different teams with no central visibility. Common risks of untracked certificates include:

  • Unplanned outages from expired certificates that were not renewed.
  • Security exposure from certificates issued with weak algorithms or by unknown authorities.
  • Compliance failures from certificates that fall outside organisational policy.
  • Shadow PKI from certificates provisioned outside approved workflows.

Automated discovery addresses these risks by continuously surfacing certificates without requiring manual audits or reliance on teams to self-report.

Discovery Methods

The platform supports two complementary discovery mechanisms. Used together, they provide broad coverage across both external and internal certificate estates.

Certificate Transparency (CT) Log Scanning

Certificate Transparency is a public, append-only log system that records certificates issued by publicly trusted certificate authorities. The Zaita platform automatically queries CT logs for all certificates issued against your registered domains, importing discovered certificates into your inventory.

CT log scanning provides:

  • External visibility — discovers certificates issued by any public CA for your domains, including certificates you may not have requested (for example, those issued by a CDN provider or a third party).
  • No network access required — CT logs are public; scanning does not require connectivity to the systems hosting the certificates.
  • Detection of unexpected issuance — surfaces certificates issued outside your approved provisioning workflows, which may indicate misconfiguration or compromise.

CT log scanning runs on a configurable schedule. The platform will alert you to newly discovered certificates that were not provisioned through the platform, enabling rapid investigation.

Bridge-Based Network Scanning

For certificates deployed within internal networks that are not exposed to the public internet, Bridges perform active TLS scanning within your enterprise environment. A Bridge deployed inside your network probes configured IP addresses and port ranges, captures the certificate presented in each TLS handshake, and reports results back to the platform — without requiring any inbound connectivity from the Zaita control plane.

Bridge-based discovery is the primary mechanism for internal network certificate visibility. It is configured using Discovery Jobs — named, schedulable scan configurations assigned to a specific Bridge.

Discovery Jobs

A Discovery Job defines a scan configuration that a Bridge executes. Each job specifies:

Field Description
Name A descriptive label for the job (for example, Production Network Scan).
Bridge The Bridge instance that will execute the scan.
IP Ranges The network addresses to scan. Supports CIDR blocks, IP ranges, and single addresses.
Ports The TCP ports to probe on each address.
Schedule A cron expression defining when the Bridge runs the job automatically, or leave unset for manual-only execution.

Multiple Discovery Jobs can be created per tenant, each assigned to the most appropriate Bridge for its target network segment.

IP Range Formats

Each entry in the IP ranges list can be one of three formats:

Format Example Description
CIDR 192.168.0.0/24 All addresses in the subnet
Range 10.0.0.1-10.0.0.254 Inclusive range between two addresses
Single 172.16.0.5 A single address

Multiple ranges can be specified per job.

Configurable Ports

Ports are specified as a list of integers per job. The platform accepts any valid TCP port (1–65535). Common ports used for TLS-enabled services:

Port Service
443 HTTPS
8443 HTTPS (alternative)
8080 HTTP alternative (TLS-enabled)
636 LDAPS
993 IMAPS
995 POP3S
1433 SQL Server
3306 MySQL
5432 PostgreSQL

Scheduling

Discovery Job schedules use a standard 5-field cron expression (minute hour day month weekday). If no schedule is set, the job runs on-demand only.

A schedule_description is shown in the UI alongside the cron expression (for example, "Daily at midnight", "Every 6 hours").

Job Status

Status Meaning
active The job runs on schedule and can be triggered manually.
inactive The job will not run automatically and cannot be triggered until re-activated.
running The job is currently being executed by the assigned Bridge.
abandoned The job was running but the Bridge stopped sending heartbeats. The platform automatically marks a running job as abandoned if no heartbeat is received within 60 seconds, allowing the job to be re-triggered once the issue is resolved.

On-Demand Execution

Any active Discovery Job can be triggered for immediate execution without waiting for the next scheduled run. The control plane sets a run_now flag on the job; the assigned Bridge reads this flag on its next heartbeat check-in and begins the scan immediately.

How Scan Results Are Processed

When a Bridge completes a scan, it uploads the discovered certificates to the control plane in a single batch. For each certificate in the batch:

  1. The certificate PEM is parsed and a SHA-256 fingerprint is computed.
  2. If the fingerprint is new — a new certificate record is created in the inventory with source: discovered.
  3. If the fingerprint already exists — the existing record is updated (last_seen_at, source IP, and source port are refreshed). No duplicate record is created.
  4. The IP address and port where the certificate was found are recorded in the host tracking table.

This fingerprint-based deduplication ensures each unique certificate appears exactly once in the inventory, regardless of how many times it is seen across scans.

Multi-Host Tracking

The platform tracks every IP address and port combination where a certificate has been found. The same certificate can be deployed across multiple hosts — for example, on a load balancer cluster — and each unique IP:port pair is tracked independently, with timestamps recording when the certificate was first and last seen on that host.

Discovery vs Provisioning

Discovery and provisioning are complementary but distinct capabilities:

Discovery Provisioning
Purpose Find and catalogue existing certificates Request and issue new certificates
Direction Inbound — certificates are found and imported Outbound — certificates are created and deployed
Scope Any certificate on registered domains or scanned networks Certificates issued by the platform's CAs or integrated external CAs
Automation Runs on a schedule automatically Triggered manually, via API, or through Bridges and Couriers

A mature certificate management practice uses both: discovery to maintain visibility across the full estate, and provisioning to issue and deploy certificates through controlled, policy-governed workflows.

Next Steps