SSLBoard combines public discovery data with active checks. The discovery data helps identify names to investigate; the live checks establish what those names expose when the scan runs.
Public certificate records identify hostnames
Certificate Transparency records make publicly logged certificates discoverable. Names associated with those certificates provide a starting inventory for a domain. SSLBoard requests names within the submitted domain’s scope and uses the domain itself as a fallback if discovery returns no names.
These names can include services you no longer use. A historical record does not disappear when a certificate expires or a DNS record is removed. Conversely, a hostname that has never appeared in the discovery data may not be found.
A wildcard such as *.example.com is not a list of all subdomains. SSLBoard can derive candidates from wildcard entries, but that does not enumerate every name that could match the wildcard. See discovery and coverage limits.
DNS tells us where to look
DNS lookups help resolve discovered names to network addresses and inspect published policies such as CAA and DNSSEC. For email security, the submitted domain’s mail routing and authentication policies determine the mail hosts and records to inspect. Discovered MX hostnames are normally kept in the email assessment rather than the ordinary web target list; the submitted hostname itself remains in the web scope.
DNS describes the public view available during the scan. Internal DNS, recently changed records, and different answers returned to other locations can produce a different inventory.
Live connections inspect deployment
For normal web deployment inspection, SSLBoard targets discovered hostnames on port 443. It connects to public endpoints to collect certificates and assess TLS support. It records endpoint details so that different addresses serving the same hostname can be compared. Web checks inspect HTTP behavior and HTTPS response headers. Email checks inspect mail transport and published policies.
The certificate inventory in the report is built from certificates observed during deployment inspection. It should not be treated as a complete archive of every certificate ever issued for the domain.
What you provide
For a public scan, you provide a domain rather than server credentials or private keys. The checks use public records and connections to exposed services. Your report can still reveal operational details you would prefer not to circulate, so review report sharing before forwarding access. The privacy policy describes the site’s wider data handling.
Results are observations with a time and scope
A successful connection provides evidence about the endpoint tested. A timeout provides evidence that the connection did not complete from the scanner, but cannot establish why. A completed report can contain both useful observations and unavailable checks.
The summary translates these observations into findings and a score. Read the supporting tables when a finding affects an important service, especially where a headline combines several endpoints. Result states explains how to distinguish a gap in evidence from a confirmed issue.