証明書 / PEM デコーダー

このツールの役割

証明書は二本のダッシュの行に挟まれた Base64 の塊として届き、見ただけでは何も分かりません。これはそれをデコードします: 誰に、誰によって発行されたか、いつ失効するか、どのホスト名を覆うか、どんな種類の鍵を持つか、そして運ぶすべての拡張です。チェーン全体を貼り付ければ、各証明書が次のものに対して確認されます。

完全にブラウザ内で動きます。これはほとんどのツールよりここで重要です — 代わりの手はたいてい本番の証明書を誰かのサーバーに貼り付けるか、openssl の呼び出しを覚えておくことで、ほとんど誰もしません。

PEM は包みにすぎない

ダッシュと Base64 は梱包です。中身は DER、ASN.1 と呼ばれる構造のバイナリ符号化で、ダッシュの間のラベルがどの構造を期待するかを言います:

CERTIFICATE           発行された X.509 証明書
CERTIFICATE REQUEST   CSR: CA に求めたもの
PUBLIC KEY            素性の付かない素の鍵
PRIVATE KEY           秘密の半分、ここでは拒否される

同じ証明書は、ダッシュも Base64 もない生の DER として .cer や .crt ファイルでも届きえます。ファイルがテキストではなくバイナリの雑音として開くなら、それがそれです。先に Base64 化するか、PEM としてエクスポートしてください。

証明書に実際に入っているもの

中核のフィールドは、これまで発行されたすべての証明書で同じです:

• サブジェクト — 証明書が誰についてのものか。Web サイトでは今やたいていコモンネームだけで、しばしばそれ以上は何もありません。
• 発行者 — それに署名した認証局。そのサブジェクト名が、それが署名するすべてのものの発行者としてそのまま現れ、それがチェーンの確認を可能にするものです。
• 有効期間 — 二つの絶対的な瞬間で、常に UTC です。このツールは両方を示し、残りがどれだけかをブラウザ内で割り出します。このページを生成したビルドマシンは、あなたがいつ読んでいるか知らないからです。
• シリアル番号 — 発行者ごとに一意で、証明書が失効されるときに使われる識別子です。
• 署名アルゴリズム — 発行者が何で署名したか、例えば SHA-256 with ECDSA です。
• 公開鍵 — 種類と大きさ。RSA ではモジュラスのビット長、EC では名前付き曲線の性質なので P-256 は常に 256 ビットです。

人が期待してもう見つけないフィールドが一つ: サブジェクトのコモンネームはブラウザが確認するものではありません。ホスト名の照合には何年も無視されてきました。重要なのは、下記のサブジェクト代替名の拡張です。

動くかどうかを決める拡張

証明書はいくつでも拡張を運べます。そのうち五つが実際に受け付けられるかを決め、このツールはそれらを完全にデコードします:

• サブジェクト代替名 — 証明書が有効なホスト名・IP アドレス・メールアドレス。これがブラウザが確認するフィールドで、SAN があなたが入力した名前を列挙しない証明書は、ほかのすべてがどれだけ正しくても拒否されます。
• 基本制約 — これが認証局かどうか、そしてその下にいくつの中間証明書が座れるか。CA と印された末端証明書、あるいはその逆は、チェーンを壊します。
• 鍵用途 — 鍵がそもそも何に使えるか: 署名、鍵の暗号化、証明書の署名。ほぼ常にクリティカルと印され、それはソフトウェアが理解しない用途を無視するのではなく証明書を拒まねばならないことを意味します。
• 拡張鍵用途 — 目的: TLS サーバー、TLS クライアント、コード署名、メール。TLS サーバー認証のない証明書は Web サイトを提供せず、これはほかのもののために発行された証明書でよくある驚きです。
• サブジェクトと機関の鍵識別子 — いくつかが名前を共有するとき、ソフトウェアが証明書をその発行者に素早く照合できるようにする短いハッシュ。

ほかのすべての拡張は、名前が分かればその名前、OID、そしてクリティカルと印されているかとともに一覧されます。何も黙って落とされません: このツールがデコードしない拡張も現れるので、それがそこにあることが分かります。

チェーンと、ここでの「連結」の意味

サーバーはほぼ決して一つの証明書を送りません。自分自身に加えて、クライアントが既に信頼するルートに到達するのに必要な中間証明書を送ります。順序が重要で、ファイルはたいてい fullchain.pem と呼ばれます:

ブロック 1   末端          サブジェクト: example.com     発行者: Example CA R3
ブロック 2   中間          サブジェクト: Example CA R3   発行者: Example Root
ブロック 3   ルート        たいてい省かれる、クライアントが既に持つので

各証明書は発行者を名指し、その下の次の証明書は、まさにその名前をサブジェクトとして持つべきです。このツールはその二つの名前をバイト単位で比べ、一致するかを言います。それがオフラインで確認できる唯一の関係で、ほとんどのチェーンの問題を占める二つの失敗を捕らえます: 中間証明書の抜けと、誤った順序で貼られたブロックです。

それらの失敗には特徴的な症状があります。デスクトップのブラウザはしばしば、抜けた中間証明書を自分で取得して覆い隠すので、サイトはノートパソコンでは問題なく見えて、電話・モバイルアプリ・curl からは失敗します。それがデバッグしているものを言い当てるなら、まず完全なチェーンをここに貼り付けてください。

このツールが教えないこと

署名を検証せず、できません。証明書が本当に発行者に署名されたかを確認するには発行者の公開鍵が要り、その発行者が信じられるべきかを決めるにはトラストストアが要ります。貼り付けたファイルはどちらも供給しません。失効も確認できず、それは CA へのネットワークリクエストを要します。

だからここでの「チェーンが連続している」は、名前が揃うことを意味し、チェーンが有効であることではありません。偽造された証明書のチェーンも完璧に連結するでしょう。この確認が役立つのは、自分の設定の構造的な誤りを見つけることで、それが人がチェーンをデコーダーに貼り付けるとき実際に見ているものです。

フィンガープリントと秘密鍵

SHA-256 フィンガープリントは証明書全体のハッシュで、誰かがあなたに引用した値や、ピンと比べるものです。それが何を識別するかに注意してください: その中の鍵ではなく、証明書です。同じ鍵で証明書を更新すると異なるフィンガープリントを生み、それが更新でピンが壊れるふつうの理由です。SHA-1 フィンガープリントも示されます。古いツールやコンソールが今も表示するからで — 識別のためだけです。SHA-1 に何かに署名する用はありません。

秘密鍵は認識され、拒否されます。ここに貼り付けたものはブラウザを離れないので、拒否はこのページについてではありません: 秘密鍵を Web フォームに貼り付けるのは身につけないほうがよい習慣で、次に求めるサイトはローカルで動いていないかもしれない、ということです。鍵と証明書が組であることを確認する必要があるなら、証明書からの公開鍵を、鍵から導いたものと、ローカルで比べてください。