Someone Factored a 90s CA. Old Keys Don't Die.

Someone just factored a certificate authority's RSA keys from the 90s. Here's why dead keys still bite, and how to audit yours today.

Dafallah Ibrahim

— 2 min read
Share

Factoring a certificate authority's key is the closest thing software has to minting money. Pull it off and you can sign certificates that look legitimate for any domain on the internet. Yesterday, someone did exactly that to a CA whose keys were generated back in the 1990s.

The certs expired decades ago. The math didn't care. And the real story isn't one dead CA — it's that key size is a countdown timer, and nothing in your infrastructure expires it for you.

Why this matters

Plenty of 90s-era keys are 512-bit RSA. Breaking a 512-bit modulus (RSA-155) took academics months of coordinated compute in 1999. Today, better sieving algorithms plus rented cloud CPUs turn that into a weekend project with a modest invoice. Anything at 1024 bits or below isn't "weak" — it's effectively public.

Meanwhile those keys still sit in frozen CA bundles: printers, routers, set-top boxes, enterprise appliances, embedded firmware. Notice the LG smart TV story sitting next to this one on HN? Devices like that never hear a root was pulled from a trust store. They trust it forever.

How it works

RSA rests on one assumption: nobody can factor the public modulus n = p × q. The certificate hands attackers n outright. Recover the two primes and you can derive the private key from public material alone.

A root key compromise is PKI's nightmare. Sign your own intermediate, mint leaf certificates for any domain, and clients that still trust the root see a perfectly valid chain. There is no revocation for a root — the only remedy is deleting it from trust stores, which reaches only devices that actually update.

Factoring cost via the Number Field Sieve grows subexponentially, so every extra bit buys less protection than the last. That's why key sizes ratchet upward — 512, 1024, 2048, 3072 — and why NIST retires 2048-bit around 2030.

Where this helps

  • Embedded and IoT: firmware shipping its own CA list or pinned certs, with no update path in the field.
  • Internal PKI: the mTLS mesh or Kafka cluster whose intermediate CA was generated years ago and never rotated.
  • Legacy enterprise: old S/MIME and code-signing certificates, plus backups encrypted under keys minted last decade.
  • Vendor appliances: anything that ships a private trust bundle you can't inspect or patch.

Watch out

Keep perspective: 2048-bit RSA is still acceptable for ordinary TLS today. Panic is reserved for 1024 and below. Don't burn a weekend re-keying everything.

Re-keying also breaks things quietly — pinned clients choke, older Java TLS stacks reject ECC, HSMs have key quotas. Prefer Ed25519 or ECDSA P-256 where you control both ends; RSA 3072 where you don't.

And factoring isn't the only way keys die. Weak randomness and key reuse do the same job faster. Audit how keys were generated, not just how long they are.

Try it yourself

Two commands, zero dependencies beyond openssl:

# Key size of a live endpoint (under 2048 = problem)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -text | grep -E "Subject:|Public-Key"

# Same check for any cert file you ship
openssl x509 -in cert.pem -noout -text | grep "Public-Key"

TL;DR

  • What changed: someone factored a 1990s CA's RSA keys — decades-old key sizes are now cheap to break.
  • Why it matters: dead keys never remove themselves; frozen trust bundles keep honoring them forever.
  • Try today: run the openssl check across your endpoints and internal PKI; treat 1024-bit and below as compromised.

Read more