\n Issuance Rate: {{ data.Details.IssuanceRate.toLocaleString() }} certs/hr
\n Expiry Rate: {{ data.Details.ExpiryRate.toLocaleString() }} certs/hr
\n
The tables below count the number of currently-valid certificates\n signed by widely trusted CAs that use insecure or deprecated\n algorithms.
\n\n| Signature Algorithm | \n# | \n
|---|---|
| {{ alg.name }} | {{ alg.count.toLocaleString() }} | \n
| (None) | \n
| Public-Key Algorithm | \n# | \n
|---|---|
| {{ alg.name }} | {{ alg.count.toLocaleString() }} | \n
| (None) | \n
This section shows the number of pre-certificates in known CT logs\n from a few particularly large certificate authorities. Anyone can\n submit a pre-certificate they find in one log to another log, but this\n currently shows that some CAs have a clear preference for certain CT\n logs when they issue a certificate containing embedded SCTs, while\n others submit to several logs equally.
\n\nThe requested page was not found.
\nCertificate\n Transparency is an experimental framework for publicly auditing the\n TLS/SSL certificates issued by certificate authorities. It does this by\n requiring an increasing number of issued certificates to be added to\n publicly-accessible repositories, called certificate transparency\n logs, in order for them to be trusted by the user's browser. The goal\n is two-fold:
\n\nIn addition to CT logs, there need to be certificate transparency\n monitors. The primary function of a monitor is to ensure that CT logs\n behave correctly, e.g., by ensuring that they continue to store and serve\n all certificates that have been submitted to them. However, it is\n also common for monitors to use the data they collect from CT logs to offer\n other services such as computing ecosystem metrics, searching known\n certificates, and triggering alerts when new certificates are issued for\n certain domain names.
\n\nThis monitor fetches each log's current Signed Tree Head (STH) and set of\n trusted roots once per minute. New entries in a log are crawled as\n appropriate, and we will occasionally submit strictly-valid unexpired\n certificates or pre-certificates to a log. If a log is sharded by year, we\n will only submit certificates expiring in that year.
\n\nAll requests to a log count towards our estimate of its uptime\n and response time. An endpoint's (get-sth, get-entries, etc.) uptime is\n computed as the percentage of requests to that endpoint that succeed (that\n is, return a 200 status code with a valid response) out of a 90 day rolling\n window. An endpoint's response time is computed as the average amount of\n time from when a request is sent until the response is fully received and\n parsed, in a 90 day rolling window. A log's uptime and response time is\n computed as a fair average of each endpoint's uptime and response\n time. Requests are made with the HTTP client in Golang's standard library.\n We do not contact endpoints that are not listed on a log's informational\n page, such as get-proof-by-hash and get-sth-consistency.
\n\nSome parts of the monitor may enforce different timeouts or will retry in\n the event that a request fails while other parts will not, which means that\n downtime may be penalized unfairly relative to a more intuitive\n interpretation of 'downtime'. Also, the response time of the get-entries\n endpoint is strongly correlated with the number of entries it\n returns, but this information is currently ignored by our monitor.
\n\nFullness and New/Old Chains. On each log's informational\n page, we display an estimate of the number of unsubmitted certificates. This\n is computed by counting all the certificates in the CT ecosystem that we\n expect a log would accept, based on its trusted root CAs and whether the log\n is sharded by year, and subtracting the number of unique certificates the\n log contains. The log's 'fullness' is computed as the percentage of\n certificates it contains out of the set of certificates we expect it would\n accept.
\n\nSimilarly, we break uptime and response time estimates for the\n add-(pre-)chain endpoints into 'new' and 'old' categories, corresponding to\n whether or not the submitted chain is already in the log (old) or is not\n (new). It is common for logs to de-duplicate submitted chains, returning the\n same SCT when the same chain is submitted multiple times, so we do this to\n measure the cases where the de-duplication mechanism succeeds and where it\n fails separately. If the de-duplication mechanism succeeds, the\n add-(pre-)chain operation is read-only but the old SCT must be\n reconstructed. If the de-duplication mechanism succeeds, the add-(pre-)chain\n operation must block until the submitted data is persisted to disk.
\n\nCryptographic Validation. No information about\n cryptographic validation is propagated to the monitor's UI, but it is done.\n We validate that STHs are issued frequently enough, and that the hash in\n each STH corresponds to the hash of the leaves we've crawled. We also store\n all SCTs returned from a log's add-chain/add-pre-chain endpoints until we\n can verify that the log honored the SCT within its maximum merge delay.
\n\nFeel free to contact us at ct-logs@cloudflare.com.
\n\n| Log Name | \n# Certificates | \nUptime | \nResp. Time | \nLast Update | \n \n \n \n
|---|---|---|---|---|
| {{ log.Name }} | \n{{ log.Count.toLocaleString() }} | \n{{ sprintPercent(log.Uptime) }} | \n{{ sprintDuration(log.ResponseTime) }} | \n{{ sprintDate(log.LastUpdate) }} | \n
| {{ log.FamilyName }} | ||||
| — {{ member.Name }} | \n{{ member.Count.toLocaleString() }} | \n{{ sprintPercent(member.Uptime) }} | \n{{ sprintDuration(member.ResponseTime) }} | \n{{ sprintDate(member.LastUpdate) }} | \n
\n {{ log.Endpoint }}{{ log.Endpoint }}
\n Last Update: {{ sprintDate(log.LastUpdate) }}
\n Avg. Throughput: {{ throughput.toLocaleString() }} certs/hr
\n Contains: {{ log.Count.toLocaleString() }} certificates
\n Unsubmitted: {{ log.Unsubmitted.toLocaleString() }} certificates ({{ sprintSmallPercent(log.Count / (log.Count + log.Unsubmitted)) }} full)\n\n
0\">This log is operating at full capacity.
\n\nThis log is frozen. It\n accepts no new entries and signs no new STHs but continues to operate\n in read-only mode.
\n\n| Endpoint | \nUptime | \n|
|---|---|---|
| {{ ep.name }} | \nN/A | \n{{ sprintPercent(log.Profile.ByEndpoint[ep.tag].Uptime) }} | \n
| Endpoint | \nResp. Time | \n|
|---|---|---|
| {{ ep.name }} | \nN/A | \n{{ sprintDuration(log.Profile.ByEndpoint[ep.tag].ResponseTime) }} | \n
{{ msg }}
\n