SSLBoard works in three layers, and every row in your report comes from one of them. Knowing which layer produced a row tells you how much weight it carries.
- Certificate Transparency suggests names worth trying.
- DNS turns those names into addresses and published policies.
- Live connections decide what is actually true right now.
Only the third layer establishes facts about your deployment. The first two tell the scanner where to look.
Certificate Transparency suggests the names
Every publicly trusted certificate gets written to public, append-only logs. That makes hostnames discoverable without touching your DNS zone, which is how SSLBoard finds the subdomains you forgot about. It requests names in the submitted domain’s scope, and falls back to the domain itself if discovery comes back empty.
Two consequences follow, and both surprise people:
- Old names never leave. Log entries are permanent. A name whose certificate expired in 2022 and whose DNS record is long gone still appears. That is not a bug, it is your cleanup list.
- A wildcard is not a list.
*.example.comtells you nothing about whetherpayroll.example.comexists. SSLBoard can derive candidates from a wildcard entry, but nothing can enumerate the names a wildcard could cover.
So a name in the inventory is a lead, not a live server. See discovery and coverage for where the gaps are.
DNS decides where to look
DNS lookups resolve discovered names to addresses and read the policies published in the zone: CAA, DNSSEC, and the mail records. For email, the submitted domain’s own routing determines which mail hosts get probed. Discovered MX hostnames stay in the email assessment rather than joining the web target list, while the submitted hostname itself stays in web scope.
DNS is also the layer most likely to differ from what you expect. What SSLBoard sees is the public view, from its resolvers, at that moment. Split-horizon DNS, a record you changed ten minutes ago, and geo-routed answers can all produce an inventory that does not match your internal picture.
Live connections decide the facts
For web inspection, SSLBoard connects to discovered hostnames on port 443, collects the certificate each endpoint actually presents, and tests what TLS it will negotiate. It records results per endpoint, so two addresses behind one hostname are compared rather than merged. Web checks read HTTP behavior and HTTPS response headers. Mail checks probe transport and read published policies.
This is why the certificate inventory is a deployment inventory, not an archive. It lists what was served during the scan, not every certificate ever issued for you.
A timeout is evidence of a timeout
This is the distinction that makes a report usable.
A successful connection tells you something about that endpoint. A timeout tells you the connection did not complete from SSLBoard’s scanner, and nothing more. It does not tell you the host is down, firewalled, or misconfigured, and it certainly does not tell you the certificate is fine.
A report can finish with a mix of solid observations and checks that never ran. The score and findings summarize the observations it has. When a finding touches something you care about, read the table underneath it, because a headline often groups several endpoints into one line. Result states covers how to separate a confirmed problem from an evidence gap.
What you hand over
A domain name. That is the entire input.
Your report can still describe your infrastructure in more detail than you would want circulating, so check report access and sharing before forwarding a link. The privacy policy covers the site’s wider data handling.