PKCS#12 キーストア インスペクター
`openssl pkcs12 -info` と同じことを、バイト列から直接、すべてブラウザー内で行います。ファイルの半分はパスワードなしで読めるので、その半分を先に表示します。PFX のバージョン、MAC のダイジェストと反復回数・ソルト長、そしてコンテンツブロックごとに平文か暗号化かとそのアルゴリズムを並べます。OpenSSL 3 が書いたファイルなら PBES2・AES-256-CBC・PBKDF2-HMAC-SHA256、Java 21 や新しい OpenSSL が読み込みを拒むファイルなら pbeWithSHA1And40BitRC2-CBC といった値が見えます。多くの場合、知りたいのはこの一行だけです。パスワードを入力すると、RFC 7292 付録 B の PKCS#12 鍵導出(PBKDF2 ではありません)で MAC を検証し、バッグを復号して、証明書ごとにサブジェクト・発行者・シリアル・有効期間・SAN・鍵アルゴリズム・SHA-256 フィンガープリントをリーフから順に表示し、friendlyName と localKeyID も添えます。そのうえで、キーストアを開く本当の目的に答えます。秘密鍵は入っているか、そしてそれはリーフ証明書の鍵か。秘密鍵から公開鍵を復元し、証明書の SubjectPublicKeyInfo とバイト単位で突き合わせるので、別名が同じだからという推測ではありません。ただし RC2・RC4・DES・3DES は WebCrypto にないため旧式ファイルは復号できず、その旨を明示します。MAC の検証は動くので、パスワードの正否だけは分かります。信頼ストアとの照合は行わないため、未知のルートで終わるチェーンと正常なチェーンは区別できません。
使い方
- .p12 または .pfx をボックスにドロップします。パスワードなしで MAC アルゴリズム、反復回数、各ブロックを守る暗号方式がすぐ表示されます。
- インポート失敗を調べているなら、まずブロックの表を見てください。pbeWithSHA1And40BitRC2-CBC や 3-KeyTripleDES があれば旧式キーストアで、それが Java 21・OpenSSL 3・Windows に拒まれている理由です。
- パスワードを入力して「開く」を押します。MAC の行で、パスワードが正しいか、書き出し以降にファイルが改変されていないかが一目で分かります。
- 「鍵と証明書」のチップを確認します。秘密鍵から復元した公開鍵をリーフ証明書のものと比較するので、このキーストアで実際に TLS を提供できるかが判定できます。
- 証明書はリーフが先頭で、その上に発行者が続きます。中間証明書が欠けていると、一度訪れたブラウザーでは動くのに他では失敗する、あの典型的な症状になります。
よくある質問
- なぜパスワードを入れる前からアルゴリズムや MAC が見えるのですか?
- そこは暗号化の対象ではないからです。PFX はバージョン番号、authenticated safe、MacData から成り、safe はコンテンツブロックの並びです。各ブロックは平文の SafeContents か PKCS#7 EncryptedData で、後者の AlgorithmIdentifier には暗号方式・ソルト・反復回数が平文で入っています。守られているのはバッグの中身だけです。だからパスワードを知らなくても、旧式の RC2 キーストアか、反復回数がどれだけ弱いか、ブロックがいくつあるかが分かりますし、逆にパスワード付きというだけで .p12 を不透明なファイルとみなすべきではありません。
- 旧式アルゴリズムだと表示されました。どうすればよいですか?
- OpenSSL で一度変換します。`openssl pkcs12 -legacy -in old.p12 -nodes -out tmp.pem -passin pass:…` で読み出し、`openssl pkcs12 -export -in tmp.pem -out new.p12` で書き戻すと、OpenSSL 3 の既定である PBES2・AES-256-CBC・PBKDF2-HMAC-SHA256 になります。tmp.pem には秘密鍵が平文で入るので必ず削除してください。-legacy が要るのは、OpenSSL 3 が RC2・RC4・単一 DES を legacy プロバイダーへ移し、Java も同じアルゴリズムを既定の処理から外したからです。2015 年頃の機器が書いたファイルは壊れているのではなく、誰も有効にしていない方式で暗号化されているだけです。
- MAC のパスワードと暗号化のパスワードは別物ですか?
- 原理上は別にできます。RFC 7292 は完全性の MAC と機密性の暗号化に別々のパスワードを認めており、一部の企業向けツールは実際にそうします。とはいえ一般的な書き出しツールはどれも同じ文字列を使うため、MAC の失敗はほぼ常に改ざんではなくパスワード違いです。鍵の導出方法も異なり、MAC 鍵は付録 B の PKCS#12 導出(ID 3)、最近のバッグ暗号化はパスワードのバイト列に対する PBKDF2 です。したがって本当に二つのパスワードで作られたファイルなら、MAC は通るのに復号だけ失敗することがあります。
- .p12 は開けるのに秘密鍵がありません。どこへ行ったのですか?
- そもそも書き出されていない可能性が高いです。`openssl pkcs12 -export -nokeys` や、ブラウザー・MMC コンソールの「証明書チェーンのエクスポート」ボタンの多くは、certBag だけの証明書専用キーストアを作ります。形式としては完全に正当なので、Web サーバーやロードバランサーは文句を言わずに取り込み、その後 TLS ハンドシェイクで鍵の不一致として失敗します。ここではバッグの一覧がそのまま出るので、鍵バッグがないことを配備前に確認できます。
- ローカル鍵 ID は何のためにありますか?
- localKeyID は証明書バッグと鍵バッグを対応づける属性です。キーストアにはどちらも複数入りうるためです。OpenSSL は証明書の公開鍵の SHA-1 ハッシュを使い、Windows や Java は独自の値を使いますが、仕様は特定の方式を求めていません。friendlyName は人間向けの別名で、keytool の一覧や Windows の証明書ストアに表示され、既存の別名と衝突するキーストアを取り込むと「alias already exists」エラーの原因になります。どちらもバッグごとに、どのブロック由来かとともに表示されます。
- 秘密鍵入りのキーストアを Web ページで開いて安全ですか?
- このページはファイルもパスワードもどこにも送りません。解析、MAC 検証、PBKDF2、AES-CBC 復号、鍵と証明書の比較はすべて WebCrypto でタブ内で動き、パスワードはコンポーネントの状態にあるだけでタブを閉じれば消えます。localStorage に残るのはファイル名だけです。とはいえ本番のキーストアなら、オフラインの `openssl pkcs12 -info` で確認する習慣がいちばん安全です。ここでは調査中のファイルを扱い、.p12 のアップロードを求める Web ツールは相応に疑ってください。
関連ツール
CSR デコーダー (PKCS#10)
証明書署名要求を送る前に確認します。サブジェクト、SAN、鍵長、署名アルゴリズム、そして自己署名が検証できるかまで。
JSON スキーマ検証ツール
JSON ドキュメントを JSON スキーマでブラウザ内検証します。エラーごとに JSON ポインター、該当行、失敗したキーワードを表示します。
CRL デコーダー (X.509)
証明書失効リストをブラウザーで読み取ります。発行者、CRL 番号、有効期間、失効したシリアルと理由、署名の検証まで。
ランダム IP・MAC ジェネレータ
テストとモック用にランダムな IPv4、IPv6、または MAC アドレスのバッチを生成 — public / private / ULA / link-local / UAA / LAA スコープに対応。
Bcrypt ハッシュ / 検証
コスト調整可能な bcrypt ハッシュ生成、または既存ハッシュとの照合 — ブラウザ内で実行。
PGP 公開鍵インスペクター
ASCII アーマー形式の OpenPGP 公開鍵を解析します。完全なフィンガープリント、鍵 ID、アルゴリズム、鍵長、作成日・有効期限、ユーザー ID と副鍵を表示します。