Find candidate hostnames
Public certificate and hostname datasets reveal names worth checking. Nocert treats them as discovery signals, not proof that a certificate is still deployed.
Certificate Transparency and passive hostname data Automatic certificate discovery
Automatic TLS Certificate Discovery for Public & Private Networks
Build a live certificate inventory from public hostname signals, read-only DNS zones, and outbound-only Sentinels. Nocert checks what is actually served or stored, then shows where each certificate was observed, without replacing your CA or collecting private keys.
Full 30-day Business trial, then a free plan for up to 10 certificates. No payment card. No paid plan starts automatically.
Inventory starts with observation
Issued is not the same as deployed
CA records tell you what was issued. Certificate Transparency tells you what was publicly logged. Neither proves which certificate a service presents today, whether the old one still exists on another endpoint, or what is stored inside a private environment.
Nocert uses those records to find places worth checking, then relies on live endpoint and Sentinel observations for deployment evidence. The result is an SSL/TLS certificate inventory tied to real locations, not a list of names detached from infrastructure.
Why Certificate Transparency is a signal, not an inventory Coverage layers
Discover certificates from outside and inside
Each source answers a different question. Nocert keeps the source and location context so your team can tell a lead from a live deployment.
Check what endpoints serve now
Nocert connects to reachable TLS services and records the certificate and TLS details actually presented by the endpoint.
Hostname, IP, port, SNI, certificate chain, and TLS observationExtend coverage from your zones
Cloudflare DNS and Route 53 connectors read the zones your credential can list. Imported hostnames seed live scans once they fall under a verified domain.
DNS access is read-only; imported records are candidates for scanningObserve from inside your environment
Outbound-only Sentinels run network, host-local listener, filesystem, and Kubernetes discovery. Network mode can also receive targeted hostname probes derived from SANs on newly observed leaf certificates.
Four independent switches, no inbound firewall rule, and no private-key custodyInspect services on the Sentinel host
A separate local-listener mode enumerates listening TCP ports on the Sentinel machine and probes them from the host itself.
Separate from network mode and excluded from the tenant-facing deployment inventory From domain to inventory
Automatic where it should be. Explicit where it matters.
Public discovery starts with the domain of the verified work email used at signup. Proof of control unlocks wider public discovery; private discovery depends on the Sentinel modes you enable.
- 01
Seed public coverage
After signup, the domain of the verified work email seeds a one-off public scan and one pass over public hostname datasets. What that finds keeps being rescanned, and in-zone SAN hostnames are followed. Querying those datasets again, and scanning DNS connector imports, wait for DNS TXT proof of control.
- 02
Configure private discovery
Deploy Sentinel where external scanners cannot reach. Review its network, local-listener, filesystem, and Kubernetes switches and their settings; network mode also permits targeted SAN-derived hostname probes.
- 03
Collect deployment evidence
Public scanners and Sentinels report what they actually observe. Observations with the same fingerprint are grouped into one certificate record with its deployment locations.
- 04
Keep the inventory actionable
Recurring discovery refreshes the inventory while expiration rules route findings to email, Slack, Microsoft Teams, or Discord.
Deployment evidence
Know where a certificate was found
The same certificate can be served on several endpoints, left on a host after a migration, and mounted in more than one cluster. Nocert groups observations by certificate fingerprint while preserving the available location context.
- Endpoints: host or IP, port, SNI, and observed TLS details.
- Filesystems: Sentinel identity and certificate path.
- Kubernetes: cluster, namespace, object, and data field.
- Freshness: source and observation timing for operational follow-up.
Source boundaries
What each discovery source can prove
The inventory remains useful because Nocert does not pretend every source has the same level of evidence.
| Source | What it finds | Boundary |
|---|---|---|
| Public datasets | Candidate hostnames and certificates seen in public records | A public record does not prove that a certificate is still live |
| Internet endpoint scan | The certificate and TLS configuration served by a reachable host and port | Cannot see services that are private or blocked from the internet |
| Read-only DNS import | Hostnames in the Cloudflare DNS and Route 53 zones your credential can list | Only hostnames under a verified domain become scan targets, and a DNS record is scanned before it becomes deployment evidence |
| Sentinel network scan | TLS services from configured CIDR and port sweeps, plus SAN-derived targeted hostname probes | The network switch gates both; targeted SAN probes are not restricted to the configured CIDR list |
| Sentinel local-listener scan | TLS listeners on the Sentinel host, enumerated and probed from the host itself | Uses a separate switch and stays outside the tenant-facing deployment inventory |
| Sentinel filesystem scan | Readable leaf-certificate files and their retained paths | CA files read from disk can be kept as certificates without a filesystem finding or path; permissions limit coverage and private keys are not sent |
| Sentinel Kubernetes scan | Certificates in configured clusters and namespaces, with object and data-field context | Uses the credentials and read-only RBAC you provide; certificate values can be sent, while private-key values such as tls.key are excluded |
Private discovery boundary
Sentinel reaches out. Nothing reaches in.
Sentinel polls Nocert over outbound HTTPS and signs requests with an Ed25519 key generated locally. It accepts no inbound connections and requires no inbound firewall rule.
Customer-controlled modes
Network, local-listener, filesystem, and Kubernetes discovery are independently switchable; network mode includes sweeps and SAN-derived probes.
No private-key custody
Certificate DER and scoped metadata leave the environment; private-key bytes do not.
Auditable agent
Review the signed Apache-2.0 source archive and reproduce the published build.
Technical questions
Automatic certificate discovery FAQ
What does automatic TLS certificate discovery include?
Nocert uses public hostname signals to seed live endpoint scans, with optional read-only DNS imports and outbound-only Sentinel discovery. Live public scans plus Sentinel network, filesystem, and Kubernetes observations feed the deployment inventory; local-listener observations remain in the separate host-local index.
Can Nocert discover certificates on private networks?
Yes. A Sentinel can sweep the private CIDRs and ports you configure. When network mode is enabled, it can also receive targeted hostname probes derived from SANs on newly observed leaf certificates. Network, local-listener, filesystem, and Kubernetes discovery can be disabled independently; local-listener observations stay outside the tenant-facing deployment inventory.
Does automatic discovery scan my entire network?
Periodic network sweeps stay within the CIDRs and ports you configure. However, a network-enabled Sentinel can also receive targeted FQDN probes from the SANs of newly observed leaf certificates, including certificates found on disk, in Kubernetes, or on a host-local listener; those probes are not confined to the CIDR list. Disabling network mode stops both kinds of network probe, but host-local listener discovery has its own switch. Sentinel exposes no inbound administration channel.
Does Nocert need access to private keys?
No. Sentinel reports certificate DER and scoped location or TLS metadata. Certificate private-key bytes, Kubernetes private-key values such as tls.key, Kubernetes credentials, kubeconfig contents, scanned-service credentials, and unrelated file contents stay in your environment.
Does Nocert replace my CA, ACME client, or certificate manager?
No. Nocert is the discovery, inventory, and monitoring layer. Your existing CA, ACME client, Vault or OpenBao, cert-manager, AD CS, or lifecycle manager remains responsible for issuance, renewal, revocation, and deployment.
Start with public discovery
See what Nocert can find for your organization
Enter your company domain, continue with a work email, and evaluate the complete Business feature set for 30 days. Add private discovery only when you are ready to review and set the Sentinel modes you need.
Review plans and limits