入力データはサーバーに送信されますか?

いいえ。**@peculiar/x509** (MIT) と **Web Crypto API** (`crypto.subtle.digest`) を使ってブラウザ内 JavaScript ですべて処理します。外部 API も解析サーバーもありません。**社内の証明書や private 環境の cert** も安心して貼り付けられます。

対応している証明書フォーマットは?

**X.509 v3 / PEM (Base64) フォーマット** のみ。Let's Encrypt / DigiCert / GlobalSign / 各国 GPKI / 社内 PKI が標準的に発行する形式すべて。**DER (バイナリ)** や **PKCS#12 (.p12 / .pfx、秘密鍵入りバンドル)** は未対応 — 先に `openssl x509 -inform DER -in cert.der -out cert.pem` などで PEM に変換してください。

**チェーン (中間 CA + サーバー証明書)** は解析できますか?

はい。**`-----BEGIN CERTIFICATE-----` ブロックを連続して** 貼ると順に解析して **チェーン全体** を表示します。`openssl s_client -connect nosend-tools.com:443 -showcerts` の出力を **そのまま貼って** OK。各証明書ごとに Subject + Issuer + 有効期限が出るので、**Issuer == 次の証明書の Subject** をたどれば順序の正しさを確認できます。

**有効期限のチェック** はどう判断していますか?

**現在のブラウザ時刻 (`new Date()`) と `notBefore` / `notAfter` を比較**。`now notAfter` なら **`Expired`** バッジ。それ以外は **`Valid`** バッジ + **残り日数** を表示。**サーバーの時刻** ではなく **ブラウザの時刻** を使うので、PC 時計がズレているとズレた判定になります。SSL 監視には ssl-checker 系の外部サービスも併用してください。

**SAN (Subject Alternative Names) と DNS の一致** はどう確認しますか?

本ツールは SAN の **タイプ (DNS / IP / Email / URI)** と **値** を一覧表示します。実際の DNS マッチング (`*.nosend-tools.com` がワイルドカードで一致するか等) は **ブラウザがその場で確認** するので、本ツールではしません。**`Subject CN`** ではなく **`SAN DNS`** が現代の TLS では優先 (RFC 6125)、CN だけで SAN が空の cert はブラウザによっては警告。

**SHA-1 と SHA-256 フィンガープリント** はどっちを使うべき?

**SHA-256** を推奨 (現代の標準、衝突攻撃に強い)。**SHA-1** は古いシステムの **pinning** や **ログ照合** で互換性のために残ってますが、新規システムには使わないでください。両方を `AA:BB:CC:...` のコロン区切り 16 進形式で表示 (OpenSSL / Chromium / Firefox 互換)。

**Key Usage** と **Extended Key Usage** の違いは?

**Key Usage** (KU) = この鍵で何ができるか (デジタル署名 / 鍵暗号化 / CRL 署名など 9 種類のビットフラグ)。**Extended Key Usage** (EKU) = この cert を使う **アプリケーション** (TLS server / TLS client / コード署名 / E-mail 保護など、OID で識別)。一般的な **TLS サーバー cert** は KU = `digitalSignature + keyEncipherment`、EKU = `serverAuth (1.3.6.1.5.5.7.3.1)` + (オプション) `clientAuth (...3.2)`。本ツールは EKU の **主要 OID 9 種類を人間可読ラベルで表示** + 未知 OID も OID として表示。

**Basic Constraints の `CA: TRUE`** って何ですか?

**Certificate Authority (CA) フラグ** = この cert が **他の cert に署名できる** ことを示します。**ルート CA** や **中間 CA** は `CA: TRUE`、**サーバー / クライアント cert** は `CA: FALSE` (本ツールのサンプル証明書も `FALSE` ですが省略表示)。**Path Length** = ルートから何階層の中間 CA を許可するか (0 = 直接の End Entity しか署名できない)。

**SKI / AKI** (Subject Key Identifier / Authority Key Identifier) は?

**SKI** = この cert の **公開鍵を識別する 20 バイトハッシュ** (通常 SHA-1)。**AKI** = この cert を **署名した CA の SKI**。**SKI と AKI の一致** で **チェーンを機械的に紐付け** できます (Subject DN マッチより堅牢)。Let's Encrypt や DigiCert などの CA はすべて記載。古い自己署名 cert では省略されることもあります。

**OpenSSL コマンド** で同じ情報を見るには?

**`openssl x509 -in cert.pem -text -noout`** = フル情報、**`-fingerprint -sha256`** = SHA-256 fingerprint、**`-dates`** = 有効期限、**`-subject -issuer`** = DN、**`-ext subjectAltName`** = SAN。本ツールはこれらを **1 画面で見やすく** 集約したもの。OpenSSL を持っていない / すぐ確認したい時に。

jwt-decode / jwt-verify との関係は?

**jwt-decode**: JWT (`xxx.yyy.zzz`) のペイロード + ヘッダを表示 (署名検証なし)。**jwt-verify**: JWT を **公開鍵 PEM** で署名検証。**pem-parse** (本ツール): その **PEM 自体** の中身 (Subject / SAN / 有効期限など) を表示。**JWT 署名検証用の公開鍵を確認** したい時に併用するのがおすすめ。

開発へ戻る

X.509 PEM 証明書パーサー — SSL/TLS 証明書を解析・有効期限チェック

**`-----BEGIN CERTIFICATE-----`** で囲まれた **X.509 PEM 証明書** を貼り付けると、**Subject** (CN / O / OU / C / ST / L / EMAIL)、**Issuer** (発行者)、**有効期限** (Not Before / Not After / 残り日数 + 失効バッジ)、**シリアル番号**、**署名アルゴリズム** (RSA-SHA256 / ECDSA-SHA384 等)、**公開鍵タイプ** (RSA 2048 / EC P-256 等)、**SHA-1 / SHA-256 フィンガープリント**、**SAN** (DNS / IP / Email / URI)、**Key Usage** / **Extended Key Usage**、**Basic Constraints** (CA フラグ / Path Length)、**SKI / AKI** を解析します。**チェーン (複数 cert)** も連結貼付で一覧表示。SSL/TLS 証明書のトラブルシューティング、有効期限監視、SAN の DNS 一致確認、Let's Encrypt 自動化のデバッグに。**完全にブラウザ内** で処理 (@peculiar/x509 + Web Crypto API)、証明書はサーバーに送信されません。

開発セキュリティ

使い方

**入力欄** に `-----BEGIN CERTIFICATE-----` で始まる **X.509 PEM 証明書** を貼り付けて **解析** を押すと、Subject / Issuer / 有効期限 / SAN / Key Usage / EKU / 公開鍵タイプ / 署名アルゴリズム / SHA-1 + SHA-256 フィンガープリント / SKI + AKI が一覧で表示されます。**複数の PEM ブロック** (証明書チェーン) を連結して貼ると **チェーン全体** をカード単位で解析します。**サンプル** ボタンで Let's Encrypt 風の自己署名サンプル証明書 (`*.nosend-tools.com`、有効期限 2026-01-01〜2027-04-01) を流し込み可能。各フィンガープリントとシリアル番号は **ワンクリックでクリップボードコピー**。

詳細解説

証明書・秘密鍵は、情報資産の中でも最高クラスの機密

X.509 PEM 証明書には、ドメインの所有権を証明する公開鍵とその署名情報が含まれており、組み合わせる秘密鍵は TLS 通信全体の信頼の根幹を担います。証明書単体でも Subject / SAN に記載されたドメイン名、Issuer に記載された CA 名、有効期限、フィンガープリントは内部インフラの構成情報を直接的に反映します。内部 PKI が発行したクライアント証明書であれば、Subject の CN や OU に社員名・部署・システム名が入っており、組織構造が読み取れます。

さらに誤操作で -----BEGIN RSA PRIVATE KEY----- や -----BEGIN OPENSSH PRIVATE KEY----- が含まれるバンドルファイルをそのまま貼り付けてしまうリスクがあります。秘密鍵は一度外部に渡ると、対応するすべての TLS 通信を復号できる状態になります。「PEM を確認したかっただけ」という操作が、最悪の場合サーバーの完全な成りすまし許可を意味します。

「証明書確認オンライン」サイトに貼り付けることの構造的なリスク

証明書のデコードや有効期限確認を提供するオンラインツールは多数存在しますが、その大半は広告・トラッカー・行動分析 SDK を複数抱えています。入力フォームに貼り付けたデータをサーバー側でログに残す設計かどうかは、外見から判断できません。利用規約に「入力内容をサービス改善に使用する」と書かれているケースもあります。

問題は「貼り付けた直後に秘密鍵が含まれていたと気づく」という事故の構造です。証明書と秘密鍵が混在した PEM バンドル (例: nginx や HAProxy で使う fullchain+key.pem) を確認しようとして、そのままオンラインフォームに貼り付けると、秘密鍵が外部サーバーに到達します。これは「慌てて閉じた」では取り消せない情報漏えいです。

@peculiar/x509 と Web Crypto API がブラウザ内で担う仕事

このツールは PEM の Base64 をデコードして DER バイト列に戻し、ASN.1 構造を @peculiar/x509 (MIT ライセンス) でパースします。OID のデコード、SAN の各エントリタイプ (DNS / IP / Email / URI) の識別、Key Usage / Extended Key Usage のビットフラグ解釈、Basic Constraints の CA フラグ抽出、SKI / AKI の取り出しまですべてクライアントサイドで実行されます。SHA-1 / SHA-256 フィンガープリントの計算はブラウザ組み込みの Web Crypto API (crypto.subtle.digest) で行うため、外部ライブラリへの依存もありません。

処理はすべてページのメモリ内で完結し、ネットワーク経路にデータが出ることはありません。DevTools の Network タブを開きながら証明書を貼り付けて解析ボタンを押しても、追加のリクエストは一切発生しません。-----BEGIN PRIVATE KEY----- や -----BEGIN RSA PRIVATE KEY----- で始まるブロックを検出した場合は解析を中断してエラーを出す設計にしており、誤操作で秘密鍵を処理する経路を持ちません。

証明書を共有する前・設定する前のチェックリストとして

TLS 証明書をサーバーに設定する前、あるいはクライアント証明書を配布する前に、このツールで SAN の DNS 名がホスト名と一致しているか、有効期限が意図した期間になっているか、Key Usage / Extended Key Usage が用途に合っているか (Web サーバーなら serverAuth、クライアント認証なら clientAuth) を一括確認しておくと、設定ミスを事前に発見できます。フィンガープリントをコピーして管理台帳や監視ツールに登録する際も、ここから直接クリップボードにコピーする流れが最もミスが少ない方法です。同じ証明書で署名された JWT の中身を確認したい場合は jwt-decode を、署名検証は jwt-verify を続けて使えます。

PEM / DER / ASN.1 と X.509 v3 拡張の解釈

PEM (RFC 7468) は DER バイト列を Base64 でラップし、-----BEGIN ...----- / -----END ...----- のヘッダー行で囲んだテキスト形式です。中身の DER は ITU-T X.690 で定義された ASN.1 の Distinguished Encoding Rules に従う TLV (Tag-Length-Value) のネストで、X.509 証明書全体は RFC 5280 が定義する Certificate ::= SEQUENCE { tbsCertificate, signatureAlgorithm, signature } という構造になります。tbsCertificate の中に Subject / Issuer (Name ::= RDNSequence)、Validity ::= SEQUENCE { notBefore Time, notAfter Time }、SubjectPublicKeyInfo、そして v3 拡張群が並びます。

このツールが表示する SAN は v3 拡張 id-ce-subjectAltName (OID 2.5.29.17) の GeneralName を dNSName / iPAddress / rfc822Name / uniformResourceIdentifier のタグごとに分類した結果です。KeyUsage (OID 2.5.29.15) はビットフラグで digitalSignature / keyEncipherment / keyCertSign などを符号化し、ExtendedKeyUsage (OID 2.5.29.37) は serverAuth (1.3.6.1.5.5.7.3.1) や clientAuth (1.3.6.1.5.5.7.3.2) などの OID 列で用途を示します。BasicConstraints の cA フィールドが TRUE であれば中間 / ルート CA、FALSE またはこの拡張自体が欠落していればエンドエンティティ証明書です。

CA / Baseline Requirements と運用上の落とし穴

公的に信頼される TLS 証明書は CA/Browser Forum の Baseline Requirements に従って発行されており、2020 年 9 月以降は最長有効期間が 398 日に制限されています。notAfter - notBefore > 398 days の証明書はパブリック CA からは発行できず、もし手元にあれば内部 PKI 発行か古い時代のものです。さらに 2024-2025 年にかけて 200 日台 → 100 日台への段階的短縮が議論されており、長期固定運用の前提は崩れつつあります。Let’s Encrypt は元から 90 日なので自動更新前提です。

実運用での頻出ミスは、(1) SAN に www. ありの FQDN だけ入っていてベアドメインで TLS エラーが出る、(2) ワイルドカード *.example.com が 1 階層しかカバーしないため a.b.example.com で失敗する、(3) チェーン中間証明書が不足していて unknown issuer 扱いになる、(4) 古いブラウザ / Java クライアントが SHA-1 署名を拒否するのに SHA-1 のままで運用している、の 4 つです。本ツールでチェーン全体の Subject ↔ Issuer の連結を目視確認し、Authority Key Identifier (AKI) と発行元の Subject Key Identifier (SKI) が一致しているかを確認することで、これらは事前に検出できます。なお Common Name (CN) ベースのホスト名照合は RFC 2818 / 6125 で deprecated になっており、現代のクライアントは SAN のみを見るため、CN だけで SAN がない証明書は発行できません。

よくある質問

入力データはサーバーに送信されますか?: いいえ。**@peculiar/x509** (MIT) と **Web Crypto API** (`crypto.subtle.digest`) を使ってブラウザ内 JavaScript ですべて処理します。外部 API も解析サーバーもありません。**社内の証明書や private 環境の cert** も安心して貼り付けられます。
対応している証明書フォーマットは?: **X.509 v3 / PEM (Base64) フォーマット** のみ。Let's Encrypt / DigiCert / GlobalSign / 各国 GPKI / 社内 PKI が標準的に発行する形式すべて。**DER (バイナリ)** や **PKCS#12 (.p12 / .pfx、秘密鍵入りバンドル)** は未対応 — 先に `openssl x509 -inform DER -in cert.der -out cert.pem` などで PEM に変換してください。
**チェーン (中間 CA + サーバー証明書)** は解析できますか?: はい。**`-----BEGIN CERTIFICATE-----` ブロックを連続して** 貼ると順に解析して **チェーン全体** を表示します。`openssl s_client -connect nosend-tools.com:443 -showcerts` の出力を **そのまま貼って** OK。各証明書ごとに Subject + Issuer + 有効期限が出るので、**Issuer == 次の証明書の Subject** をたどれば順序の正しさを確認できます。
**有効期限のチェック** はどう判断していますか?: **現在のブラウザ時刻 (`new Date()`) と `notBefore` / `notAfter` を比較**。`now < notBefore` なら **`Not yet valid`** バッジ (まだ有効でない、テスト用 cert などで発生)、`now > notAfter` なら **`Expired`** バッジ。それ以外は **`Valid`** バッジ + **残り日数** を表示。**サーバーの時刻** ではなく **ブラウザの時刻** を使うので、PC 時計がズレているとズレた判定になります。SSL 監視には ssl-checker 系の外部サービスも併用してください。
**SAN (Subject Alternative Names) と DNS の一致** はどう確認しますか?: 本ツールは SAN の **タイプ (DNS / IP / Email / URI)** と **値** を一覧表示します。実際の DNS マッチング (`*.nosend-tools.com` がワイルドカードで一致するか等) は **ブラウザがその場で確認** するので、本ツールではしません。**`Subject CN`** ではなく **`SAN DNS`** が現代の TLS では優先 (RFC 6125)、CN だけで SAN が空の cert はブラウザによっては警告。
**SHA-1 と SHA-256 フィンガープリント** はどっちを使うべき?: **SHA-256** を推奨 (現代の標準、衝突攻撃に強い)。**SHA-1** は古いシステムの **pinning** や **ログ照合** で互換性のために残ってますが、新規システムには使わないでください。両方を `AA:BB:CC:...` のコロン区切り 16 進形式で表示 (OpenSSL / Chromium / Firefox 互換)。
**Key Usage** と **Extended Key Usage** の違いは?: **Key Usage** (KU) = この鍵で何ができるか (デジタル署名 / 鍵暗号化 / CRL 署名など 9 種類のビットフラグ)。**Extended Key Usage** (EKU) = この cert を使う **アプリケーション** (TLS server / TLS client / コード署名 / E-mail 保護など、OID で識別)。一般的な **TLS サーバー cert** は KU = `digitalSignature + keyEncipherment`、EKU = `serverAuth (1.3.6.1.5.5.7.3.1)` + (オプション) `clientAuth (...3.2)`。本ツールは EKU の **主要 OID 9 種類を人間可読ラベルで表示** + 未知 OID も OID として表示。
**Basic Constraints の `CA: TRUE`** って何ですか?: **Certificate Authority (CA) フラグ** = この cert が **他の cert に署名できる** ことを示します。**ルート CA** や **中間 CA** は `CA: TRUE`、**サーバー / クライアント cert** は `CA: FALSE` (本ツールのサンプル証明書も `FALSE` ですが省略表示)。**Path Length** = ルートから何階層の中間 CA を許可するか (0 = 直接の End Entity しか署名できない)。
**SKI / AKI** (Subject Key Identifier / Authority Key Identifier) は?: **SKI** = この cert の **公開鍵を識別する 20 バイトハッシュ** (通常 SHA-1)。**AKI** = この cert を **署名した CA の SKI**。**SKI と AKI の一致** で **チェーンを機械的に紐付け** できます (Subject DN マッチより堅牢)。Let's Encrypt や DigiCert などの CA はすべて記載。古い自己署名 cert では省略されることもあります。
**OpenSSL コマンド** で同じ情報を見るには?: **`openssl x509 -in cert.pem -text -noout`** = フル情報、**`-fingerprint -sha256`** = SHA-256 fingerprint、**`-dates`** = 有効期限、**`-subject -issuer`** = DN、**`-ext subjectAltName`** = SAN。本ツールはこれらを **1 画面で見やすく** 集約したもの。OpenSSL を持っていない / すぐ確認したい時に。
jwt-decode / jwt-verify との関係は?: **jwt-decode**: JWT (`xxx.yyy.zzz`) のペイロード + ヘッダを表示 (署名検証なし)。**jwt-verify**: JWT を **公開鍵 PEM** で署名検証。**pem-parse** (本ツール): その **PEM 自体** の中身 (Subject / SAN / 有効期限など) を表示。**JWT 署名検証用の公開鍵を確認** したい時に併用するのがおすすめ。

「送らない」を確かめるには

このツールは入力データを外部に送信しません。仕組み・監査手順・運営方針は以下で詳しく説明しています。

類似のツール

JWT デコード — header / payload を可読化

JWT を貼り付けて Header / Payload / Signature に分解。exp / iat / nbf などの数値クレームは人間可読な日時に変換して表示。署名検証は行いません (内容確認専用)。すべてブラウザ内で処理。

開発JWTデコード

JWT 署名検証 — HMAC / RSA / ECDSA 対応

WebCrypto で JWT の署名を検証します。HS / RS / PS / ES の各 SHA-256/384/512 に対応。HMAC は共通鍵文字列、RSA / ECDSA は SPKI 形式の PEM 公開鍵か JWK を入力するだけ。exp / nbf もあわせてチェックします。鍵もトークンもサーバへ送信されません。

開発JWTセキュリティ

ハッシュ生成 — SHA-1 / 256 / 384 / 512

テキストから SHA-1 / SHA-256 / SHA-384 / SHA-512 のハッシュ値を一括生成します。Web Crypto API ベースでブラウザ内処理。

開発ハッシュ生成

ZIP アーカイブ内容ビューア

ZIP ファイルをドロップして、解凍せずに中身を一覧表示します。総ファイル数・全体サイズ・圧縮率・アーカイブコメントに加え、各エントリのパス・圧縮前後のサイズ・圧縮方式 (Stored/Deflate/Deflate64/BZIP2/LZMA/Zstandard)・最終更新日時・CRC32・暗号化フラグ・ディレクトリ判定を表示。Central Directory だけを読む自前パーサで動作するため、ファイルの中身データは展開せず、サーバーにも送信されません。

開発抽出