X.509 証明書デコーダー

動作のしくみ

• -----BEGIN CERTIFICATE----- と -----BEGIN CERTIFICATE REQUEST----- のブロックを順番にすべてデコードします。貼り付けに含まれる秘密鍵やその他の PEM ブロックは数えるだけで解析しません。
• 一般的なリーフ証明書が先頭の順序のチェーンでは、各証明書の発行者名を次の証明書のサブジェクトと比較し、次の証明書の公開鍵で署名を検証します。
• フィンガープリントは DER バイト列の SHA-1 と SHA-256 で、コロン区切りの 16 進数で表示されるため、ブラウザ、openssl、証明書ピンニングの設定値と直接比較できます。
• CSR の自己署名も検証するので、CA に料金を払う前に、編集されたり不完全にコピーされたりした要求を見つけられます。

よくある質問

証明書が信頼されているかどうかもわかりますか？

いいえ。証明書に書かれている内容を読み取り、貼り付けた証明書同士の署名を検証しますが、失効状態（OCSP や CRL）や、ルートがブラウザのトラストストアに含まれるかは確認しません。どちらもネットワークか信頼リストが必要です。公開中のサイトなら、ブラウザ自身がその判定を示し（開発者ツールのセキュリティパネルで説明されます）、SSL Labs のようなスキャナーで設定全体を確認できます。

CN がドメイン名と一致しているのに、ブラウザが証明書を拒否するのはなぜですか？

ブラウザはホスト名をサブジェクト代替名とだけ照合し、何年も前から CN を無視しているからです。Chrome は 2017 年に CN の使用をやめました。ここに表示される SAN の一覧に正確なホスト名（またはその 1 階層を覆うワイルドカード）がなければ、CN に何が書いてあっても証明書は検証に失敗します。

現在、公開 TLS 証明書の有効期間は最長どのくらいですか？

以前よりずっと短くなっています。CA/Browser Forum は最大有効期間を段階的に短縮することを決議し、2029 年には 47 日になります。そのため、certbot などの ACME クライアントによる自動更新が TLS 運用の標準になりました。ここに表示される残り日数は、自動化から漏れた証明書を見つけるのに役立ちます。

チェーンファイルはどの順序にすべきですか？

リーフ証明書を先頭に、続けて各中間証明書を並べ、それぞれが次の証明書によって署名されている形にします。ルートはクライアントがすでに持っているので、通常は含めません。「Issued by next」の行は、順序の誤りや中間証明書の欠落を示します。これは、あるブラウザでは動くのに curl や古い Android では失敗する最もよくある原因です。

ここに証明書を貼り付けても安全ですか？

証明書はもともと公開されるもので、TLS クライアントは誰でも受け取るため、秘密の情報は含まれていません。秘密鍵は貼り付けないでください。このツールには不要で、見つけても読み飛ばします。

別の呼び方

• 証明書 デコード
• X.509 デコーダー
• PEM 証明書 確認
• SSL 証明書 チェック
• CSR 確認
• 証明書 フィンガープリント SHA256