2,622 Valid Certificates Exposed: A Google-GitGuardian Study Maps Private Key Leaks to Real-World Risk
This post is a companion piece to our presentation at Real World Crypto (RWC) 2026 in Taipei, Taiwan on March 11, 2026, where GitGuardian and Google researchers will present the full findings of this collaboration.
2,622 Valid Certificates Exposed: A Google-GitGuardian Study Maps Private Key Leaks to Real-World Risk
This post is a companion piece to our presentation at Real World Crypto (RWC) 2026 in Taipei, Taiwan on March 11, 2026, where GitGuardian and Google researchers will present the full findings of this collaboration.
When a private key leaks on GitHub or DockerHub, detecting it is easy. What’s harder, sometimes impossible, is understanding its real-world impact. Unlike AWS keys or OpenAI tokens, which are tied to their respective service, a leaked private key is just a mathematical object without an obvious owner.
Private keys are challenging to attribute at scale: they are used in many different contexts, ranging from SSH authentication to JWT signatures. When one leaks, where do you start assessing the impact? Among leaked private keys, those used in X.509 infrastructure are most critical. They authenticate web servers in HTTPS: a compromised key enables attackers to impersonate websites or intercept data. That’s why GitGuardian partnered with Google’s researchers to answer a deceptively simple question: what happens when private keys leak?
In the TLS ecosystem, a private key leak poses a critical threat, as attackers on the appropriate network path can impersonate websites, intercept or manipulate data, and decrypt past communications, particularly if the same private key is used for a long period of time prior to the widespread adoption of PFS.
The Numbers Behind the Threat
Since 2021, GitGuardian has detected about one million unique private keys leaked across GitHub and DockerHub. Using Google’s internal Certificate Transparency database, we successfully mapped more than 40,000 of these keys to 140,000 real TLS certificates. As of September 2025, 2,600 of these certificates were valid, with more than 900 actively protecting Fortune 500 companies, healthcare providers, and government agencies.
Our disclosure campaign revealed worse news: we sent 4,300 disclosure emails to 600 organizations about their exposed certificates, but only 54 responded. That’s a 9% response rate. Even for high-confidence identifications, only 36% bothered to reply. National CERTs? Only 2 out of 20 responded within a week. Bug bounty programs? Three asked us to prove that having a website’s private key was actually a security problem.
Research pipeline
This reveals a widespread misunderstanding of private key risks. Months after disclosure, 84 certificates remain valid; 40% from Certificate Authorities (CA) we contacted but who failed to revoke.
This is the first Internet-scale analysis of private key leaks, made possible by combining two unique capabilities: GitGuardian’s real-time secret detection across millions of repositories and images, and Google’s infrastructure for querying Certificate Transparency logs containing billions of certificates.
Certificate Transparency (CT) is a public database of all certificates issued by major CAs since 2015, created after CA compromises like the 2011 DigiNotar breach. CT is a decentralized architecture with multiple operators hosting what are called logs, subsets of the CT database.
In theory, CT is perfect for mapping leaked keys to certificates using public key hashes. The mathematical properties of asymmetric cryptographic keys make it easy to link a certificate’s public key information with its corresponding private key. In practice, storage and persistence are massive challenges. In 2025 alone, over 5 billion unique certificates have been submitted, representing more than 10 terabytes of storage. Moreover, log operators can disconnect logs once all their certificates have expired, which makes sense in the context of TLS but breaks OSINT and historical attribution.
As of September 2025, 2,600 of the mapped certificates were valid (6% of mapped keys). We validated 921 (35%) through direct online checks; the remaining 1,701 (65%) required simulated TLS stack validation.
Querying TLS revocation mechanisms revealed a widespread misunderstanding of the impacts: of all the certificates we found compromised, only 24 were revoked via Certificate Revocation Lists (CRL) – with just 1 marked as actually compromised – and 56 via OCSP – with only 2 marked as compromised. More troubling: nearly 22% of offline-validated certificates were found to differ from those served online. This usually indicates that a new certificate has been issued after the key leak, without revoking the compromised one. Owners either don’t know about the leak or don’t understand revocation.
Finally, since revocation is rarely used, we simulated historical validity by checking if the private keys leaked during their associated certificate’s lifetime. This revealed that 24,000 certificates (17.16%) were valid at the time of the leak, and more than 4,000 are exposed per year.
Valid certificates at the time of first leak (in September 2025)
With certificates mapped, the next challenge emerged: finding and contacting their owners. Mapping private keys to certificates was indeed easy. Finding who owned them proved harder, but essential.
Our primary goal was to contact owners directly. As security researchers, we aim to fix root causes and alert owners to enable proper remediation. Without addressing the source of the leak, private keys remain in repositories and container images, ready for reuse.
Of 2,600 valid certificates, only 430 (16%) included organization information. For the rest, we deployed different attribution techniques: extracting domains from certificates, scraping security.txt and Whois records, analyzing MX records, and LLM-assisted web crawling. We identified entities for roughly half the certificates, leaving 1,300 certificates untraceable.
After three weeks of poor response rates, we contacted the major Certificate Authorities directly. Revocation processes vary by CA, but all require proof of ownership: a signature performed with the leaked private key. We submitted 2,200 valid certificates; most were revoked within 48 hours.
This joint research between GitGuardian and Google represents a systematic analysis that maps leaked private keys to real-world certificate usage at Internet scale. This collaboration demonstrates that protecting the Internet at scale requires both technical innovation and cross-organizational partnership.The results speak to both success and systemic challenges. Our disclosure campaign achieved 97% remediation, but at the cost of 4,300 emails sent, 1,706 entities contacted, 9 bug bounty submissions, countless follow-ups, and days of meticulous attribution work employing multiple OSINT techniques. The high success rate masks the extraordinary effort required to protect organizations that fail to protect themselves.
Despite our efforts, in January 2026, 84 certificates remained valid: 27 from small CAs that didn’t revoke, 6 from unresponsive government entities, and 51 from organizations that took no action. We re-contacted the relevant CAs and are still working with them to have the certificates revoked.
The research exposes hard truths: a widespread global misunderstanding of certificate security exists. Fortune 500 companies and governments leave leaked keys unrevoked. Private keys outlive multiple certificate renewals, remaining valid years after public exposure. This is a systemic failure, not isolated incidents.
The solution is clear. Cryptoperiods must be shortened, and private keys should never outlive certificates; ideally, they should be single-use. This isn’t new: Let’s Encrypt and Certbot already rotate keys with every renewal.
This practice should become industry standard, and CAs must forbid private key reuse. Compromised keys should be permanently blacklisted across all authorities. Combined with upcoming 47-day certificate lifetimes and mandatory rotation, this dramatically reduces vulnerability windows.
At RWC 2026, we present the full findings and roadmap. Private keys are leaking, and the industry can no longer afford to ignore them.
*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog – Take Control of Your Secrets Security authored by Guillaume Valadon. Read the original post at: https://blog.gitguardian.com/certificates-exposed-a-google-gitguardian-study/
About Author
