Do CT logs show internal certificates?

No. CT covers only certificates issued by public authorities; internal PKI certificates need network scanning.

How long does a scan take?

A /24 range scans in a few minutes; large organisations repeat scans on a schedule.

Can we keep the inventory by hand?

At small scale, for a short time. With shrinking lifetimes a manual list ages quickly; discovery and verification should be automated.

Guide

How to build a certificate inventory: discovery, ownership, records

Before automating renewal, one question must be answered: which certificate, on which system, owned by whom? In most organisations half of that list is missing.

31 August 2026 · 6 min read

Where certificates live

Load balancers and reverse proxies: the most visible place, but the systems behind them may hold certificates too.
Web and application servers, API gateways, Kubernetes ingresses and Secret objects.
Mail, VPN, directory (LDAPS) and database servers; management interfaces (BMC, switches, storage).
Internal tooling: CI/CD, monitoring, logging; most of it runs on self-signed or internal PKI certificates.
Cloud resources: managed load balancers and CDNs carry their own certificates.

Discovery methods

Network scanning: Ports speaking TLS in given IP ranges are scanned and the served certificate is read. The most direct way to find internal endpoints; read-only, it touches nothing.
Certificate Transparency (CT): Every publicly trusted certificate is written to public CT logs (RFC 9162). Tools such as crt.sh list every certificate ever issued for a domain; forgotten or unauthorised issuances surface.
DNS and cloud inventories: DNS zones and cloud accounts provide the names that need scanning.
Configuration management: Certificate paths in server configuration files show how many places the same certificate is installed in.

What every record needs

Identity: The SHA-256 fingerprint; it separates versions issued for the same domain.
Domain names: CN and the SAN list.
Issuer and chain: Authority, intermediate, root. Serving an incomplete chain is a common mistake.
Lifetime: Expiry date and alert threshold.
Where it is installed: System, port, file path or object name; one certificate may live in several places.
Owner and renewal path: The responsible team; renewed through ACME or by hand.

Common pitfalls

The same certificate installed in three places, renewed in one: the old version is still served.
An expired certificate is still served and nobody notices; clients have disabled verification.
Incomplete chain: desktop browsers work, the mobile app or API client fails.
Self-signed and internal certificates are missing from the inventory; nobody tracks their expiry.

Standards and guidance

NIST's SP 1800-16 describes TLS server certificate management as an enterprise programme: inventory, ownership, automation, monitoring and incident response.

Automation does not start before the inventory is complete.
Every certificate has an owner and a renewal method.
Shorter lifetimes make manual processes impossible to scale; the guide explicitly recommends automation.

Frequently asked questions

Do CT logs show internal certificates?: No. CT covers only certificates issued by public authorities; internal PKI certificates need network scanning.
How long does a scan take?: A /24 range scans in a few minutes; large organisations repeat scans on a schedule.
Can we keep the inventory by hand?: At small scale, for a short time. With shrinking lifetimes a manual list ages quickly; discovery and verification should be automated.

Sources

Manage your certificates in one place

Inventory, expiry tracking, renewal through ACME and verified installation, on your own infrastructure.

Request a demo