No certificates found
The client’s Certificates tab reads “No certificates found”, or the Domains page shows No certs against a row. The scan finished; it just came back empty.
First, confirm the scan really completed
Section titled “First, confirm the scan really completed”Open the client. If the message is “Scanning for certificates…” rather than “No certificates found”, discovery has not finished yet and there is nothing to fix. See scan is stalled or deferred.
When a scan has completed with nothing found, Tidehawk says so plainly, and adds that discovery may have been temporarily unavailable, that you can select Run Discovery to try again, and that it will retry automatically within six hours.
Check the hostname
Section titled “Check the hostname”Work through these in order.
- Is the hostname the one that serves TLS? An apex like
example.commay redirect towww.example.comwithout presenting a certificate itself. Add the hostname people actually browse to. - Is it a public name? Tidehawk resolves and connects from the internet. A hostname that only resolves inside your client’s network, or a name in a private DNS zone, cannot be reached. Internal names are the most common cause of an empty result.
- Is TLS on the port you tracked? The active scan connects on port 443 unless you added a port. If the service listens on 8443, track
host.example.com:8443. - Was there a typo? Tidehawk validates the top-level domain at entry, so
example.conwould have been rejected, butexmaple.comis a perfectly valid domain that simply is not your client’s.
Check whether certificates exist at all
Section titled “Check whether certificates exist at all”If the client’s certificate is brand new, transparency logs may not carry it yet, and if the service is not yet deployed there is nothing for the active scan to read either. Give it a few minutes and run discovery again.
If the certificate is internally issued or self-signed, it will never appear in a transparency directory. The active TLS scan is the source that finds those, and it needs to be able to reach the host.
Run discovery again
Section titled “Run discovery again”- Open the client.
- Select Run Discovery, or Re-scan where certificates already exist.
- The button changes to Scan queued and the progress banner takes over.
Manual re-scans are rate-limited per workspace, so a burst of repeated presses is refused with a message asking you to slow down. Waiting a minute clears it.
Check whether the scan was degraded
Section titled “Check whether the scan was degraded”Open the Domains page and look at the Discovery column for the domain. Degraded means only the active TLS scan ran and no transparency directory answered. A degraded scan finds the deployed certificate but can miss issued certificates that are not currently served. Selecting the row shows the last scan time, the quality and any failure reason.
A degraded scan is not permanent. The six-hourly sweep will try the directories again.
Check the certificate is not attached elsewhere
Section titled “Check the certificate is not attached elsewhere”A certificate is matched to a client through its subject alternative names. If a certificate covers several of your clients’ domains, it is attached to one client, and the client page annotates a certificate with “covers” and the names that matched, so you can see why it is filed where it is.
Search the full inventory for the hostname before concluding it was not found. The search box covers hostname, client, issuer and serial.
Still nothing
Section titled “Still nothing”If the hostname is public, serves TLS on the tracked port, and repeated discovery still returns nothing, contact support@tidehawk.co with the client name and the hostname, or use the form at https://tidehawk.co/contact.