Technical correction — 1 November 2026: The original publication date is retained. This review corrects CT coverage, browser-policy, protocol-status and example-code claims; commands were not executed. The opening illustration is schematic: “Immutable” means auditable append-only behavior, not guaranteed prevention, and “SCT Proofs” does not mean an inclusion proof. Read the Hebrew version.
Introduction to Certificate Transparency
A TLS certificate participates in server authentication; it is not a guarantee that a website is safe. Certificate Transparency (CT) adds publicly auditable records of certificates and precertificates submitted to logs. Monitoring can help investigate unexpected issuance, but its coverage depends on the logs and services observed. Private PKI is not universally subject to public CT. The protocol specifications are Experimental, while browser enforcement is defined by separate policies. How CT works.
Certificate Transparency at a Glance
The Problem CT Solves: A Brief History of CA Failures
Certificate Authorities issue certificates, and clients maintain trust anchors. A signature chaining to a trusted authority is not sufficient by itself: hostname, validity, usage and applicable policy checks also matter. Vendor incident reports illustrate why issuance controls and independent scrutiny are necessary.
- DigiNotar (2011): Google reported a fraudulent certificate used in attempted interception and subsequently rejected authorities operated by DigiNotar. Google’s report and updates.
- Comodo (2011): Mozilla reported nine fraudulent certificates after a registration-authority partner account was compromised; its account says an internal Comodo check detected the incident. Mozilla’s report.
- TURKTRUST (reported January 2013): Google described December 2012 blocking actions and attributed the mistaken issuance of two intermediate certificates to information supplied by the authority. Google’s chronology.
- Symantec (2017–2018): Chrome announced and implemented phased distrust of the legacy Symantec PKI. Chromium’s implementation record.
CT supports systematic monitoring, but does not ensure every misissuance is detected promptly or prevent it in advance. Investigation, remediation and revocation remain separate tasks.
Selected CT Milestones and Reference Points
How Certificate Transparency Works
Step 1: Certificate Submission
A CA or another submitter sends a certificate or precertificate to CT logs. Required SCT counts and operator diversity depend on the applicable client policy, not a universal “two independent logs” rule in the protocol. A log checks its acceptance conditions and returns a signed promise. Chrome CT policy.
Step 2: Signed Certificate Timestamps (SCTs)
An SCT is a signed commitment to include an entry within the log’s published Maximum Merge Delay. It is not, by itself, proof that the entry is already included. Its signed data binds the submitted entry and relevant protocol fields; describing it simply as a certificate-hash field is inaccurate. Delivery mechanisms and what a client accepts depend on protocol version and client policy.
Step 3: Merkle Tree Inclusion
CT logs organize entries in Merkle trees. The root hash summarizes a tree; a Signed Tree Head includes signed tree metadata, not just the hash. Inclusion proofs establish membership relative to a tree, while consistency proofs help audit append-only growth. Detecting inconsistent views also requires suitable observations and comparison. These checks make misconduct auditable, not impossible.
CT Log Merkle Tree Structure
Step 4: Monitoring and Auditing
Monitors watch selected logs or indexes for domains of interest. Auditors check inclusion and consistency evidence; detecting a split view requires comparing appropriate observations. A monitor’s log coverage, delay and service availability matter, so no single alert feed should be treated as complete or instantaneous.
The CT Log Ecosystem
Checking Current Log Operators and Status
Use Chrome’s CT log-list documentation to locate the current machine-readable lists and understand their different meanings. A listed name is not proof that a log is currently usable for new issuance: check its identifier, operator, state and applicable period. This replaces the outdated static operator/status table.
Browser Enforcement: The Chrome CT Policy
Chrome evaluates SCT delivery method, certificate lifetime, operator diversity and log state under its current CT policy. The old 180/365-day, two/three/four-SCT table is not a reliable current rule. Presence of an SCT extension alone is not compliance. Apple has its own CT policy; do not treat browser rules as identical to the protocol.
Tools for CT Monitoring
crt.sh
crt.sh is a public certificate-search service useful for investigating observed issuance. Its results should not be treated as proof of every certificate ever issued or zero ingestion delay. Use the results alongside your certificate inventory and the coverage information of the services you rely on.
CertSpotter
CertSpotter is SSLMate’s monitoring service for certificate-related observations and alerts. Check the current service description and plans rather than assuming a permanent free tier. Alerts support investigation but cannot guarantee detection before abuse.
certstream
Certificate-event streams can support monitoring, but coverage and payload formats depend on the provider. The following is illustrative pseudocode, not a verified npm package API. In particular, a certificate subject organization must not be reported as its issuer.
// Illustrative message handling, not a verified npm API.
// Configure a documented provider, payload schema and reconnect handling.
function processCertificateUpdate(message) {
if (message.message_type !== "certificate_update") return;
const cert = message.data?.leaf_cert;
if (!cert) return;
console.log("Observed domains:", cert.all_domains ?? []);
// subject describes the subject, not the certificate issuer.
}
// Wire this to a verified event source; coverage may be incomplete.
Querying CT Logs Directly (RFC 6962 HTTP API)
# Historical RFC 6962 endpoint example; argon2024 is not a current-log recommendation
# Check the current official log list before choosing a live endpoint
# Get Signed Tree Head
GET https://ct.googleapis.com/logs/us1/argon2024/ct/v1/get-sth
# Get an inclusion proof using the RFC 6962 MerkleTreeLeaf hash (not a certificate fingerprint)
GET https://ct.googleapis.com/logs/us1/argon2024/ct/v1/get-proof-by-hash
?hash={base64-leaf-hash}&tree_size={size}
# Read entries from the log (paginated)
GET https://ct.googleapis.com/logs/us1/argon2024/ct/v1/get-entries?start=0&end=9
CT in .NET: Checking SCT Extensions
This .NET example checks only whether an embedded SCT extension is present. It does not verify SCT signatures, qualifying log state, operator diversity, count, timestamps or browser-policy compliance. The callback still returns whether normal TLS policy errors are absent; it is not described as bypassing those errors. Do not replace TLS validation with this diagnostic.
using System;
using System.Net.Http;
using System.Security.Cryptography.X509Certificates;
using System.Net.Security;
// Check extension presence only; this is not CT compliance validation.
static bool HasEmbeddedSCTs(X509Certificate2 cert)
{
// OID for embedded SCT list: 1.3.6.1.4.1.11129.2.4.2
const string sctListOid = "1.3.6.1.4.1.11129.2.4.2";
foreach (var ext in cert.Extensions)
{
if (ext.Oid?.Value == sctListOid)
{
Console.WriteLine($"SCT extension found, {ext.RawData.Length} bytes");
return true;
}
}
return false;
}
// Use in HttpClient with server certificate validation
var handler = new HttpClientHandler
{
ServerCertificateCustomValidationCallback = (request, cert, chain, errors) =>
{
if (cert is not null)
{
var x509 = new X509Certificate2(cert.GetRawCertData());
Console.WriteLine($"Embedded SCT extension present: {HasEmbeddedSCTs(x509)}");
}
return errors == SslPolicyErrors.None;
}
};
using var httpClient = new HttpClient(handler);
var response = await httpClient.GetAsync("https://example.com");
Privacy Considerations
Public CT records expose names and other data in submitted certificates or precertificates. They are not a universal record of every TLS domain: private PKI is not automatically covered. Consider this exposure before requesting a public certificate for sensitive internal names. Wildcards may reduce explicit hostname disclosure but are not a complete privacy solution and have separate key-management tradeoffs.
CT v1, CT v2 and the Separate Static CT API
CT v1 (RFC 6962)
- SHA-256 leaf hashing only
- Signed tree heads and inclusion/consistency proofs
- Client policy determines accepted logs
- Basic JSON API
CT v2 (RFC 9162)
- Updated structures and cryptographic agility
- Revised log artifacts and proof structures
- Experimental specification; deployment is a separate question
- Static CT API is separate, not a feature defined by RFC 9162
- Split-view detection still requires appropriate comparison
Static CT API defines a separate monitoring read path alongside RFC 6962 submission endpoints. Do not equate that design with CT v2.
The Future of Certificate Transparency
- Merkle Tree Certificates: The October 2026 IETF draft describes an X.509 certificate design with integrated public logging. It remains work in progress, not a finalized replacement that all clients support.
- Post-Quantum CT: As quantum computing threatens ECDSA signatures used in SCTs, log operators will need to migrate to post-quantum signature algorithms.
- Client-side CT checking: Browsers already evaluate SCTs. Further auditing and comparison can complement policy checks; this is not a future switch from CA-only checking.
- DNS CAA and CT: RFC 8659 CAA lets domain owners authorize issuing CAs. It does not define a general mechanism selecting mandatory CT logs.
Certificate Transparency Ecosystem
Conclusion
CT improves transparency and auditability in the Web PKI, but does not guarantee complete or immediate discovery of every error. Monitor domains you are responsible for, reconcile alerts with your inventory, distinguish an SCT promise from inclusion evidence, and evaluate the actual client policy rather than an extension-presence test. Review current log and browser documentation when maintaining implementations.