01
境界行を省略しない
BEGIN CERTIFICATEからEND CERTIFICATEまでを一組として、中間証明書も含めて貼り付けます。秘密鍵やCSR、ブロック外の説明文は受け付けません。元の入力番号が結果に残るので、順序が変わっても照合できます。
証明書の診断
証明書チェーンの検証
PEMバンドルを任意の順序で貼り付けます。最初の確認後、必要なら対象証明書と信頼アンカーを選び直してください。
証明書チェーンの検証
PEM証明書
ローカル処理。証明書の送信やAIA・OCSP・CRLへの照会はありません。
経路とレポート
PEM証明書を貼り付けてください。
対象とアンカー
一度実行すると候補が表示されます。今回のアンカーとして扱う場合だけ入力内のCAを選び、再確認してください。
PEM証明書20枚、入力256 KiB、経路結果64件まで。
PEM証明書を貼り付けてください。
インポート時に発行者エラーが出る場合、証明書チェーンの検証で手元の材料のつながりを確かめられます。発行者名が一致していても、別の公開鍵を持つ証明書かもしれません。署名で確認したリンクと経路の終点を読み、配置先の信頼設定とは分けて判断します。
証明書チェーンの検証で見分けること
名前の一致だけでは接続しない
証明書チェーンの検証では、発行者候補の公開鍵で実際に署名を調べます。同じサブジェクト名の証明書が複数あっても、失敗した候補と検証できたリンクを区別し、見た目だけ整った経路を作りません。
終点と信頼を分けて読む
末端から発行者へ進んだ経路が自己署名証明書で終わっても、それを自動的には信頼しません。入力内のCAを明示的に選んだ場合だけ、そのアンカーへ到達するかを表示します。
インポート前に確認する三つの点
02
対象が複数なら選び直す
最初の実行で証明書が選択肢に現れます。末端証明書が複数ある場合は、今回追跡する対象を選んで再実行してください。信頼アンカーは未指定でもよく、指定する場合は入力内のCAから選択します。
03
出力が止まる理由を読む
発行者不足は中間証明書とは限らず、ルートを含めなかった可能性もあります。診断はJSONで保存できますが、PEM出力には全入力を使う完全で一意の経路と、診断上の問題がないことが必要です。編集後は再確認します。
レポートに含まれる診断
署名の状態を分離
名前が対応する候補ごとに検証し、成功、失敗、現在の環境では未対応という状態を表示します。自己署名も検証対象です。アルゴリズムを処理できない場合に、成功とみなすことはありません。
証明書ごとの識別情報
サブジェクト、発行者、シリアル番号、SHA-256フィンガープリント、UTCの有効期間を確認できます。重複は証明書全体の符号化データで判定し、名前が同じだけでは同一視しません。
基本的な経路の問題
期限切れ、未発効、発行者不足、CAではない署名者、証明書署名用の鍵用途、パス長制約を診断します。重複拡張や未処理の重要拡張も表示し、黙って読み飛ばした結論を出しません。
元の入力を保った出力
証明書チェーンの順序を確認してもエディターは書き換えません。JSONには全証明書、候補リンク、経路と診断を保存し、失効確認とシステムの信頼確認を実施していないことも明記します。
判定の範囲と入力の制限
- 不足分の取得は行わない
- AIAのURLや対象サーバーへ接続せず、OCSP照会やCRL取得も行いません。必要な中間証明書は適切なCAから別途入手し、入力に追加してください。
- ルートを自動的に信頼しない
- ルート証明書が自己署名であることは、信頼の根拠にはなりません。選んだアンカーへの到達は今回の入力内のつながりを示すだけで、ブラウザやOSの受け入れを保証しません。
- 完全なPKIX検証ではない
- 名前制約、証明書ポリシー、アプリケーション用途、ホスト名照合、網羅的なアルゴリズム強度の判定は範囲外です。RFC 5280の完全な経路検証や、サイト全体の安全性の証明として使わないでください。
- 曖昧な経路を勝手に選ばない
- クロス署名、重複、無関係な証明書、未解決の診断や終点不足があれば、並べ替えたPEMは出力しません。解析が完了していればJSONは保存でき、止まった理由を引き継げます。
- PEMのみ、最大20枚
- 入力はCERTIFICATEブロック20枚、256 KiBまでです。DER、PFX、PKCS#7、CSR、秘密鍵は拒否します。経路探索は64結果までとし、上限に達した場合はその事実を報告します。
証明書チェーンの検証に関する質問
証明書のインポート時にチェーンの検証が失敗するのはなぜですか？
不足する発行者、署名の不一致、証明書の用途や有効期間を確認してください。このページは入力した材料を診断しますが、インポート先の信頼ストアや設定は読み取れません。エラーの位置とそのシステムの要件を併せて調べます。
SSL証明書のデプロイが失敗するのはなぜですか？
秘密鍵との組み合わせ、ホスト名、サーバー設定など、チェーン以外にも原因があります。本ツールは秘密鍵を受け取らず、デプロイ先へ接続もしません。ここで経路が完成しても、配置作業の完了を意味しません。
チェーン内の中間証明書はどの順序に並べますか？
一般的なサーバー用バンドルは末端証明書の後に中間証明書を並べます。解析時の入力順は任意です。本ツールの出力は供給したルートも含むため、そのまま配備する前に利用先の形式要件を確認してください。
検証結果が有効ならブラウザも信頼しますか？
いいえ。アンカー未指定では自己署名の終点があっても信頼は判断しません。選択したCAへの経路が見つかっても、ブラウザのルートストア、利用目的、失効状態は別途確認が必要です。
失効した証明書も検出できますか？
失効確認は行いません。署名が正しくても、証明書は後から失効することがあります。JSONにも未確認のフラグを残すため、OCSPやCRLによる現在の状態は別の手段で調べてください。
確認したい証明書チェーンの事例はありますか？
補ったバンドルをもう一度確認
不足した発行者を追加したり、アンカーを変更したりした後は、証明書チェーンの検証を再実行してください。新しい経路と診断を比較してから設定の置き換えを判断できます。