Skip to the content
The Indexsites.llc

Entry IX-04 · Internet shelf

Certificates & subdomains

One instrument on the /domains/ desk: every logged certificate for a domain, the subdomains they reveal, and the certificate being served now. We ran it on a small domain and a very large one.

Tested 27 Sep 2026, 20:00–20:06 UTC · 2 comparators · labs.llc/domains/certs/

The certificates instrument on the labs.llc domains desk at desktop width: a headline about every certificate ever issued for a name, a domain field with a Read the logs button, and example domains to try.
labs.llc/domains/certs/, captured from the local copy of build 537 on 27 September 2026.

01What it is

This is one of ten instruments on the labs.llc /domains/ desk. Give it a domain and it lists every TLS certificate the public Certificate Transparency logs hold for it, read through crt.sh, plus the subdomain names those certificates reveal, which of them a valid certificate still covers today, and the certificate the apex and www. are serving right now. Both lists export as CSV.

It is for site owners, IT and security staff, and anyone who wants to know what a domain's certificates give away and when the live one expires.

02How it works

The browser (domains/assets/js/dc-certs.js, 1,233 lines) calls the site's own relay, which queries crt.sh for the domain and for every subdomain and removes duplicates by serial. It reads crt.sh's answer object by object instead of decoding it whole, at about 0.6 KB a certificate, listing the newest 5,000 and counting up to 40,000. It asks crt.sh no more than 20 times a minute and caches for six hours. If crt.sh fails, it shows nothing rather than a guess and says why; an older copy is served only with its fetch date (tools_certs.php:8-18, 35-38, 70-79, 127).

Alongside the logs, the relay opens a live TLS handshake to the apex and www. and parses the certificate served (tools_certs.php:19-21, 402-404). The browser then recomputes days left against your clock and applies the RFC 6125 wildcard rule, under which *.example.com covers a.example.com but not a.b.example.com. It also flags certificates near expiry with no successor in the logs (dc-certs.js:47-56, 279-291).

03The test

Test log, 27 September 2026 (times UTC)
UTCWhat we didWhat came back
20:00:29wikipedia.org through the local relayHTTP 200 in 25.1 s. crt.sh answered 503; the relay said so and listed nothing. The live probe still worked: *.wikipedia.org, Let's Encrypt, 41 names, TLS 1.3, chain of 4, 36 days left.
20:00:59crt.sh asked directly, both query formsHTTP 200 in 0.5 s (26,174 bytes) and 4.9 s (14,520 bytes).
20:01:10example.com through the local relayHTTP 200 in 23.6 s: 43 certificates from 86 rows, 9 issuers, 6 subdomain names; apex and www. on TLS 1.3, 89 days left.

The wikipedia.org run shows the design working under failure. The source was down, the page said exactly that, and the live half still answered. It also shows the cost: both lookups ran close to the relay's 25-second wait.

04Against the field

Each comparator was read on its own site on the date shown. We credit what each does better before saying where Certificates & subdomains goes further.

crt.sh

Fetched 27 Sep 2026, 20:06 UTC; JSON output measured directly at 20:00 UTC.

The public Certificate Transparency search: look up certificates by domain, organisation, fingerprint or crt.sh ID, with JSON output.

Where it does better

  • It is the source, queried with no relay in between.
  • Searches by organisation and by fingerprint as well as by domain.
  • Answered in 0.5 to 4.9 s against 23.6 s through the relay.

Where Certificates & subdomains goes further

  • Turns rows into answers: current coverage under the wildcard rule, and lapses with no successor.
  • Adds the certificate actually served now.
  • CSV exports of both tables (dc-certs.js:314-330).

Qualys SSL Labs, SSL Server Test

Fetched 27 Sep 2026, 20:06 UTC.

A free deep analysis of a public HTTPS server's TLS configuration, ending in a letter grade from A+ to F.

Where it does better

  • Grades the whole configuration, protocols, cipher suites and chain, not one captured certificate.
  • Can keep a result off its public boards.

Where Certificates & subdomains goes further

  • Shows a domain's certificate history and exposed subdomains, which a single-server test does not attempt.
  • Says what the evidence cannot prove: a name in a certificate is not proof a host exists.

05Where it falls short

  1. Slow: 23.6 s and 25.1 s for the two lookups, almost all of it spent waiting on crt.sh.
  2. It rests on one free monitor. When crt.sh returned 503 for wikipedia.org there was no history to show, honestly reported but empty.
  3. The live check covers only the apex and www., and it does not grade the server's TLS set-up.
  4. Names covered only by a wildcard never appear individually, so the list is of names ever written into a certificate, not every host; the page says so itself.

06Filing note

File underWhat a domain's certificates reveal, and whether the live one is close to lapsing.

This instrument does the reading that crt.sh leaves to you, and adds the one thing the logs cannot: what the server presents today. It refuses to guess when its source fails, which we saw in practice. The cost is patience. Go to crt.sh for speed or organisation searches, and to SSL Labs for a configuration grade.

Open Certificates & subdomains on labs.llc

07Spec sheet

IX-04 · Certificates & subdomains · as tested
Addresslabs.llc/domains/certs/
Where it runsYour browser plus the labs.llc relay (tools.php?op=certs)
Sourcescrt.sh; a live TLS handshake to the apex and www.
LimitsLists 5,000, counts 40,000; 20 crt.sh queries a minute
Cache6 hours; older copies only with their date
ExportsCSV: subdomains and certificates
Lookup time23.6 s and 25.1 s
Measured27 Sep 2026, 20:00–20:01 UTC
Set againstcrt.sh; Qualys SSL Labs