google

certificate-transparency

C++2014–2023

google / certificate-transparency · Archived

certificate-transparency

Auditing for TLS certificates.

Networking

Explore on GitHub Read Hacker News discussions

7Distinct people

8Mentions

0Explicit recommenders

887GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Auditing for TLS certificates.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year8 dated mentions

Observed mentions: 2014-09-19 14:54:44 UTC to 2023-06-15 19:51:48 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2014	2014-01-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	1	1
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	0	0
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	2	2
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	1
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	1
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	0	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	1	1

What Hacker News says

8 sources

amiga386·Jun 15, 2023

You are correct: https://github.com/google/certificate-transparency/blob/mast... You can embed CT attestations (SCTs) in the certificate itself, so yes, provided the CA is in cooperation with CT log operators, and deliberately does the pre-certificate -> SCTs -> real certificate dance, it is possible for a browser to validate embedded SCTs without an online check. However, that assumes that the CA actively does that, they don't have to. Neither does the server. What's compelling them to is _policy_, set by Google and Apple, that their respective browsers won't accept certificates _without_ CT attestations. Google's policy specifically requires that one of the SCTs on a certificate must be a CT log run by Google. Google also controls the list of CT logs that Chrome will consider as valid CT logs, as part of deciding if an SCT is valid. Ant

Read the rest

itrust, anyone? I was trying to make a similar point about Firefox - policy vs code. And rather than saying that it's specifically the CA/Browser Forum setting policy (which it does, but only baseline policy, which does not include CT), each org in the CA/Browser Forum has their own root cert inclusion program with their own policies, that all draw from baseline policy then add to it. You are right, _baseline_ policy does not require CT.... ... and neither does _Mozilla's_ policy, now I've scanned through it. It actively acknowledges that CT exists (in that it mandates that if you issue a precertificate for CT, you _must_ issue the completed certificate), but it does _not_ require CAs to use CT. In stark contrast to Google and Apple. Perhaps this is why they also don't implement CT checking in Firefox?

In Let's Encrypt Acme API Outage

ampdepolymerase·Aug 12, 2021

This could actually work for certificate attestation if baked directly into the browser. https://github.com/google/certificate-transparency

In A future for SQL on the web

est31·Nov 2, 2019

That paper is from April 2010 which is a different age in terms of internet encryption. Just for comparison, Google only started offering an encrypted version of its service in May 2010: https://googleblog.blogspot.com/2010/05/search-more-securely... They quickly realized the problems that you describe. In Nov 2011, the Certificate Transparency project by Google had its initial commit: https://github.com/google/certificate-transparency/commit/6a... In Chrome they have since enforced CT compliance for certificates: https://groups.google.com/a/chromium.org/forum/#!msg/ct-poli... CT requires that each certificate issued needs to be contained in both a Google log and a non-Google log: https://github.com/chromium/ct-policy/blob/master/ct_policy.... This means that fradulently issued certificates either won't work, or will be contained in publi

Read the rest

c logs run by Google (or Google needs to be forced by authorities as well).

In Encrypted web traffic now exceeds 90%

TheDong·Jan 9, 2018

Let's look at another project that needed a such a ledger: the certificate transparency project. One implementation of it, google's, uses leveldb: https://github.com/google/certificate-transparency Another one out there uses postgres. It turns out that you can use traditional databases in many cases where you think you need a blockchain, and you'll be able to waste vastly less energy on proof-of-work and vastly less time dealing with the terrible mess that is "blockchain". The reason not to use "blockchain" is that it has 200 definitions, all of them full of people trying to get rich, not getting things done. Databases have long-since solved the problem of storing and distributing data. Distributed stores like etcd, zookeeper, and so on have long since solved the problem of duplicating data. Very few people need byzentine fault tolerance

Read the rest

(due to having a large number of untrusted actors with write access), which is the only time the additional complexity blockchain includes is actually useful

In Building for the Blockchain

TheDong·Jan 17, 2017

Certificate transparency fits right on top of postgres, see crt.sh https://github.com/crtsh Or on top of LevelDB or sqlite if you look at google's implementation of it: https://github.com/google/certificate-transparency#software-... The source of truth for certificates is certificate authorities. Certificate authorities by definition must trust the claims other authorities make about what they issued. There's no need for "proof of work". There's not even any distrust. There's a need for an audit log, an append-only database, replication, and distribution of data. There is no need for solving the generals problem, for hashing, for confirmations, for any of the blockchain really.

In Ask HN: Why is the community so negative towards blockchain technology?

pfg·Oct 13, 2016

Google open sourced their server implementation[1]. The problem that a number of CAs and other log operators have run into is that Google has rather strict requirements[2] for uptime and such (which makes sense!) if SCTs from that log server are to be accepted by Chrome, so you'd probably need a dedicated team capable of operating a HA cluster. [1]: https://github.com/google/certificate-transparency [2]: https://www.chromium.org/Home/chromium-security/certificate-...

In Remediation Plan for WoSign and StartCom

0xmohit·Jul 28, 2016

Also worth looking at is Google's Certificate Transparency project [0], [1]. Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates. Certificate Transparency Lookup Tool [2]. [0] https://www.certificate-transparency.org/ [1] https://github.com/google/certificate-transparency [2] https://www.google.com/transparencyreport/https/ct/

In Show HN: Certificate Transparency Log Monitor

cpach·Sep 19, 2014

Well, the project itself isn't new. But this article is (relatively) new, and since it was quite well written I thought it was worth submitting. I'm not really knowledgable enough to assess the project's vitality but I found that the Github repo[1] is active, and the mailing list[2] is somewhat active as well. There is also a new RFC draft from 2014-07-10[3]. My conclusion is that since this project is backed by Google, it's currently the most viable attempt to improve on the suboptimal PKI infrastructure we have for TLS. Ideally Firefox, Safari, Internet Explorer and Opera would add support as well. Firefox as least has an open feature request[4]. But these things take time, you know :) [1] https://github.com/google/certificate-transparency/commits/m... [2] https://groups.google.com/forum/#!forum/certificate-transpar... [3] https://tools

Read the rest

.ietf.org/html/draft-ietf-trans-rfc6962-bis-04 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=944175

In Certificate Transparency: Public, verifiable, append-only logs