I factored a root CA
A researcher factored a 512-bit RSA root CA that Netscape shipped in 1999, in 32 hours on a desktop, and published the private keys.
Updated 11 October 2026: the closing SSL Labs line repeated the author’s joke as fact; the test site scores an F.
A 512-bit RSA root that Netscape 4.51 trusted for SSL took 32 hours to factor on a single Ryzen 9 5950X desktop. The root belonged to E-Certify, a long-defunct Canadian certificate authority. Its “RSA 512 Gold Server” root shipped for SSL in Netscape 4.51 in March 1999, and a matching “RSA 512 Gold Client” root shipped for S/MIME. Matthew McPherrin pulled the public key out of each certificate, fed the modulus to CADO-NFS, and recovered the two prime factors. The server root took 32 hours; the client root took another 29. Both private keys are now published, reconstructed in full from nothing but the public certificate.
The mechanism is simple. RSA security rests on the difficulty of factoring the modulus N back into its two primes p and q. Once you have p and q, you have everything the private key needs. At 512 bits that factorization is a weekend job on a desktop today, and it was already a demonstrated result in 1999: RSA-155, a 512-bit challenge number, was factored later that same year. A 512-bit CA root was too weak to ship the day it shipped. Netscape pulled the E-Certify roots in 2002, and the certificates carried a hard expiry of 2003-10-16.
Finding the key was the interesting part. Root certificates came bundled inside browser installers, and archive.org holds old Internet Explorer and Netscape installers. McPherrin extracted the roots with Claude Code, published a filterable list of the old trust anchors, and sorted for small keys trusted for SSL. E-Certify’s two 512-bit roots stood out. Internet Explorer, as it turns out, never shipped a 512-bit root for SSL, so the usable window was Netscape over a few years in the early 2000s.
With the private key in hand you can mint certificates that chain to a trusted root, but only for a client that still trusts it. That means Netscape 4.51 with its clock set back before October 2003, which describes a population of roughly one VM. Netscape 4.51 and any modern TLS stack share no common cipher suites or protocol versions, so verifying the forged certs worked at all meant building a period-correct TLS server in Go. It runs at e-certify.fly.dev and will not load in a current browser. The one scenario with any teeth is man-in-the-middling those ancient clients, which is a museum exhibit rather than a live threat.
As a bonus, Internet Explorer 3.02 shipped a 512-bit code signing root called “Test VeriSign Commercial Software Publisher CA.” Steve Weis factored it in about an hour on a GPU cluster. The ancientroots repo has several more test-looking 512-bit roots still waiting for someone with spare compute.
The practical lesson is in the timeline. A 512-bit key was breakable in principle when it shipped and trivially breakable within a few years, yet it sat in a shipping trust store because the early Web PKI had no minimum key size and no standard to enforce one. Key size floors protect you at issuance, before the key is ever cracked, because a root lives for years and a trust store entry lives until someone remembers to remove it. The same arithmetic is advancing up the scale. The Web PKI deprecated 1024-bit RSA over a decade ago, and a well-resourced organization factoring one is within reach; just days before this writeup, RSA-260, an 862-bit number, became the largest public factorization McPherrin is aware of. 2048-bit is today’s floor, and it will fall to deprecation too as quantum risk firms up.
The keys, certificates, and the old-timey TLS server are all in the repo at github.com/mcpherrinm/ancientroots. SSL Labs, McPherrin notes drily, gives the test site an F.
Keep Reading
data breachA February 2025 migration exposed DigiCert customer records online
A February 2025 server migration exposed a DigiCert internal system, and a self-registered account read archived customer data and identity documents.
OpenSSHLong Passwords Bypass Alpine SSH Authentication
OpenSSH 10.6p2 fixes a critical password authentication bypass affecting Alpine Linux and other potentially vulnerable musl systems.
opensshLong passwords unlock disabled accounts
The "*sshole" flaw lets oversized passwords log into *-disabled accounts on musl-based OpenSSH servers like Alpine under certain configurations. Fixed in 10.6p2.
Latest on the Wire
Full wire →- Bending Spoons Destroys Harvest With 10x Price Hike and LLM SupportHacker News
- CISA Flags SonicWall MFA Bypass Amid Exploitation ReportsThe Hacker News
- Claude Opus Ports 3D Models from Three.js to Vanilla WebGLSimon Willison
- Collapsing AI PR descriptions with HTML details tagsSimon Willison
New signal daily · RSS
Stay in the loop
New writing delivered when it's ready. No schedule, no spam.