Find candidate hostnames
Public signals
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 dataAutomatic 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 50 certificates. No payment card. No paid plan starts automatically.
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 these records to find hostnames to check. Endpoint scans and Sentinel then record where certificates are presented or stored.
Why Certificate Transparency is a signal, not an inventoryDiscover 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
Live internet scan
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 observationImport hostnames from your DNS zones
Read-only DNS
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
Private discovery
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
Host-local listeners
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 inventoryChoose the domains and internal environments to monitor
Public services
- Add your domain
example.com - Verify control by DNS TXT
Internal services
- Connect Sentinel
- Choose the sources to observe
Observed certificatesOne shared inventory
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.
What each discovery source can prove
A hostname in a public record, a certificate served over TLS, and a certificate file provide different information. The table below describes each source and its limits.
| 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 |
Sentinel uses outbound connections only
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.
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.
See what Nocert can find for your organization
Create a professional workspace and evaluate Business for 30 days without a card. You can start with an authorized public domain or configure a Sentinel for internal discovery. At signup, Nocert can add your email domain and start public certificate discovery before DNS TXT verification. Domains such as gmail.com and outlook.com are excluded.
Compare plansPublic domain to monitor (optional)
Continue to signup
We’ll email you a code to verify your email address.