Certificates can list several DNS names in their Subject Alternative Name field. SSLBoard reads those names and reports the adjacent domains that turn up alongside yours.
The usual explanation is mundane: shared hosting platforms and CDNs bundle many customers onto one certificate, so your name sits next to strangers. Why is a domain I do not own on my certificate? walks through when that is fine. Occasionally it is more interesting, such as a name from a merger you did not know was still deployed, or a certificate a contractor issued years ago.
What the relationship establishes
That a certificate carries both names. Nothing more.
It does not establish common ownership, an active service, or a vulnerability. A certificate containing www.example.com and a name under a different domain is a relationship worth a question, not a finding.
Scope stays where you put it
Adjacent domains are context. They are not silently added to the report’s TLS assessment. If you want results for another domain, scan it separately and read its own discovered-host inventory.
Two non-conclusions to avoid:
- A wildcard in a certificate does not enumerate the names beneath it.
- An empty adjacent-domain list does not mean the organization has no other domains.
Reviewing an unexpected one
Look at the certificate names and the issuer, then ask whoever operates that service whether the shared certificate is deliberate. On a managed platform the answer is almost always yes.
If a deployment or certificate changes, retest to see what is now served. Discovery and coverage helps you separate a historical name from a live service.