PowerPC MacからApple Siliconまで、クラシックなMac体験を届けるアプリを配布しています。なぜまだ使えるMacを捨てるのか。究極のエコは使い続けること。
Keychainが陳腐化してHTTPS接続に失敗するようになった古いMac向けの、ルート証明書レスキューツールです。署名付きの最新CA一覧をサーバーから取得して適用します。この機種はそもそもHTTPSが使えない場合もあるので、通信自体はHTTPでも構わない作りですが、その場合でも署名検証で改竄は検知します。
古いMac → RetroCertを起動 → サーバーから最新のCA一覧を取得 → Keychainへ反映 → HTTPS接続を再試行、という流れです。
SecureTransportの限界であり、証明書ツールでは解決できません。さらに、今実際にTiger世代のMacを使い続けている人の多くは、ブラウザ・メールをすでにAquafoxやThunderbirdに乗り換えていて、どちらもOSのKeychainとは別に自前の証明書ストアを持ち、最新のルート証明書を最初から内蔵しています。すでにAquafoxをお使いなら、おそらくこれは要りません。RetroCertの実際の対象は、あえて標準のSafari/Mail.appを使い続けている少数派です。
RetroCert.zip をダウンロードして解凍します（別の機種で解凍してフォルダごと転送してもOKです）。cd して実行します。python3.12 retrocert.py …… ドライラン。何が変わるか表示するだけで、実際には何も変更しません。python3.12 retrocert.py --apply …… 実際にログインKeychainへ証明書を反映します。python3.12 retrocert.py --apply --system …… システム全体へ反映します（sudoが必要）。| 動作確認 | PowerMac G4 / Mac OS X 10.4.11 (Tiger) / Python 3.12.11、当サイト自身の本番サーバーに対して確認済み |
|---|---|
| 要件 | PowerPC Mac / Mac OS X 10.4 (Tiger) 以降 / Python 3.12 |
個人の趣味プロジェクトにつき無保証です。MITライセンス。ソースコード・発行者側のツール・設計の解説は上記のGitHubリポジトリにあります。
このプロジェクトの本題は「証明書を直す」こと自体（そこはよくある作業です）ではなく、プレーンなHTTP経由で取得した更新（証明書を直すまでHTTPS自体が使えない機種もあるので、鶏卵問題としてHTTPにも対応しています）を、それでも信用できる形にすることでした。
署名鍵は開発者の手元のマシンにしか存在せず、どこにもアップロードしません。そのマシンで manifest.json とクライアント配布アーカイブに署名し、署名済みの結果だけをVPSに上げます。VPS自体は秘密鍵を一切持たない、ただの静的ファイル配信サーバーです。RetroCertは、取得した内容を信用する前に、同梱の公開鍵で署名を検証します。ポイントは、VPSが完全に乗っ取られたとしても、攻撃者は正しい署名を作れないということです。改竄されたマニフェストや証明書ファイルは、通信経路がHTTPかHTTPSかに関わらず、クライアント側で拒否されます。個々の証明書ファイルも、検証済みマニフェスト内のSHA-256と照合するので、マニフェスト1つの署名検証で証明書一式全体をカバーできます。
client/verify.py は、hashlib と pow()、そして自前の小さなASN.1 DERパーサーだけで、RSA-PKCS#1 v1.5 + SHA-256の署名検証を約90行で実装しています。cryptography や pyOpenSSL は使っていません。古い・制約のあるPython環境で動かすのが目的なので、そもそもそれらを入れるのが現実的でない、という事情によるものです。
SecureTransportのプロトコル・暗号スイートの不一致であり、証明書ツールでは直せない領域です。
/System/Library/Keychains/X509Anchors）に証明書が存在するかどうかだけで決まります。macOS側の実装（store_macos.py）は、新しいAPIが常にあるものとは仮定せず、この違いで分岐しています。
上の通り、実際の効果はかなり限定的でしたが、仕組み自体は証明書以外にも転用できると思っています。
verify.py を単体のユーティリティとして。 cryptography/pyOpenSSLが入れられない環境（古いPython、pipの使えないサンドボックス、依存を増やしたくないインストーラーの起動処理など）で使えます。store.pyのOS別ディスパッチ層はまさにこの汎用化のために用意しています。古いルーター・NAS・複合機・産業機器・古いLinux/Windowsサーバーなど、HTTPS通信はするが証明書ストアが更新されない機器は多く、「古いMacでWebを見る」ではなく「証明書が原因で通信できなくなったレガシー機器を延命するツールキット」と捉え直せば、もっと広い需要がありそうです。store_windows.pyのようなバックエンドを足すだけで拡張できます。certutilが無いため今回は見送りましたが、libnss3.dylibをctypes経由で直接呼ぶ独自バインディングを書けば、cert9.dbへの証明書追加も原理的には可能です。皮肉にも、本当に欲しい機能はここにあるのですが、NSSの内部API・ABIに正確に合わせる必要があり、相応の開発コストがかかります。ソースコード・発行者側のツール・ライセンスはGitHubにあります。
不具合報告・要望は、非公開で開発者に直接届きます。個人プロジェクトのため、返信できないことがあります。