A gaming desktop, a weekend, and a dead CA's root key
Matthew McPherrin pulled two root certificates out of an archived Netscape Communicator 4.51 installer on archive.org, pointed CADO-NFS at their public keys, and let a Ryzen 9 5950X chew on the math. Thirty-two hours later he had the private key for E-Certify's 512-bit SSL root. The S/MIME root took twenty-nine. No cluster, no cloud bill worth mentioning, no exotic hardware. A machine you could buy off a shelf, factoring the keys that a Canadian certificate authority trusted to sign the web in 1999.
The keys are harmless now. E-Certify's roots expired on October 16, 2003, Netscape yanked them in 2002, and Internet Explorer never shipped a single 512-bit SSL root to begin with. To actually issue a certificate with the factored key you would need Netscape 4.51 with its clock wound back past 2003, which describes exactly one machine on the planet: the VM McPherrin built to prove it. That is the fun part of the story. The part that should bother you is the number. Five hundred and twelve bits, one desktop, a day and a half.
What "factoring the key" actually means here
An RSA public key is a big number, the modulus, which is the product of two large primes. The private key falls straight out of those two primes. The entire security of RSA rests on one bet: that nobody can pull the modulus apart into its factors in any reasonable amount of time. Break that number into its two primes and you have reconstructed the private key from nothing but the certificate everyone can already download.
For a 512-bit modulus, that bet lost a long time ago. RSA-155, a 512-bit challenge number, got factored back in 1999, the same year E-Certify shipped these roots. So the weakness wasn't a surprise even then. What changed is the price. In 1999 factoring a 512-bit key was a supercomputer project. In 2026 it is a thing you run overnight next to your Steam library, using open-source software anyone can download. The details are in McPherrin's writeup, and it's worth reading in full, including the part where he feeds a captured handshake to an LLM and then, correctly, doesn't trust the output until he's tested it.
Factoring never stopped. It just moved up the key sizes.
512 bits has been indefensible for a quarter century. The interesting question is where the line sits today, because that line is the whole reason the industry keeps raising minimum key sizes.
The public record moves in steps, each one a serious academic effort:
- RSA-512: factored in 1999, and now a desktop weekend.
- RSA-768 (768-bit): factored on December 12, 2009, across hundreds of machines over roughly two years of sieving.
- RSA-250 (829-bit): factored in February 2020 using CADO-NFS, at a cost of about 2,700 core-years spread over tens of thousands of machines.
829 bits is the largest RSA modulus anyone has publicly factored. 1024-bit keys sit above that record, which is exactly why nobody sane will tell you they are safe. The gap between 829 and 1024 is not a comfortable margin, it's an unfunded one. A well-resourced adversary who wanted a specific 1024-bit key badly enough is inside the realm of "expensive but plausible," and the academic record is a floor, not a ceiling: it's what people published, not what a signals intelligence agency has quietly built. This is why the CA/Browser Forum killed 1024-bit issuance for public certificates at the end of 2013, and why the Baseline Requirements now demand at least RSA 2048 or an approved ECC curve (P-256, P-384, P-521) for anything a browser will trust.
A dead CA's key still teaches the live lesson
The reflex reaction to a story like this is "so what, the roots expired in 2003." Fair, for E-Certify specifically. But two things carry forward.
The first is recorded traffic. Plenty of what E-Certify protected in 1999 wasn't using ephemeral key exchange, so the session keys were derived under the certificate's RSA key. Anyone who captured that traffic and kept it can now decrypt it, decades later, because the long-term key finally fell. That is the entire shape of harvest-now-decrypt-later, and it is not a museum problem. It is the same argument driving the post-quantum migration happening right now, where the fear is that today's TLS 1.3 handshakes get recorded and cracked once a quantum computer arrives. We wrote about the certificate side of that in your key exchange went post-quantum, your certificates didn't. The mechanism is identical, only the timeline differs.
The second is that "the CA uses strong keys" tells you nothing about the keys you generate and run. Public issuance has a hard floor now. Your own infrastructure does not.
The weak keys are almost always yours
Every publicly trusted certificate in your stack is already at 2048-bit RSA or ECDSA, because a CA that issued anything weaker would be dead in the water. The soft underbelly is everything the CA/Browser Forum never touches.
Internal PKI is the usual offender. Someone stood up an OpenSSL-based CA in 2014, generated a 1024-bit root because that was the default in whatever tutorial they followed, and that root is still signing certificates for internal services today. mTLS client certificates are another, especially long-lived ones minted years ago and rotated never, which is its own separate mess we covered in rotating mTLS client certificates without taking down your services. Then there's the hardware: load balancers, VPN concentrators, IPMI and BMC interfaces, printers, IoT devices, all of which love to ship with a self-signed 1024-bit certificate and a private key generated on a device with almost no entropy at boot. None of that shows up in a scan of your public endpoints, and none of it is on anyone's renewal calendar. It's exactly the kind of thing that goes missing when you don't actually know how many certificates you have.
How to find the small keys before someone else does
You can audit this today with tools you already have. Start with what a server actually presents on the wire:
echo | openssl s_client -connect example.com:443 2>/dev/null \
| openssl x509 -noout -text \
| grep -E "Public-Key:|Signature Algorithm:"
You want to see Public-Key: (2048 bit) or larger, or an ECDSA key, and a signature algorithm that isn't sha1WithRSAEncryption or, worse, MD5. A 1024-bit RSA key or a SHA-1 signature is a finding, not a curiosity.
Check certificate files sitting on disk the same way:
openssl x509 -in server.crt -noout -text | grep "Public-Key:"
And inspect a private key directly, which is what matters for an internal CA root:
# RSA key
openssl rsa -in ca.key -noout -text | head -1
# any key type, including EC
openssl pkey -in ca.key -noout -text | head -2
To sweep a directory of certificates instead of checking them one at a time:
find /etc/ssl /etc/pki -name '*.crt' -o -name '*.pem' 2>/dev/null | while read -r f; do
bits=$(openssl x509 -in "$f" -noout -text 2>/dev/null \
| grep -oE 'Public-Key: \([0-9]+ bit\)')
[ -n "$bits" ] && echo "$bits $f"
done | sort
Sort the output and the weak keys float to the top. Anything under 2048-bit RSA goes on the list to re-key and reissue, and re-keying is the operative word: rotating the certificate while keeping the same undersized key changes nothing. If the weak key is an internal CA root, re-keying it means reissuing everything under it, which is precisely the kind of job that is miserable to do in a hurry and merely tedious to do on a schedule.
What counts as big enough now, and for how long
2048-bit RSA is the floor for public trust and a reasonable minimum everywhere else. ECDSA on P-256 gives you comparable security with far smaller keys and faster handshakes, and it's what most people should reach for on new systems. 1024-bit is finished. 512-bit is a toy, as the E-Certify roots just demonstrated on a desktop.
The catch is that "big enough" has an expiry date of its own. Every RSA and ECDSA key you deploy today is breakable in principle by a large enough quantum computer, and the harvest-now-decrypt-later crowd is already recording traffic against that day. 2048-bit RSA is safe against classical factoring for the foreseeable future, but it is not the last word, and the migration to post-quantum algorithms is the reason the whole ecosystem has been in motion for two years. A CA root cracked on a gaming PC is a good moment to check that none of your own keys are already living on borrowed time.
Frequently asked questions
Are the factored E-Certify certificates a threat to anything on the web today? No. The roots expired on October 16, 2003 and were removed from browsers in 2002, and no current client trusts them. The value of the demonstration is the cost, not the target: it shows a 512-bit RSA key now falls to a single desktop in about a day, which is the practical proof behind every minimum-key-size rule.
Is 1024-bit RSA actually breakable, or just theoretically weak? The largest RSA key publicly factored is 829 bits (RSA-250, in 2020), so nobody has openly broken a 1024-bit key. But 1024 sits just above that record with no comfortable margin, and an adversary with a nation-state budget is a real possibility rather than a hypothetical. Treat any 1024-bit key still in service as something to replace now, not eventually.
How do I know if my internal CA or devices are using weak keys?
Inspect them directly with OpenSSL rather than trusting an inventory. openssl x509 -in cert.pem -noout -text | grep Public-Key shows a certificate's key size, and openssl s_client -connect host:443 shows what a live server presents. Sweep certificate directories and device management interfaces, because that gear is where undersized keys hide, not on your public endpoints.
Should I switch from RSA to ECDSA while I'm re-keying? For new systems, usually yes. ECDSA on P-256 matches 2048-bit RSA on security while giving you smaller keys and faster handshakes, and it's widely supported. Keep RSA where you need compatibility with old clients, but there's no reason to generate fresh 2048-bit RSA keys by default on a modern stack.
Does this mean 2048-bit RSA is next to fall? Not to classical factoring. The jump from 829 bits to 2048 is astronomically large, so a desktop, or even a data center, isn't cracking 2048-bit RSA by number field sieve. The real threat to it is a future quantum computer running Shor's algorithm, which is why post-quantum migration is happening now while there's time, rather than after recorded traffic becomes readable.
