証明書デコーダーがよく使われる場面：デプロイ直前にステージング環境が SSL_ERROR_BAD_CERT_DOMAIN を返し、手元には PEM ブロックしかない。見たいのは SAN の一覧、有効期限、SHA-256 フィンガープリントだ。openssl x509 -text でも見られるが、ほかの全フィールドと一緒に出てくる。専用のデコーダーはこれらを先頭に出す。

証明書をすぐデコード →

PEM 証明書の中身

.pem ファイルは DER バイナリを Base64 でくるんだだけのものだ。-----BEGIN CERTIFICATE----- と -----END CERTIFICATE----- を剥がして Base64 デコードすれば、ASN.1 でエンコードされたバイナリ構造が出てくる——LDAP メッセージ、SNMP パケット、ほとんどの公開鍵フォーマットと同じエンコーディングだ。

トップレベルの形は RFC 5280 で固定されている:

Certificate ::= SEQUENCE {
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING
}

tbsCertificate(「to be signed」、署名対象)に、人間が気にする情報がすべて入っている——バージョン、シリアル、有効期間、Subject、Issuer、Subject Public Key Info、そして v3 拡張の一覧。signatureAlgorithm と signatureValue は残りの仕事を担う:TBS バイト列が対応 CA によって署名されたことを示す。

ZeroTool のデコーダーは、純粋な JavaScript で書かれた小さな ASN.1 パーサーで、このツリーをすべてブラウザ内で歩く。アップロードもサーバー側の OpenSSL も API キーも不要だ。cert-tools-online.example には貼り付けるのをためらうような PEM でも、ここなら安全に貼れる。

有効期間の読み方

notBefore と notAfter のタイムスタンプは、2050 年より前なら UTCTime(YYMMDDhhmmssZ)、それ以降なら GeneralizedTime(YYYYMMDDhhmmssZ)でエンコードされる。RFC 5280 がこの切り替えを規定しているのは、2 桁年号があいまいにならないようにするためだ。

実務で気にするのは次の 4 状態:

状態意味アクション
有効(残り 30 日超)期限内・更新ウィンドウ前何もしなくてよい——ただし期限を監視ダッシュボードに登録する
30 日以内に期限切れブラウザはまだ受け入れる、ACME・商用 CA の更新はこの窓口で発火ローテーションをスケジュール
期限切れブラウザが拒否、クライアントは NET::ERR_CERT_DATE_INVALID を見る即座にローテーション。期限が直近なら時計ずれを確認
まだ有効でないnotBefore が未来——時計のずれか段階展開サーバー NTP と CA 発行時刻を確認

デコーダーはこれらの状態をステータスのバッジに色で示し、残り日数も併記する。30 を割っていたら会話は「更新ジョブは動いているか?」に切り替わる。

Subject・Issuer・SAN——現代のホスト名照合ルール

ブラウザーはホスト名の照合に Subject の CN を使わず、Subject Alternative Name（SAN）拡張を使う。Chrome はバージョン 58 で CN へのフォールバックをやめ、Apple は iOS 13 と macOS 10.15 から名前が SAN にあることを求めている。CN=example.com だけで SAN がない証明書は、現在のブラウザーでは拒否される。

だから証明書をデコードしたらこの順で読む:

  1. SAN——この証明書は実際にどのホスト名をカバーするのか?
  2. Subject——CN は一致しているか?(主に人間向け。CA はまだ埋める習慣だ)
  3. Issuer——誰が署名したか？（Let’s Encrypt の中間証明書 R10 や E5、DigiCert、ZeroSSL などのどれを想定すべきかが分かる）

今日の典型的な Let’s Encrypt 証明書は、SAN にネイキッドドメイン(example.com)と www サブドメインの両方を持つ。ワイルドカード証明書では *.example.com が SAN であり、CN ではない。デコーダーは SAN エントリを種別(DNS、IP、URI、email)でグルーピングして表示するので、誤発行のワイルドカード証明書が一目でわかる。

Key Usage と Extended Key Usage は「許可証」

Key Usage 拡張は 9 ビットの BIT STRING で、この証明書の公開鍵に許される行為を宣言する。Extended Key Usage(EKU)は Key Usage の上に重ねて、serverAuth や codeSigning のような意図レベルの粒度で許可を細分化する。

TLS サーバー証明書なら典型的にはこうなる:

Key Usage: digitalSignature, keyEncipherment
EKU      : serverAuth (some certificates also carry clientAuth)

CA 証明書(中間または root)ならこうだ:

Key Usage: keyCertSign, cRLSign
Basic Constraints: CA = true

リーフ証明書に keyCertSign が立っていたら異常だ——このビットは他の証明書を署名する権限を意味し、中間 CA だけが持つべき特権だ。デコーダーは KU と EKU を読みやすいチップで並べるので、一覧で目視確認できる。

フィンガープリント:どのハッシュをどう使うか

デコーダーが出すフィンガープリントは、証明書の DER バイト列全体(PEM テキストでも公開鍵単独でもない)に対する SHA-256、SHA-1、MD5 のダイジェストだ。証明書の中身ではない——CA は署名していない——が、特定の証明書ファイルを識別する最も安価な手段ではある。

ハッシュ2026 年の実用途
SHA-256標準の識別子。openssl x509 -fingerprint -sha256 が出力し、現在のほとんどのツールや台帳もこれを記録する。
SHA-1レガシーツール:古い監視スクリプト、未移行の社内 CMDB、一部の IDS/IPS シグネチャ。新規のピンニング用途では使わない。
MD5かなり古い openssl 出力との互換のため。暗号学的には破られている——読み取り照合用途のみ。

証明書ファイルを識別するなら SHA-256 の行を使う。証明書ピンニングは通常、証明書全体ではなく公開鍵（SPKI）の SHA-256 ハッシュを固定するので、同じ鍵で更新しても有効なままだ。このデコーダーはその SPKI ハッシュも Base64（RFC 7469 の pin-sha256 形式）で表示する。誰かがログに書き残したハッシュを探すなら、3 種類のフィンガープリントが全部出るので推測しなくて済む。

RSA・ECDSA・Ed25519——公開鍵フィールドが教えてくれること

Subject Public Key Info セクションは、アルゴリズム OID と生の鍵バイト列を持つ。現代で遭遇する 3 形態:

1.2.840.113549.1.1.1  rsaEncryption          (古典的な RSA)
1.2.840.10045.2.1     id-ecPublicKey         (名前付き曲線上の ECDSA)
1.3.101.112           id-Ed25519             (edwards25519 上の EdDSA)

RSA の鍵バイト列はそれ自体が ASN.1 SEQUENCE { modulus, exponent } だ。デコーダーは modulus のビット長を報告する——2048 は許容範囲、3072 は推奨、4096 はルート CA 領域。2026 年に 1024 ビット RSA が出てきたら指摘事項だ:主要ブラウザは 2014 年あたりから受け入れを停止している。

ECDSA は名前付き曲線 OID を表示する。実務で遭遇する 3 種類:

  • prime256v1（別名 P-256、secp256r1）——Certbot 2.0 以降が既定で生成する ECDSA 鍵の曲線
  • secp384r1(P-384)——一部 EV 証明書や Windows エンドポイントが好む
  • secp521r1(P-521)——実環境では稀。主に内部コンプライアンス用途

Ed25519 証明書は現在、公開 Web の TLS では使われない。CA/Browser Forum の Baseline Requirements が、公的に信頼される TLS 証明書に RSA と ECDSA の鍵しか認めていないためだ。プライベート PKI や社内のメッシュ TLS で見かける。デコーダーは OID でラベル付けするので覚えなくていい。

バンドルファイルと処理範囲

PEM バンドルとは、-----BEGIN CERTIFICATE----- ブロックを複数連結したものだ。サーバーが leaf + 中間 + ルートをチェーンファイルでまとめて配信したり、CA が fullchain.pem として提供したりするときに出てくる。

ZeroTool のデコーダーは入力のすべての証明書をデコードし、チェーンを確認する。各証明書の次にその発行元が並んでいるか、次の証明書の公開鍵で署名を検証できるかを見る。一覧の証明書を押せば詳細が出る。トラストストアは持たないので、信頼の判定は手元で openssl verify -CAfile chain.pem cert.pem を実行する。

デコード結果で「ん?」と思うべきポイント

運用レビューで次のパターンは赤フラグだ:

  • 公開 TLS リーフ証明書の有効期間が現在の上限を超えている。 CA/Browser Forum の Baseline Requirements は 2020 年 9 月から公開 TLS 証明書を 398 日以内に制限し、投票 SC-081 により 2026 年 3 月 15 日以降に発行する証明書は 200 日以内になった。これより長ければ、非公開 CA、設定を誤ったプライベート PKI、または古い証明書だ。
  • CN は埋まっているが SAN がない。前述のとおりブラウザは拒否する——新規デプロイを壊しそうなレガシー内部 CA フローを発見するのに便利。
  • サーバー証明書に CA = true。誤発行か、リーフと取り違えた中間証明書のどちらかだ。
  • AIA に OCSP URL があるが OCSP Must-Staple フラグがない。ほとんどのデプロイでは問題ないが、stapling を必須化する環境なら発行時に OCSP Must-Staple 拡張(OID 1.3.6.1.5.5.7.1.24)を追加する必要がある。

openssl x509 -text との関係

openssl x509 -in cert.pem -noout -text
openssl x509 -in cert.pem -noout -fingerprint -sha256
openssl x509 -in cert.pem -noout -dates -subject -issuer -ext subjectAltName

openssl は網羅的でスクリプト化しやすい。ZeroTool のデコーダーは、インシデント対応時の「これは何の証明書なのか?」という単発の問いに対して速い。両者は補完関係で代替ではない——openssl はパイプラインに、デコーダーは Slack に貼られた PEM をすぐ読む瞬間に。

運用担当が気にするプライバシー上の論点

本番証明書を見慣れない Web ツールに貼り付ける行為はソフトリークだ:証明書自体は公開情報で TLS クライアント全員が受け取るとはいえ、貼り付けたという行為そのものが「今この瞬間、御社の誰かがこの証明書をデバッグ中」と相手のサーバーに伝える。一部のコンプライアンス枠組みではこのパターンを監査ログにマークする。

ZeroTool のデコーダーはブラウザータブ内で完結し、PEM はどこにも送られない。ページ自体はサイトのほかのページと同じく解析と広告のスクリプトを読み込むが、それらのリクエストに証明書は含まれない。DevTools → Network を開き、PEM を貼ってデコードし、新しいリクエストに含まれていないことを確認できる。

関連リソース