Certificates · from the public CT logs

Every certificate ever issued for a name.
And every name they gave away.

Since 2018 a certificate a browser will trust has to be written into public Certificate Transparency logs first. So the logs hold, for any domain, the whole history of its certificates — and of every subdomain they named, including the staging and admin hosts nobody meant to publish. This page reads them, and the certificate the site serves right now.

DC‑C1 Certificate reader

crt.sh · port 443

Any domain or URL — the certificates for it and for every name under it.

Reads crt.sh for %.name · the live certificate on the name and its www
Instrument
Try

What a reading holds

Five panels for any name with certificates. If the logs cannot be read, the page says so and claims nothing — a failed reading is Unknown, never “no certificates”.

C1

The certificate it serves

What the name and its www hand over on port 443 now: issuer, names, dates, days left, protocol.

C2

The logs, summed up

Who issued them, how many a month, and which end within thirty days with no successor.

C3

Subdomains

Every name a certificate carried, first and latest seen, and the ones that say too much.

C4

Every certificate

Newest first, paged: issuer, validity, days left, the names on each, a link to its log entry.

C5

The limits

What a certificate log can and cannot tell you, stated beside the result.

What the logs tell you

A certificate is a public announcement.

Nobody has to publish a DNS zone, and most zones cannot be listed. But every publicly trusted certificate is published, in logs anyone can read, the moment it is issued. That makes the logs the best public map of a domain there is — and a record of names their owners may not know they gave away.

01Certificate Transparency

In 2011 a certificate authority called DigiNotar was broken into, and certificates for Google’s own names were issued to somebody who was not Google. Nobody noticed for weeks, because nobody could see what an authority had issued. Certificate Transparency (RFC 6962, 2013) fixed that by making issuance public: an authority submits each certificate to several append-only logs, run by independent operators, and gets back signed receipts that go into the certificate itself.

Chrome has refused publicly trusted certificates without those receipts since April 2018, and Apple’s platforms since the same year, so in practice every certificate a browser will accept is in the logs. The logs are huge, so services called monitors read and index them; crt.sh, run by Sectigo, is the best known and the one this page asks, for the name and for %.name — everything under it.

02What a certificate says

Three things matter here. The names it is good for — the subject alternative names, which may be exact (www.example.com) or a wildcard one label deep (*.example.com). The issuer, the authority that vouched for it. And its validity, a start and an end date. Publicly trusted certificates have been capped at 398 days since September 2020, and the CA/Browser Forum’s 2025 ballot SC-081 steps the cap down further — 200 days from March 2026, 100 from March 2027, 47 from March 2029 — so most names now renew every few months, automatically.

That is why a busy name has thousands of certificates: a new one every sixty to ninety days for every service, for years. A certificate near its end is ordinary when a newer one covers the same names, so the summary lists near-expiry certificates together with whether the logs already hold a successor.

03Names nobody meant to publish

Every name on a certificate is public from the moment of issue and stays public for good. staging., vpn., jenkins., admin., intranet. — a host set up for a week, given a certificate so the browser would stop complaining, is now a permanent line in a public log. Attackers read the logs as they are written: a new certificate for a new host is often probed within minutes.

The Subdomains panel marks names whose labels read as pre-release, internal, admin or infrastructure. That is a reading of the name and nothing more: the page does not resolve those names or connect to them, and a name on an old certificate may point nowhere today. What it shows is what anyone can already see.

04How they are counted

An authority usually logs a certificate twice: a pre-certificate first, to collect the receipts, then the certificate itself. Both carry the same serial number, so this page counts one certificate per serial. crt.sh’s answer is capped at 5,000 certificates, newest first, and the page says when a name reaches the cap. A subdomain’s dates are those of the first and the latest certificate that named it, by start date; “covered now” means a certificate valid today names it, exactly or through a wildcard.

crt.sh is often slow and sometimes down. When it does not answer, this page says so and claims nothing about certificates — which is different from a name having none.

05The live certificate

Separately, this site’s server opens port 443 on the name and on its www., sending each as the server name, and records the certificate it is handed: who issued it, the names on it, its dates, the protocol and cipher agreed. Certificate checking is switched off for that handshake on purpose — the point is to report what is served, expired or mismatched included, not to decide whether to trust it. A site behind a content network may hand different certificates to different places; this is what reached this server.

06What to do with it

  1. Publish a CAA record (RFC 8659) naming the authorities allowed to issue for your name. Any other authority is obliged to refuse — and the WHOIS report shows your CAA.
  2. Keep internal hosts off public certificates: an internal authority for internal names, or one wildcard instead of a certificate per host.
  3. Watch the logs for your names, and for look-alikes of them — a phishing site usually gets its certificate before it gets its victims.
  4. Treat a certificate you do not recognise as an incident: every row links to its full entry on crt.sh, with the authority that issued it.
  5. Renew well before the last thirty days, and check the live certificate after — the instrument above says how much of its life it has used.

What it will never claim

Four answers this page refuses to give.

01

A certificate is not a host.

The logs show that a name was issued a certificate. Whether a host by that name exists, answers, or ever went live, they do not say — and neither does this page.

02

A failed reading is not “none”.

When crt.sh does not answer, the result is Unknown, with the reason — never an empty list presented as a clean bill of health.

03

It does not vouch for a certificate.

The live check reports what was served, with verification switched off. Whether a browser would trust it — the chain, revocation — is a different question, and not answered here.

04

It does not probe the names it finds.

Only the name and its www are ever contacted. The subdomains in the logs are listed, not resolved, scanned or visited.