Millions Of Public Certificates Are Reusing Old Private Keys
summary
Analysis of 7 billion certs in Certificate Transparency finds millions reusing private keys, including organizations that reissue the same key after revocation — one case shows Verizon using the same key for 10 years. Automation and defaults matter: acme.sh defaults to key reuse, and SSH analysis finds ~100k GitHub accounts sharing keys and some keys reused between TLS and GitHub. Open-source tooling is published to detect key reuse across CT logs and GitHub.
AI-written summary · about
chapters (23)
- 0:00Private key leak scenario
- 3:17TLS certificates and private keys
- 4:39Blind CA signing
- 5:22Password reuse analogy
- 6:04Why leaking private keys is dangerous
- 7:0610% of certs reuse keys globally
- 9:13Certificate Transparency logs
- 10:36Key revocation codes and gaps
- 11:58Revocation flaws and short-lived certs
- 14:24ACME default key reuse
- 15:48Why developers reuse keys
- 16:53NIST vs real-world practices
- 17:35Verizon key reuse examples
- 21:09Compromised key still in use
- 25:01Key reuse detection tool
- 27:50Key reuse beyond TLS
- 28:34130K GitHub users reuse SSH key
- 31:02SSH and TLS key reuse
- 32:48Other private key uses
- 37:01Encrypted keys and password guessing
- 38:43Root causes of key reuse
- 41:11Best practices to prevent reuse
- 44:19Q&A
related talks
27mSSH Keys: Security Asset or Liability?
28mManaging SSH Access without Managing SSH Keys
26mThe Dangers of Key Reuse: Practical Attacks on IPsec IKE
41mA better way to SSH: Introducing SSH certificates
24mFinding insecure cryptographic keys in DKIM, DNSSEC, OpenID Connect & elsewhere
32mKeys or Certs for SSH Access? Why should I care?
29mKeys, Certs and Vault: From DevSecOps to Post-Quantum
11mIf You’re Not Using SSH Certificates You’re Doing SSH Wrong