RetroCert

A root-certificate rescue tool for old Macs whose Keychain has gone stale, causing HTTPS to fail. It fetches a fresh, signed list of root certificates from a server and applies them — and the signature is checked even if the transfer itself happens over plain HTTP, since some machines this old can't necessarily speak HTTPS to fetch the fix in the first place.

Old Mac → launch RetroCert → fetch the current CA list from the server → apply it to the Keychain → retry the HTTPS connection.

Requirements

• Mac OS X 10.4 (Tiger) or later, PowerPC.
• Python 3.12 on the machine you're fixing — if it's not there yet, our own Python 3.12 build for Tiger PowerPC provides it.

Using It

1. Download and unzip RetroCert.zip on the old Mac (or unzip elsewhere and copy the folder over).
2. Open Terminal, cd into the unzipped folder, and run:
   python3.12 retrocert.py — a dry run; shows what would change, changes nothing.
   python3.12 retrocert.py --apply — actually applies the new certificates to your login Keychain.
   python3.12 retrocert.py --apply --system — applies system-wide instead (needs sudo).
3. Retry the site that was failing. If the failure really was just a stale certificate (see the notice above), it should connect now.

Supported Environment

A personal hobby project provided with no warranty. MIT licensed. Full source, the publisher-side tooling, and the design notes are in the GitHub repository.

The interesting part of this project turned out not to be "fixing certificates" — that part is routine — but making sure an update fetched over plain HTTP (because some of these machines can't do HTTPS at all until the certificates are fixed, which is a chicken-and-egg problem) can still be trusted.

Signing on a machine that isn't the server

The signing key lives only on the developer's own machine and is never uploaded anywhere. That machine signs manifest.json and the client distribution archive; only the signed output goes to the VPS. The VPS itself holds no private key at all — it's just a static file server. RetroCert checks the signature with its bundled public key before trusting anything it downloaded. The point: even if the VPS were fully compromised, an attacker still couldn't produce a valid signature, so a tampered manifest or certificate file gets rejected by the client itself, regardless of the transport. Each individual certificate is additionally checked against the SHA-256 recorded in the (already verified) manifest, so one signature check covers the whole certificate set.

A dependency-free signature verifier

client/verify.py implements RSA-PKCS#1 v1.5 + SHA-256 signature verification in about 90 lines, using only hashlib, pow(), and a small hand-rolled ASN.1 DER parser — no cryptography or pyOpenSSL. That matters here because the whole point is running on old or constrained Python builds where installing those isn't realistic.

What real hardware showed

Ideas for reusing this elsewhere

Given the narrow real-world payoff above, the more interesting part may be the mechanism itself, reusable beyond certificates:

• A generic tamper-evident distribution framework. Nothing here is certificate-specific — the same "sign on a trusted machine, serve from an untrusted one" pattern works for game patches, fonts, config files, dictionary data, or any small hobby project's auto-update feature that doesn't want the overhead of Sparkle/TUF-style infrastructure.
• verify.py as a standalone utility anywhere cryptography/ pyOpenSSL aren't available — old Python builds, pip-less sandboxes, an installer's bootstrap step that shouldn't need extra dependencies.
• Beyond Mac, to any legacy device with a frozen certificate store. store.py's per-OS dispatch layer exists specifically for this: old routers, NAS boxes, multi-function printers, industrial equipment, and old Linux/Windows servers all make HTTPS calls whose certificate store never gets updated. Reframed as "keep an old TLS client alive" rather than "old Mac web browsing," it could serve a broader need — just add a store_windows.py or store_linux.py.
• (Not attempted here) Reaching into Aquafox/Thunderbird's own NSS store. This was skipped because certutil isn't available on the target machine, but a binding that calls libnss3.dylib directly via ctypes could in principle add certificates to cert9.db. That's ironically where the actually-useful feature lives, but it needs to match NSS's internal API/ABI exactly — a meaningfully larger effort.

Full source code, the publisher-side tooling, and license are on GitHub.