証明書、CSR、または鍵
X.509 証明書、証明書署名要求 (CSR)、鍵、または PEM 形式の完全なチェーンを貼り付けるか、.crt、.cer、.der、.p7b、.pfx、.p12 ファイルを読み込んでください。サブジェクト、SAN、有効期間、拡張、フィンガープリントに加え、チェーンが正しい順序で署名されているか、秘密鍵が証明書に対応しているかを確認できます。データがブラウザーの外に送信されることはありません。
複数のブロック (証明書、中間証明書、鍵) をまとめて貼り付けるか、ここにファイルをドラッグできます

仕組み

X.509 証明書は、公開鍵を名前 (ドメイン、個人、組織) に結び付ける署名付きの文書です。サーバー間やファイルでやり取りされるのはそのバイナリ形式 (DER) で、コピー＆ペーストされるのは同じ構造を BEGIN CERTIFICATE 行と END CERTIFICATE 行の間に Base64 で記述したもの、つまり PEM 形式です。中にはサブジェクト、発行者、有効期間、公開鍵、そして用途や失効の確認先を示す拡張が含まれています。

このツールは、証明書、PKCS#10 証明書署名要求 (CSR)、PKCS#8・PKCS#1・SEC1 形式の秘密鍵、公開鍵、PKCS#7 パッケージ (.p7b)、PKCS#12 ファイル (.pfx、.p12) を認識します。複数のブロックをまとめて貼り付けると、エンドエンティティ証明書からルートまでチェーンを並べ替え、各署名を発行者の鍵で検証し、秘密鍵を各証明書・各 CSR と照合して、どれがどれに対応するかを示します。

また、形式の変換、証明書と鍵から IIS や Azure で求められる .pfx の作成、新しい CSR とその秘密鍵、またはテスト用の自己署名証明書の生成も行えます。すべての処理はブラウザーの暗号 API で行われるため、証明書も鍵もサーバーには送信されません。

例

ISRG Root X1 · SHA-25696:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6Let's Encrypt のルート証明書の SHA-256 フィンガープリントです。認証局やトラストストアが公開している値で、手元のファイルの値と一致すれば、まさにその証明書です。
ISRG Root X1 · pin SPKIC5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=公開鍵の SHA-256 を Base64 で表したものです。Android のネットワーク セキュリティ構成の pin-sha256 や、アプリの certificate pinning で使う値で、鍵を再利用すれば証明書を更新しても変わりません。
root.crt + intermediate.crt + server.crtserver.crt + intermediate.crt + root.crtnginx と HAProxy は、ファイル内の最初の証明書をサーバー証明書として扱います。チェーンが逆順だと、nginx は秘密鍵をルート証明書と比較してしまい、key values mismatch で失敗します。
openssl pkcs12 -in viejo.pfx -legacy -nodes | openssl pkcs12 -export -out nuevo.pfxPBES2 · AES-256-CBC · MAC SHA-256古い Windows や OpenSSL 1.x でエクスポートされた .pfx は RC2 と 3DES で暗号化されていますが、ブラウザーはこれらを実装していません。このコマンドは、OpenSSL 3 の既定の形式である AES で再暗号化します。

ユースケース

  • 認証局から届いた証明書をインストールする前に、すべてのドメイン (SAN) がカバーされ、有効期限が想定どおりであることを確認する。
  • サーバーに残っている秘密鍵のどれが各証明書に対応するかを、OpenSSL でモジュラスを比較することなく特定する。
  • クライアントがサイトを信頼しない原因を突き止める: 中間証明書の欠落、順序の乱れたチェーン、SHA-1 で署名された証明書など。
  • 証明書の購入や更新に必要な CSR を、手元のコンピューターで作成した鍵で生成する。サーバー上で行いたい場合に備えて、同等の OpenSSL コマンドも表示されます。
  • .crt とその .key を IIS、Azure App Service、Java キーストア用の .pfx に変換する、または .pfx から nginx 用に証明書と鍵を取り出す。
  • モバイルアプリで certificate pinning を設定したり、クライアント証明書を検証したりするために、証明書のフィンガープリントや SPKI ピンを取得する。

よくある質問

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

鍵はブラウザー内で Web Crypto API によって処理され、どのサーバーにも送信されません。開発者ツールの [ネットワーク] タブで確認できます。それでも、本番環境の鍵はすべて機密情報として扱うのがベストプラクティスです。信頼できるツールにだけ貼り付け、作業が終わったらタブを閉じてください。

PEM、DER、CRT、CER、P7B、PFX の違いは何ですか？

DER はバイナリ形式の証明書で、PEM は同じバイナリを BEGIN 行と END 行の間に Base64 で記述したものです。拡張子 .crt と .cer は形式を示すものではなく、どちらの形式も入り得ます。.p7b は複数の証明書を含み、鍵を含まない PKCS#7 パッケージです。.pfx や .p12 は PKCS#12 で、証明書、中間証明書、秘密鍵をまとめてパスワードで暗号化して保存します。

サーバーに中間証明書が不足しているかどうかは、どうすればわかりますか？

サーバーに設定している内容を貼り付けてください。チェーンが自己署名ではない証明書で終わっている場合は、1 つ欠けています。その証明書の Authority Information Access 拡張の CA Issuers には、通常、発行者をダウンロードするためのアドレスが記載されています。デスクトップのブラウザーは自動で取得することがありますが、Android、curl、ほとんどのライブラリは取得しないため、一部のクライアントでだけエラーが発生します。

公開 TLS 証明書の有効期間はどのくらいまで可能ですか？

2020 年 9 月以降、ブラウザーは 398 日を超える証明書を拒否しています。CA/Browser Forum は 2025 年に、上限を段階的に短縮することを承認しました。2026 年 3 月 15 日以降に発行されるものは 200 日、2027 年 3 月以降は 100 日、2029 年 3 月以降は 47 日です。そのため、ACME で更新を自動化することをおすすめします。企業の社内 CA にはこの制限はありません。

CSR には RSA と ECDSA のどちらを使うべきですか？

ECDSA P-256 は、はるかに小さい鍵と署名で 3072 ビットの RSA に匹敵するセキュリティを実現し、サーバーのハンドシェイクも高速になります。現在のすべてのブラウザーとシステムがサポートしています。非常に古いクライアント、組み込み機器、または RSA しか受け付けないシステムがある場合は、RSA 2048 が引き続き安全な選択肢です。

コモンネーム (CN) にドメインを入れるだけで十分ですか？

いいえ。2017 年の Chrome 58 以降、ブラウザーはサブジェクト代替名 (SAN) だけを参照し、CN は無視されます。CN のドメインも含め、証明書で使用するすべてのドメインを SAN のリストに含める必要があります。*.example.com のようなワイルドカードは 1 階層のみをカバーし、www.example.com には使えますが、example.com や a.b.example.com には使えません。

関連項目