Discovery methods
Trust Architecture Playbook: Baseline pillar
There are many sources for certificate discovery, some of which provide higher fidelity than others. When building your trust baseline in DigiCert® Trust Lifecycle Manager, focus on the following discovery methods.
Connectors and integrations
Connectors integrate directly with the systems that manage certificates (load balancers, cloud certificate services, vaults, issuing CAs, etc.) and therefore deliver richer, more reliable data than a network scan can infer from a TLS handshake. Prioritize onboarding these high-fidelity sources first and use scans to fill in the gaps.
注記
A scan may see a certificate, but a connector sees the certificate and its context: where it’s managed, how it was issued, and who owns it.
Recommended connector onboarding sequence
Load balancers and ingress tiers (for example, F5).
Issuing CAs (for example, Microsoft AD CS) for authoritative issuance metadata.
Cloud certificate services and load balancers (AWS/Azure/GCP).
Vaults and secrets managers used by applications or orchestration.
Scan solution imports (vulnerability management scanners) to broaden coverage quickly.
Connector hygiene checklist
Use least-privilege service accounts and rotate credentials per policy. Where possible, use a supported vault or secrets manager to store and manage credentials.
Assign each connector a clear organizational boundary (for example, business unit or platform team).
Use assignment rules where possible to automatically assign tags and owners to imported certificates.
Apply default tags at ingestion (
platform,environment,discovery_source) to avoid unlabeled inventory.Review connector health and data freshness on a defined cadence.
Examples (commonly deployed)
The most commonly deployed connectors cover the systems where certificates are most likely to live — and most likely to cause an outage if overlooked:
F5 BIG-IP LTM: Certificate and endpoint discovery across load balancers, where many organizations hold their highest-traffic and highest-stake TLS termination points.
Microsoft AD CS: Private trust issuance inventory and lifecycle alignment for organizations running internal PKI through Microsoft CA.
Public CAs: Public trust issuance inventory and lifecycle alignment for DigiCert and any third-party CA vendors like Entrust, GlobalSign, and Sectigo.
Cloud provider connectors: Coverage for cloud-native load balancers and certificate managers across AWS, Azure, and GCP environments.
Secrets managers, vaults, and orchestration tools (HashiCorp, Ansible, Puppet, Chef): Surface certificates stored outside traditional PKI workflows and establish the integration points you'll need when automation comes online in later phases.
Scan solution connectors (Qualys, Tenable): Import IP/port certificate findings from existing vulnerability scan infrastructure, extending coverage without redundant tooling.
Network scanning
Network scanning is the fastest way to identify what is bound to ports as well as to find unknown endpoints. It's most useful when scoped and operated with safety controls (rate limiting, maintenance windows, and exception zones).
Operational best practices
Roll out scanning in rings (external edge, DMZ/ingress, internal tiers, legacy/OT), using assignment rules where possible to automatically apply tags and owners to the discovered certificates.
Avoid very large monolithic scans. Instead, configure multiple smaller-sized scans and schedule them for different times on the managing sensor. Recommended maximum limits per scan are 10,000 FQDNs/IPs or two /16 CIDR blocks.
Deploy multiple sensors where possible for availability and ability to run parallel scans. Place sensors strategically on local subnets to avoid having to open firewall ports for scanning.
Define scanning guardrails with network owners (allowed subnets/ports and throttle limits).
Account for SNI where applicable, otherwise expect default certificates on shared endpoints.
Treat network findings as evidence of exposure, not proof of ownership.
Cloud scanning
Cloud scans provide a view of your public-facing certificate posture without requiring any scanning infrastructure on your side. The scan operates from outside your environment, which is exactly the point.
What you see in a cloud scan is what your customers (and attackers) see. If a certificate is expired, misconfigured, or issued outside your approved channels, it’s visible to anyone doing reconnaissance on your domains. Treat these results as your external reality check: if something looks wrong from the outside, it’s most likely wrong, regardless of what your inventory says.
Recommended use
Scan all primary domains and public IP ranges, including CDN-exposed origins where applicable.
Always use assignment rules where possible to automatically assign tags and owners to discovered certificates.
Schedule recurring scans and configure notifications to alert on newly discovered certificates and status changes.
Cross-check cloud scan results against CT monitoring for completeness and anomaly detection.
System scanning
System scans provide visibility where network scans can’t, directly on the host, surfacing certificates and keys stored in local keystores, including artifacts that are staged, unused, or never made it into your inventory through any other discovery channel.
This depth makes system scans the most valuable feed for automation planning by telling you what’s deployed. Before you can automate renewals and deployments with confidence, you need to know the local reality, not just what the platform thinks it knows.
重要
Privacy and risk note
System scans may reveal sensitive material (for example, private keys, keystore files). Limit scope, document exclusions, and align with internal security and compliance requirements.
Recommended starting points
Representative critical web hosts (IIS, Apache, NGINX).
A Java application tier (JKS/PKCS#12).
Gateways or middleware where certificates are frequently embedded (API gateways, brokers).
Certificate Transparency monitoring
All publicly trusted certificate issuance for any of your domains gets logged to Certificate Transparency (CT) logs whether you knew about the issuance or not. CT logs monitoring gives you near-real-time visibility into that activity, surfacing certificates the moment they’re logged rather than waiting for a scan cycle to catch them.
This is what makes CT monitoring one of the most effective controls for detecting unexpected issuance. If anyone issues a certificate for your domain, whether through a misconfigured system, an unauthorized request, or something more deliberate, CT monitoring can alert you before it becomes a problem.
Triage workflow (recommended)
Was the certificate approved/expected? Map it to a known service, owner, and issuance path.
If unexpected, determine whether it is a legitimate third-party (CDN/SaaS/MSP) or a mis-issuance concern.
Escalate suspicious findings with issuer details, timestamps, and relevant CT log entries.