SSL証明書・CSR 内容確認

SSL証明書や CSR の内容をブラウザ内で確認します。送信は一切ありません。

cert-viewer

🖥 Reads an X.509 certificate or a PKCS#10 CSR entirely in your browser. Nothing is uploaded. A private key is refused rather than displayed.

Paste PEM (certificate or CSR)

§01 このツールについて

概要

証明書は、署名された主張の集合を DER というバイナリで符号化し、転送のために Base64 で包んだものです。実務で証明書に起きる問題はすべてその主張の中に見えます。 SAN 一覧から抜けている名前、思っていたより早く終わる有効期間、リーフを貼るべき場所に貼られた中間証明書、購入した用途を禁じている鍵用途です。

このビューアは PEM を復号し、DER を解析して中身を並べます。X.509 証明書と PKCS#10 の証明書要求の両方に対応します。これをブラウザ内で行い、秘密鍵はきっぱり拒否します。

使い方

-----BEGIN CERTIFICATE----- または -----BEGIN CERTIFICATE REQUEST----- で始まる PEM ブロックを貼ります。
要約を読みます。種別、サブジェクト、発行者、有効期限、残日数です。
SAN 一覧を、配信する予定のホスト名と突き合わせます。

サーバーから実際の証明書を取得するには次のようにします。 openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509

有効な名前は SAN だけ

サブジェクトの Common Name は証明書の名前のように見えますが、ホスト名の検証には使われません。Chrome はバージョン 58 から無視し、他のブラウザも続きました。参照されるのは subjectAltName 拡張だけです。

実務上の帰結は次のとおりです。

ホスト名が CN にしか 無い証明書は、現行のどのブラウザでも検証に失敗し、そしてサブジェクトを目立つ位置に表示するツールでは完全に正しく見えます。
ワイルドカード *.example.com は 1 ラベルにだけ一致します。www.example.com を覆い、a.b.example.com は覆いません。裸の example.com も覆いません。その名前には自分の SAN 項目が必要で、だから証明書は両方を並べて記載します。
SAN には型があります。dNSName・iPAddress・rfc822Name・URI の各項目を表示します。誤った型に入れたホスト名は一致しません。

鍵とその用途の読み方

鍵のアルゴリズムと長さは公開鍵の構造から読みます。RSA では法（モジュラス）の長さがそのままビット長になります。EC では名前付き曲線が使われていればその名前を、曲線名ではなく明示的パラメータを持つ場合はそう述べます。明示的パラメータは現代の TLS スタックのほとんどが拒否するので、見えることに意味があります。曲線名が無い場合は公開点の長さから長さを導きます。P-521 の鍵が、単純なバイト数から出る 528 ではなく 521 と報告されるのはそのためです。

keyUsage と extendedKeyUsage は鍵に許された用途を示し、どちらも強制されます。 EKU に serverAuth を持たない証明書は、他がすべて正しくても TLS には使えません。クライアント証明書を誤ってサーバーに入れたときによく起きる結果です。

basicConstraints は証明書が CA かどうかを示します。リーフ証明書だと思って貼ったものが CA と報告されたら、貼ったのは中間証明書です。ローカルでは検証が通り他の環境では失敗する連鎖の、通常の原因です。

拡張の一覧は、存在するすべての拡張を critical フラグ付きで示します。RFC 5280 により、クライアントが理解できない critical 拡張は拒否を引き起こさなければならないので、見慣れない critical 拡張は調べる価値があります。

使用例

検証が通らない名前 — サブジェクトではなく SAN 一覧を確認します。ホスト名が CN にしか無ければ、証明書を再発行するしかありません。
送る前に CSR を読む — CSR はサブジェクトと公開鍵を確定します。送信前に名前を確認すれば再発行の往復を避けられます。とくに CA が再発行を有償にしている場合に重要です。
どの証明書を持っているかの確認 — リーフ・中間・ルートはテキストとしては似ています。basicConstraints とサブジェクト・発行者の関係で即座に判別できます。ルートはサブジェクトと発行者が同一です。
更新の計画 — 残日数を直接表示します。業界が最大有効期間の大幅な短縮へ向かっているため、年 1 回の証明書で成立していた手作業の更新手順はこの変化を越えられません。
バンドルの点検 — ブロックを 1 つずつ貼ります。順序が誤っているバンドルや、無関係な証明書が混ざったバンドルは、一部のクライアントでのみ現れる連鎖エラーの頻出原因です。

注意事項

受け付けるのは CERTIFICATE と CERTIFICATE REQUEST の PEM ブロックだけです。それ以外のブロック種別（すべての秘密鍵形式を含む）は、見つかったものを示すエラーで拒否します。拒否したブロックについては何も解析せず、何も表示しません。

DER パーサは DER が禁じているものを拒否します。長さ不定の符号化、バッファ末尾を越える長さ、32 段を超える入れ子です。途中で切れた貼り付けは、部分的に埋まった結果ではなく ASN.1 length exceeds buffer のような具体的なメッセージになります。半分だけ解析された証明書は誤読を招くからです。解析が失敗したときに前の結果を消すのも同じ理由です。

日付は証明書に符号化されているとおりに表示します。GeneralizedTime は 4 桁の年を持ち、UTCTime は 2 桁で、RFC 5280 が解釈を 50〜99 は 19xx、00〜49 は 20xx と定めています。残日数はご使用の端末の時計に対して計算するので、システム時刻が誤っていれば数字も誤ります。

このツールは 1 枚の証明書を単独で読みます。連鎖の構築、失効、信頼は評価しません。サーバーが実際に何を送り、どう応答するかを見るには HTTP ヘッダー取得とセキュリティヘッダー診断を使ってください。ここでの処理はすべてブラウザ内で完結します。詳細はプライバシーポリシーに書いてあります。

FAQ

証明書はどこかにアップロードされますか？

いいえ。PEM を Base64 復号し、DER 構造をブラウザ内で解析します。何も送信せず、読み込み後はオフラインでも動きます。これは聞こえるより重要な点です。証明書が入っているクリップボードには、その少し前に秘密鍵が入っていたのが通常だからです。

間違えて秘密鍵を貼ったらどうなりますか？

ブロック種別を示すエラーで拒否し、その中身は一切解析も表示もしません。受け付けるのは CERTIFICATE と CERTIFICATE REQUEST だけです。証明書を扱う人の手元には対応する鍵があるので、拒否することが唯一安全な既定値です。

ドメインがサブジェクトと SAN の両方にあるのはなぜですか？

SAN 一覧だけが有効だからです。ブラウザは何年も前にホスト名の照合でサブジェクト CN を使うのをやめました（Chrome は 58 以降）。そのため名前が CN にしか無い証明書は、どれだけ正しく見えても検証に失敗します。CN は表示と旧来のツールのために残っているだけです。

証明書が信頼されるかは分かりますか？

分かりません。信頼はクライアントが信頼するルートまでの連鎖、失効状態、そしてクライアント側の現在時刻に依存します。ここで読むのは 1 枚の証明書が自分について主張している内容です。自己署名証明書と公的 CA の証明書はここでは同じくらい妥当に見え、違いが分かるのは発行者の欄です。

CSR に有効期限が出ないのはなぜですか？

CSR には有効期限がありません。サブジェクト・公開鍵・要求する拡張を含み、対応する秘密鍵で署名された要求です。有効期限は発行する CA が決めるので、notBefore と notAfter は証明書が発行されてから存在します。

残日数が負の数になるのはどういう意味ですか？

すでに失効しており、その数字は何日前に失効したかです。日付は証明書に符号化されているとおりに読みます（UTCTime の年は RFC 5280 に従い、50〜99 は 19xx、00〜49 は 20xx と解釈します）。残日数はご使用の端末の時計と比較して計算します。