ctscout research · note 2

Who Runs Your Website?

When a software vendor holds the certificate for a company's own domain, the vendor is operating that part of the company's site. This note measures that signal in public certificate logs, checks it against live DNS, and says how often it is right.

ctscout.dev · warehouse through 2026-08 · GLEIF 2026-09-06 · ISIN mapping 2026-09-06

How a vendor is confirmed

Candidates. Every certificate organization with at least 200 registrable domains that do not contain its brand token. There are 153. Fan-out is a filter, not evidence.

Evidence, per sampled domain. For each candidate, a fixed-seed sample of 60 such domains. For each domain we take up to 2 of the exact hostnames the candidate certified there (not the apex, which the owner usually runs somewhere else) and follow their CNAME chains through public resolvers. Three facts are recorded:

• Operated: the certified host's chain lands on a domain the candidate itself certifies. A community portal that resolves to a Salesforce-certified domain is operated by Salesforce.
• Owner's site on the same infrastructure: the customer's www or apex also lands on a candidate domain. Then it is the same owner, not a customer: a university's project sites resolving to the university.
• Another organization certifies the apex: a second, unrelated organization holds certificates on the same domain, which is what an owner looks like.

A domain is confirmed vendor-operated when it is operated and either another organization certifies the apex or the owner's site is not on the candidate's infrastructure. A sampled domain with no certified hostname other than the apex or www is untestable and counts neither way; so is any domain where a lookup failed (timeout or server failure), because an unknown answer is not a negative one. A candidate is a vendor when it has at least 20 testable domains in the sample and at least 25% of them confirm. The confirmed share is the precision figure for that vendor; the unconfirmed rows are shown, not hidden. "Own infrastructure" excludes any domain that other organizations also certify, so a shared cloud or content network never counts as a vendor's own. DNS was resolved for 22,850 names with 297 resolver errors; a run with more than a few percent of errors refuses to write results.

Confirmed vendors

vendor_footprint.py · 2026-09-06 18:06 UTC · precision = confirmed / testable

Cases that confirm

Cases that do not

Sampled domains for the same vendors where the test fails: the certified host resolves elsewhere, or the owner's site sits on the same infrastructure. These are counted against precision.

Large certifiers that are not vendors

Organizations with the same fan-out that the test rejects, those with the most sampled domains whose own www resolves to the candidate's infrastructure first. They certify hundreds of sites that do not carry their name, and those sites are theirs.

Customers over time

For each confirmed vendor and month: customers whose certificate coverage overlaps the month, customers first seen in the month, and customers whose latest certificate expired in the month with no replacement observed. Coverage is measured by certificate validity, not by last observation, so an annual certificate is not "lapsed" because none was issued lately. A fourth column, seen late, counts customers whose entire certificate coverage, from first observation to expiry, spanned seven days or less, once, in the month they were first seen; they are left out of the other three columns. A burst of domains whose certificates were only observed days before they expired would otherwise show up as thousands of customers gained and lost in the same month; the section after the table says what the largest such burst in this series was. The column is named seen_late_customers in the series JSON: short coverage here can mean the certificate was logged late or that it was genuinely short-lived, and this table alone cannot tell the two apart (the section below investigates the one large burst in this series and finds it was late logging, not short certificates; the other, smaller cells are not individually investigated). See issue #37. The figure is computed for every vendor and month, so a zero there means none were observed. The series is written append-only with the date it was computed, so an earlier view is never rewritten by a later one. The grid starts at 2026-02, the first month in the warehouse; point-in-time views accrue from 2026-09-06; last complete month 2026-08.

vendor_series.py · as_of 2026-09-06 · 2026-09-06 18:06 UTC

What the seen-late burst was

The seen-late column is almost entirely one event: Microsoft customers in April 2026. Their certificates were not short-lived; they were ordinary-length certificates issued around July 2025 that this collector first saw in April 2026, days before they expired. The column measures late observation, not short issuance: observed late, not issued short.

Of the 16,893 customers the column counts for April 2026, 15,310 were first seen between 11 April and 13 April. Nearly all of their certificates had been issued long before, with ordinary validity. Within those days the median certificate was first seen in 7 distinct logs. Other organizations' certificates seen on the same days show no such backlog: 3,035 of 269,664 were that old. So the collector did not replay its own feed; something submitted a batch of existing Microsoft certificates to many logs shortly before they expired. Nothing in the data fits a product rollout, a certificate-lifetime change or a rekey: as of 2026-09-06, none of the 15,310 customers has a Microsoft certificate here that stayed valid past that week. The hostnames are ordinary customer web names. Every one of the 29,704 certificates covers a single hostname (a certificate's SAN list, the list of hostnames it covers).

cdn.* (the asterisk stands for the customer's domain): a Microsoft certificate for one fixed word (cdn, mail, autodiscover) on a customer's domain; 13,795 of the 29,704 hostnames in this burst have that shape. The certificates behind hostnames of this shape were issued around July 2025 and first observed here with 2 days of validity left at the median.

www.* (the asterisk stands for the customer's domain): a Microsoft certificate for www on a customer's domain; 4,493 of the 29,704 hostnames in this burst have that shape. The certificates behind hostnames of this shape were issued around July 2025 and first observed here with 2 days of validity left at the median.

short_lived_burst.py · as_of 2026-09-06 · 2026-09-06 18:06 UTC

Customers as legal entities

Customer domains resolve to legal entities through the same pipeline as note one. Of 44,436 certificate organizations tied to an LEI, 7,515 (16.9%) have at least one ISIN recorded in GLEIF's ISIN-to-LEI mapping. That is a lower bound on organizations with ISIN-bearing securities: an ISIN identifies an instrument, not an exchange listing, and an LEI absent from the mapping may still have unmapped ISINs.

lei_isin_join.py · 2026-09-06 17:58 UTC

What this can and cannot say

• It sees production deployments on the customer's own domain, not every use of a vendor. A company using Salesforce only internally is invisible.
• Coverage is enterprise-shaped. Only organizations that buy organization-validated certificates appear, on both the vendor and the customer side.
• DNS is checked on a sample, not on every domain. The precision figure is the sample's; the full customer table carries a confirmed flag only for sampled rows.
• Six months of history. The warehouse starts 2026-02 and point-in-time views accrue from 2026-09-06; neither is long enough to backtest anything yet.