How OMSHIFT works, and what it doesn’t claim

What OMSHIFT observes

OMSHIFT observes public Certificate Transparency (CT) records — the append-only, publicly auditable logs that certificate authorities submit issuances to under RFC 6962. When you submit a domain, OMSHIFT queries a CT search provider for issuances naming that domain and persists what it finds as evidence.

What baseline means

The first successful observation batch for a domain is its baseline — OMSHIFT’s first persisted view of that domain’s CT evidence. A CT source can return several certificates in that first response. OMSHIFT does not invent a chronology between them, and does not generate issuance or delta events for baseline records: the baseline establishes state, it does not represent change.

How changes are derived

After baseline, each new domain/certificate relationship OMSHIFT observes creates an Issuance observed event. OMSHIFT then compares that certificate against the previous observed issuance for the domain, using one deterministic ordering rule:

Observations for a domain are ordered by certificate validity start (not_before), ascending; a certificate with no recorded not_before sorts after all others; ties are broken by OMSHIFT’s own observation id. The predecessor of a given observation is the entry immediately before it in that order.

If the normalized issuer of the new observation differs from its predecessor’s, OMSHIFT records an Issuer delta. If the normalized SAN set differs — anything added or removed — OMSHIFT records a SAN delta, storing both the added and removed name lists. Identical issuers and identical SAN sets produce no event.

Certificate issuance can legitimately overlap in validity. OMSHIFT does not treat a new observation as a “replacement” of the previous one — it reports only that the two differ, using the wording above.

What OMSHIFT does not prove

• CT observation alone does not prove a certificate is currently served by a website.
• OMSHIFT makes no request to the domain being observed — it queries CT evidence only.
• SAN presence on a certificate does not prove ownership of that name.
• OMSHIFT assigns no security score, grade, or health status.

Provenance

Every observation retains its source provider, a provider-assigned source record identifier where available, the timestamp OMSHIFT made the observation, and a hash of the normalized evidence. Every certificate row records first-observed and last-observed timestamps. Every derived event stores the observation pair it was computed from.

Certificate identity

OMSHIFT identifies a certificate by the SHA-256 hash of its TBSCertificate (RFC 6962 §3.2), as supplied by the CT source — not by serial number alone, which is not a reliable global identifier.

Indexing

A domain record becomes eligible for search indexing only once it has substantive evidence and either two independent successful observation batches or at least one genuine post-baseline event. Thin, baseline-only, or error records are marked noindex.