ByteScope

Certificate Decoder

証明書を貼り付けて、その中身をすべて読み取る — そしてチェーンが壊れている理由を突き止める。

ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。

.pem / .crt / .cer / .der / .csr ファイルをドロップ

ローカルで解析 — アップロードされません

PKCS#12 (.p12 / .pfx) の解凍

パスワード保護されたコンテナから証明書チェーンと秘密鍵を抽出します。ファイルはすべてこのタブ内で開かれます — 秘密鍵がブラウザの外部へ送信されることはありません。ネットワークを切断しても動作します。

.p12 / .pfx ファイルをドロップ

ローカルで処理 — アップロードされません

PKCS#12 サポートマトリクス — 対応フォーマット
AES-128/192/256-CBC (PBES2)✓Modern OpenSSL 3, recent keytool / Windows
3DES (pbeWithSHA1And3-KeyTripleDES)✓OpenSSL ≤1.1 key default, older exports
RC2-40 / RC2-128 (legacy)✓OpenSSL ≤1.1 certificate default
RSA & EC private keys✓Extracted as PKCS#8 PEM
SHA-1 & SHA-256 integrity MAC✓Password verified before decrypting

レガシーな RC2 や 3DES はバンドルされた JavaScript 実装によって復号されるため（ブラウザの WebCrypto 非対応分を補完）、古い OpenSSL や Windows のエクスポートもすべてページ内で安全に開くことができます。

このツールについて

PEM・DER・CRT・CERの素材 — 単一の証明書、チェーン全体、またはCSR — を貼り付けるかドロップすると、すべてのフィールドが即座にデコードされます：サブジェクトと発行者のDNをコンポーネントごとに、残り日数カウントダウン付きの有効期間（期限切れはマゼンタ、残り30日未満はオレンジ。ここに来る主な目的が有効期限の確認だからです）、完全なSANリスト、鍵用途と拡張鍵用途、公開鍵の種類とサイズ、署名アルゴリズム、シリアル番号、そしてSHA-1 / SHA-256フィンガープリント。

複数の証明書をまとめて貼り付けると、ツールはそれらをチェーンに並べ替え、各リンクを検証し、典型的なサーバー設定ミスを1行で診断します：「中間証明書がありません」。証明書・鍵マッチャーは証明書と秘密鍵を受け取り、両者が対になっているかを教えてくれます — 障害対応の最中に湧く「そもそもこれは正しい鍵なのか？」という疑問への5秒での答えです。ホスト名チェックは入力したドメインをSANリストと照合し、弱い署名（SHA-1）や自己署名証明書には注意を促します。

すべての解析はWebCryptoを使ってブラウザ内で行われます — 証明書、CSR、そして何より秘密鍵がどこかへ送信されることは決してありません。適当なウェブサイトに秘密鍵を貼り付けるのは通常はセキュリティ上の間違いですが、ここではアーキテクチャがそれを安全にしており、ネットワークケーブルを抜いてそれを証明することもできます。

PKCS#12コンテナの展開にも対応しています：.p12または.pfxファイルをドロップしてエクスポート時のパスワードを入力すれば、証明書チェーンと秘密鍵がそのまま取り出されます — 証明書は同じフルデコーダーに流し込まれ、鍵はリーフ証明書と照合され、すべてPEMとしてダウンロードできます。ここではレガシーファイルが重要です：古いOpenSSL、Java keytool、Windowsのエクスポートが作るコンテナは、ブラウザのWebCryptoでは扱えないRC2-40や3DESの暗号を使っているため、同梱のJavaScript実装がそれらを復号します。それでも秘密鍵がタブから出ることはありません。

よくある質問

ここに秘密鍵を貼り付けても安全ですか？

はい — すべてはページに同梱されたWebCrypto / ASN.1ライブラリを使ってブラウザ内でローカルに解析されます。サーバー呼び出しは一切なく、それはDevToolsのNetworkタブで（または貼り付け前にオフラインにして）確認できます。とはいえ、貼り付けた秘密鍵は機密情報として扱ってください：作業が終わったらタブを閉じましょう。

「中間証明書がありません」とはどういう意味ですか？

ブラウザはルートCAを信頼しますが、サーバー証明書は通常、中間CAによって署名されています。サーバーは自身の証明書とともにその中間証明書を送信しなければなりません。送信しないと、一部のクライアントは信頼エラーで失敗し、他のクライアントは（中間証明書をキャッシュしているため）動作します — 「Chromeでは動くのにcurlでは失敗する」という典型的な症状です。チェーンをここに貼り付ければ、どのリンクが欠けているかを正確に示します。

証明書が秘密鍵と一致するかどうやって確認しますか？

両方をマッチャーに貼り付けてください。証明書には公開鍵が含まれています。ツールは秘密鍵から公開鍵を導出し、両者を比較します。不一致は、この鍵がこの証明書では動作しないことを意味します — nginxの「key values mismatch」エラーの最速の診断です。

CAに提出する前にCSRをデコードできますか？

はい — CSRを貼り付ければ、送信前にサブジェクト、要求されたSAN、鍵の詳細を確認できます。CSR内のドメインのタイプミスを見つける方が、証明書を再発行するよりずっと安上がりです。

どの形式に対応していますか？

PEM（BEGIN CERTIFICATE / CERTIFICATE REQUEST / PRIVATE KEY ブロック、貼り付けまたはドロップ）、DERバイナリファイル（.crt/.cer/.der）、複数証明書のPEMバンドル、そして専用の展開パネル経由のPKCS#12（.pfx/.p12）コンテナ（パスワード保護。証明書チェーンと秘密鍵をローカルで抽出）です。

.p12 / .pfx ファイルを開けますか？

はい。コンテナを展開パネルにドロップしてパスワードを入力すると、証明書チェーンと秘密鍵がブラウザ内で抽出され、フルデコーダーで表示されます。鍵はリーフ証明書と照合され、PEMとしてダウンロードできます。復号を始める前にパスワードをコンテナの整合性MACで検証するため、パスワード誤りはファイル破損とは明確に区別して報告されます。

他のブラウザツールでは開けない古い.p12がなぜここでは開けるのですか？

古いOpenSSL、Java keytool、Windowsのエクスポートは、証明書をRC2-40で、鍵を3DESで暗号化します — これらはブラウザ組み込みのWebCryptoが実装していない暗号なので、WebCryptoだけのツールはそうしたファイルを拒否します。このツールはそれらレガシー暗号のJavaScript実装を同梱しているため、RC2-40、3DES、そしてモダンなAES-256（PBES2）のすべてが開けます — それでも秘密鍵がページから出ることはありません。