In 1999, Netscape 4.51 shipped with two certificates from a Canadian certificate authority called E-Certify. One root was trusted for SSL servers; the other was intended for secure email. Each used a 512-bit RSA public key.

Twenty-seven years later, security researcher Matthew McPherrin recovered both private keys on an ordinary Ryzen 9 5950X desktop. The SSL root took 32 hours to factor. The S/MIME root took 29. With the recovered key, he issued a new website certificate that Netscape 4.51 accepted as belonging to a trusted chain.

Nothing about this depended on stealing a backup, finding a software bug, or attacking the original company. The public certificate already contained the mathematical value needed for the attack. The only missing operation was one that had become dramatically cheaper with time: splitting a 512-bit RSA modulus into its two prime factors.

This is a compact demonstration of a large security lesson. A root certificate is a promise that may survive its vendor, its browser, and the computer that first stored it. The cryptography has to remain sound for as long as any relying system still honors that promise.

The hunt began in old browser installers

The first challenge was not factoring. It was finding a real root key small enough to make the experiment practical.

Early web browsers carried their own collections of trusted certificate authorities. Archived installers therefore preserve snapshots of the trust decisions browser vendors made decades ago. McPherrin downloaded collections of old Netscape and Internet Explorer installers from the Internet Archive, extracted their bundled roots, and built a filterable Ancient Roots catalog.

That survey found an unusually weak target. Netscape 4.51, released in March 1999, trusted an E-Certify “RSA 512 Gold Server” root for SSL and a matching “Gold Client” root for S/MIME. Internet Explorer apparently did not ship a 512-bit SSL root, so the usable historical window was narrow and browser-specific.

The timing matters. RSA-155, the famous 512-bit RSA challenge number, was publicly factored later in 1999. E-Certify’s roots were therefore close to the edge even when Netscape distributed them. They were removed from Netscape in 2002 and expired on October 16, 2003.

This was cryptographic archaeology, not discovery of a live weakness. The interesting part was being able to recover an authentic CA signing key and replay the complete trust decision in the software that originally made it.

What an RSA certificate reveals

An RSA public key contains two integers:

public key = (n, e)
n = p × q

The exponent e is public. So is the modulus n, the product of two secret primes p and q. A conventional RSA private key also contains a private exponent d, derived so that the private and public operations undo each other under modular arithmetic.

Publishing n is safe only while recovering p and q is infeasible. Multiplying two large primes is easy. Reversing the multiplication for a carefully generated, sufficiently large modulus is expensive. RSA security lives in that gap.

Once an attacker factors n, the rest is routine arithmetic. For a two-prime RSA key, compute:

φ(n) = (p - 1)(q - 1)
d = e⁻¹ mod φ(n)

The recovered d, together with the primes and precomputed Chinese Remainder Theorem values, forms a complete private key. It can produce signatures that verify against the public key already embedded in the root certificate. The browser cannot distinguish those new signatures from ones made by the original CA.

McPherrin extracted the modulus from each certificate with Python’s cryptography package, then passed the decimal integer to CADO-NFS. CADO-NFS is a complete open-source implementation of the number field sieve, the leading classical method for factoring large general integers.

What the number field sieve actually does

“Try every possible divisor” is the wrong picture. A 512-bit number is far too large for trial division. The general number field sieve changes the problem into a search for a congruence of squares:

x² ≡ y² (mod n)

When x is not simply ±y, the value gcd(x - y, n) has a good chance of revealing a nontrivial factor of n.

Getting that congruence is the hard part. A practical NFS run is a pipeline:

1. Polynomial selection chooses related algebraic representations with properties that make later work cheaper.
2. Sieving searches huge ranges for values that factor completely over selected sets of small primes. Each successful result becomes a relation.
3. Filtering removes duplicates and combines partial relations into a cleaner sparse problem.
4. Linear algebra finds a dependency among exponent vectors, arranging products whose prime exponents are all even.
5. Square root converts that dependency into the congruent squares and uses a greatest common divisor to extract a factor.

The work is uneven. Sieving produces a large relation set and parallelizes well. Sparse linear algebra has different memory and coordination costs. CADO-NFS supplies separate programs for the phases plus a driver that connects them and can spread suitable work across cores or machines.

For the E-Certify roots, a single modern desktop and a little over a day per modulus were enough. That is the striking comparison: the first public 512-bit RSA factorization in 1999 required a broad distributed effort, while a real 1999 CA key now fits into a weekend experiment on consumer hardware. Better processors matter, but so do decades of algorithm engineering and implementation improvements.

The result does not imply that RSA-2048 is four times harder than RSA-512. Factoring difficulty does not scale linearly with bit length. Adding bits changes the work by vastly more than the simple ratio suggests. NIST SP 800-131A Rev. 2 reflects that difference: it disallows RSA moduli below 2048 bits for generating digital signatures, while permitting 1024- to 2047-bit keys only for legacy signature verification. That exception does not cover these 512-bit roots.

A factored root is more powerful than a broken website key

Recovering a normal website’s private key lets an attacker impersonate that one site, subject to protocol and client constraints. Recovering a root CA key changes the issuer.

A browser’s trust store contains anchors: public keys and identities accepted without needing a higher signer. During certificate-path validation, the browser connects a site’s leaf certificate through any intermediates to one of those anchors, checks signatures, names, validity periods, uses, and constraints, then decides whether the identity binding is acceptable. RFC 5280 formalizes this model and makes the trust anchor an input to validation.

Possession of a root’s private key means an attacker can create new descendants of that anchor. They can choose a hostname, generate a fresh leaf key, build a certificate, and sign it as the trusted CA. If a client still trusts the root and accepts the certificate’s algorithms and fields, the forged chain is mathematically valid.

That final condition is why the experiment needed more than a factored key.

The protocol time capsule was harder than the signature

A modern browser will not load the demonstration site. It does not trust the retired E-Certify root, and modern TLS stacks have dropped the algorithms and protocol versions needed to communicate with Netscape 4.51.

McPherrin instead created a virtual machine running the old browser and set its clock to a date before the E-Certify roots expired. He then built a custom TLS server in Go because there was no shared cipher suite between Netscape 4.51 and an ordinary modern server stack.

That separation is important:

• Certificate trust asks whether the presented identity chains to a trusted key under the client’s policy.
• TLS negotiation asks whether client and server can agree on a protocol version, cipher suite, and handshake behavior.
• Time validation asks whether the certificates are valid at the evaluation time.

The recovered CA key solved only the first problem. Replaying the full 1999 environment required satisfying all three.

Once those pieces aligned, the old browser accepted a newly issued certificate for the test host. That is stronger than merely printing the factors: it demonstrates the consequence at the relying-party boundary. The original Netscape code, original root store, recovered signer, forged leaf, and compatible server completed the historical system end to end.

Why no current browser is suddenly vulnerable

The experiment is deliberately bounded. E-Certify is defunct. The roots expired in 2003. Netscape removed them in 2002. Contemporary root programs do not trust them, and modern clients reject the obsolete protocol machinery around the demo.

Factoring these keys therefore does not grant a path into today’s public web PKI. A forged E-Certify certificate presented to Chrome, Firefox, Safari, or Edge has no trusted anchor. The signature can be perfectly correct and still be irrelevant to the client’s policy.

This distinction prevents two common mistakes. First, cryptographic validity is not the same as trust: a valid signature matters only when a verifier recognizes the signing key in the right role. Second, removal from mainstream software is not the same as erasure: old virtual machines, appliances, firmware images, archives, and specialized systems can preserve yesterday’s trust decisions long after vendors stop thinking about them.

The demo is safe as a statement about current browsers, but it is a useful prompt for anyone maintaining long-lived or isolated systems. Inventorying algorithms is not enough. Teams need to know which trust anchors still exist, where they are embedded, which validation clocks are used, and whether retired keys can still authorize meaningful actions.

Cryptography has a longer lifetime than deployment

The E-Certify story compresses several decades of security change into one reproducible experiment.

Key size is a time-dependent engineering choice. “Too expensive to break” always contains assumptions about algorithms, implementations, hardware, budget, and the years an asset must remain protected. A key that survives a product’s active life may still fail during the lifetime of signed archives or forgotten clients.

Trust stores are executable policy. A root certificate is not harmless metadata. It grants authority to every private key capable of producing signatures under that root. Shipping a weak anchor silently expands what future attackers may impersonate.

Retirement must remove authority, not just traffic. Stopping issuance does not neutralize a root. Clients must receive removals or distrust rules, and systems that cannot be updated need compensating controls or decommissioning.

Compatibility can be a defense and a liability. Modern protocol stacks protected the public demonstration by refusing obsolete TLS. The same incompatibility makes legacy islands harder to observe and update, which can leave weak trust material hidden.

Historical verification is valuable. Reconstructing the browser, clock, certificate chain, and server turned an abstract factorization into evidence. Security work is strongest when it reaches the actual decision point rather than stopping at a mathematical intermediate result.

What to audit in a living system

The practical response is not panic about 512-bit keys; those should already be gone. It is to treat cryptographic dependencies as an inventory with owners and expiration plans.

For each product or environment, record:

• embedded root and intermediate certificates, including firmware and offline images;
• public-key algorithm, modulus or curve size, signature hash, and validity period;
• every purpose the anchor authorizes, such as TLS, S/MIME, code signing, or device enrollment;
• the mechanism for distributing removals and distrust updates;
• systems that evaluate signatures at historical times or keep clocks disconnected from reality;
• protocol constraints that may trap a service on obsolete libraries;
• signed data that must remain verifiable for years after the signing system is retired.

Then test the failure path. Remove or distrust an anchor in a staging image. Rotate an intermediate. Advance the clock. Disable the oldest cipher. Confirm that the system fails closed and can still recover operationally.

Modern minimums are a baseline, not a lifetime guarantee. NIST guidance moved digital-signature generation to at least 112 bits of classical security, represented by RSA-2048 in its transition tables. Organizations also need migration plans for the eventual move away from factorization-based and discrete-logarithm cryptography as post-quantum standards enter deployments.

The central lesson is simpler than the mathematics: trust accumulates, and old trust does not become safe merely because it becomes obscure. A public modulus in a forgotten certificate can wait decades for hardware and algorithms to catch up. When they do, the certificate still says exactly what it said in 1999. Only the cost of challenging it has changed.

Sources and further reading

• I’ve factored the RSA keys of a Certificate Authority…, Matthew McPherrin’s original experiment and timings.
• Ancient Roots source repository, containing the extracted roots, recovered keys, and E-Certify test server.
• CADO-NFS, the number field sieve implementation used for the factorization.
• RFC 8017: PKCS #1 v2.2, the RSA key and operation specification.
• RFC 5280, the Internet X.509 certificate and path-validation profile.
• NIST SP 800-131A Rev. 2, transition guidance for cryptographic algorithms and key lengths.
• History of Cryptographic Key Sizes, a survey of factoring records and key-size recommendations.