Certificate Transparency data now live: 7 new cyber tests

Certificate Transparency is now Senserity's 34th data source, and it brings seven new tests to the Cyber category. It answers a question the rest of our cyber checks could not: what else is out there.

Until now, assessing a supplier's external security meant assessing its website. That is one address. Most companies have several, and the others are often the more interesting ones.

The problem with checking only the website

A company's main website is usually its best maintained asset. Someone owns it, someone renews the certificate, someone notices when it breaks. It is the part of the estate least likely to tell you anything alarming.

The rest of the estate is different. There is often a VPN gateway set up for remote working, a staging copy of the site left running after a redesign, or a customer portal built by an agency that has since moved on. Sometimes there is the web interface of a firewall or a network storage device that was never meant to face the internet at all. These carry the same domain, sit on the same connection, and are reachable by anyone who knows the name. Nobody looks at them, which is why they are worth checking.

Finding them has always been the difficulty. Guessing at names is unreliable and slightly rude. Port scanning a supplier you are evaluating is neither proportionate nor, in most procurement relationships, welcome.

Certificate Transparency solves the discovery problem

Since 2018, browsers have refused to trust a TLS certificate unless it has been published to a public, append-only log. The scheme exists so that a certificate authority cannot quietly issue a certificate for someone else's domain without the world noticing.

It has a side effect. Every certificate carries the hostnames it covers, so the logs are, in aggregate, a public directory of named internet infrastructure. If a company put a certificate on its VPN gateway, the name of that gateway is in the public record. Nobody has to guess.

That sounds more invasive than it is. Senserity reads a published log and then connects to the names it finds in the ordinary way a browser would, to see whether they respond and what certificate they present. It does not scan ports, probe for vulnerabilities, guess at names that were never published, or reach anything a certificate authority has not already made public. The company published these names itself, by the act of securing them.

What the seven tests check

Where each name leads. Every discovered hostname is resolved and classified: reachable from the internet, behind a firewall, resolving only to an internal address, no site configured, or no longer resolving at all. Only the reachable ones represent exposure, and separating them matters. An estate of two hundred names where six are reachable is a very different picture from one where a hundred and eighty are.

Whether certificates are sound. For each reachable name, whether the certificate is valid, expired, self-signed, or cannot be verified against a trusted authority. One expired certificate on a forgotten subdomain is a maintenance signal. A low proportion of valid certificates across a whole estate is a systemic one, and it is the proportion that is scored.

Exposed development and test systems. Staging and development environments reachable from the internet are a recognised weak point. They typically run older code, carry weaker authentication, and sometimes hold a copy of production data.

Remote access surface. VPN concentrators, remote desktop gateways and similar entry points, reported where the name or the certificate identifies them. These are not a fault, since remote access is normal and necessary, but knowing how many a supplier exposes and whether their certificates are in order is part of understanding the relationship.

Equipment management interfaces. Firewall, switch, storage and appliance administration pages that are reachable from the internet. These are usually accidental. An appliance that ships with a self-signed certificate and a web interface, plugged in and forwarded without much thought, is one of the more common findings.

Estate growth. New names appearing over a rolling ninety-day window, so a sudden expansion in a supplier's footprint is visible rather than silent.

Internal hostname disclosure. Names that resolve only to internal addresses but appear in the public certificate log anyway. These are not reachable and are not scored as a weakness. They are reported for information because they tell you something about how an organisation names and manages its infrastructure.

Estate size is not a risk signal

One design decision is worth explaining, because the obvious approach would have been wrong.

It is tempting to treat a large estate as a larger attack surface and score it accordingly, perhaps banded against employee count. We do not, and we will not.

A managed service provider hosting systems on behalf of its customers will have many times the hostnames of a professional services firm with the same headcount. So will a hosting company, a software vendor running per-customer environments, or an agency maintaining client sites. None of them is less secure for it. Scoring estate size against company size would penalise a whole category of legitimate business for its operating model, and would do so invisibly, inside a number that looks objective.

Estate breadth is therefore reported as context and carries no weight in the grade. What is scored is the proportion of certificates that are sound, which is a fair comparison whether a company has six hostnames or six hundred.

What we tell you when we cannot see everything

There are two limits worth stating.

The sample is capped. For a company with a very large estate, Senserity examines a subset of the names in the log rather than all of them, and both the Cyber tab and the report say so, with the coverage percentage, where that applies. The names left out are not selected on any risk or recency basis, so a capped result is a sample and is presented as one.

A domain that answers to any name makes absence meaningless. Some domains are configured with a wildcard DNS record, which means every possible name resolves whether or not anything is behind it. On those domains, a name that does not respond cannot be assumed to be unused, and we say so rather than counting it as clear.

Both of these could have been left unsaid. A silent false all-clear is the worst thing a risk product can produce, so we would rather show you the shape of what we do not know.

Where to find it

Certificate Transparency results appear in a Public hostnames panel on the Cyber tab of any company profile, with the count breakdowns and a listing of individual addresses. The Cyber report carries a matching Public Hostnames section.

A large estate would run to a dozen pages if printed in full, so the report listing is capped at roughly a page. The rows are ordered so that any address with a finding appears before any clean one, and the footer states how many addresses were held back and, separately, whether any of those had findings. A capped list that quietly dropped failures would read as a clean bill of health, which is the opposite of what the report is for.

The seven tests are available from the Self-Assessment tier upward, alongside the rest of the Cyber category.

If you already have companies on your watchlist, the tests will run on the next scheduled assessment. For the full detail on how the category works, see How Senserity checks cyber risk.

One test retired

CYB-031, Subdomain Discovery, has been retired with this release. It worked from a wordlist of common subdomain names, checking whether each one happened to exist. Certificate Transparency supersedes that entirely, because the log lists names that actually exist rather than names that might. Its findings now come through the new tests instead.