TLS Certificate Checker

サイトのTLS/SSL証明書をチェック：サブジェクト/発行者、有効期限、SAN、チェーンの完全性、一般的なHTTPS設定ミス。オプションでリダイレクトを追跡し、最終到達先が有効な証明書を持つHTTPSであることを確認。JSON/PDFレポートをエクスポート。

Loading…

概要 TLS証明書チェッカー

HTTPSが壊れると、ユーザーは恐ろしい警告を見て、ボットはサイトを信頼しなくなります。このツールはURLを取得し、オプションでリダイレクトを追跡し、最終HTTPSエンドポイントを保護するTLS証明書を検査します。期限切れ間近の証明書、不完全なチェーン、ホスト名/SANの不一致、ブラウザエラーやSEO/可用性の問題を引き起こすその他の一般的な問題を発見するのに役立ちます。

機能

  • 証明書のサブジェクトと発行者を検査（誰のため、誰が発行したか）。
  • 日付を検証：notBefore / notAfter、期限切れ間近の警告。
  • SAN（サブジェクト代替名）とホスト名カバレッジ（www vs エイペックス、サブドメイン）をチェック。
  • 証明書チェーンの問題を検出（中間証明書の欠落 / 不完全なチェーン）。
  • オプションでリダイレクトを追跡し、最終URLのHTTPS強制を検証。
  • 一般的なHTTPSの落とし穴を特定（間違ったホスト、間違った証明書、混合リダイレクトフロー）。
  • インシデントチケット用のコピーしやすい結果と所見。
  • ドキュメントと回帰チェック用のJSONおよびPDFレポートをダウンロード。

🧭 使い方 for tls-certificate-checker

1

テストするURLを貼り付け

ターゲットURLを入力します。https://example.com を貼り付けるか、最終的にHTTPSにアップグレードすることを確認したい場合は http://example.com でも構いません。

2

実際の動作を確認するために「リダイレクトを追跡」を有効化

ユーザーやクローラーが実際に到達する宛先（http→https、非www→www）を検証したい場合は、リダイレクト追跡を有効にしてください。

3

チェックを実行して概要を確認

重要な項目を確認：有効期限、ホスト名/SANの一致、チェーンが完全かどうか。

4

所見を検査し根本原因を修正

警告（期限切れ間近、不一致、不完全なチェーン）が表示された場合は、TLS終端レイヤー（CDN、リバースプロキシ、ロードバランサー、またはウェブサーバー）で修正してください。

5

追跡用にJSON/PDFをエクスポート

レポートをダウンロードして、運用/SEOチケットに添付したり、前後のスナップショットを保存したりします。

技術仕様

入力と操作

このツールはURLをチェックし、解決されたHTTPSエンドポイントのTLS証明書を検査します。

機能詳細
対応URL形式HTTPまたはHTTPS URL（リダイレクト追従は有効化可能）。
リダイレクト処理オプション。有効時、設定された最大リダイレクト数まで追従します。
TLS焦点証明書のプロパティと一般的な設定ミスを検査します。

デフォルトと制限

フェッチと安全性のデフォルトは、予測可能な動作に調整されています。

設定値
リダイレクトを追従有効
最大リダイレクト数10
タイムアウト15000 ms
ユーザーエージェントEncode64Bot/1.0 (+https://encode64.com)
プライベートネットワーク許可されていません

検査対象

検査は、本番環境で最も頻繁に発生する障害（有効期限切れ、ホスト名不一致（SANカバレッジ）、チェーン完全性）を中心に設計されています。リダイレクト追従は、HTTPSが最終的な正規ホストでのみ有効なケースを捕捉するのに役立ちます。

有効な証明書は強固なセキュリティに必要ですが、それだけでは十分ではありません。堅牢なデプロイメントのためには、HSTSとセキュリティヘッダーの監査と併用してください。

コマンドライン

OpenSSLとcurlを使用して、自身のターミナルから証明書の詳細を確認し、ツールの報告と比較してください。

macOS / Linux

ホストの証明書チェーン（SNI）を表示

echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null

提示されたリーフ証明書と中間チェーンを検査するのに有用です。

有効期限を素早く抽出

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

notBefore / notAfterを出力します。

SANを一覧表示

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

証明書がカバーするホスト名を表示します。

HTTPからHTTPSへのリダイレクトを検証

curl -I http://example.com

Locationヘッダーと最終的なスキームを確認します。

リダイレクトを追従して最終URLを表示

curl -IL http://example.com | sed -n '1,120p'

リダイレクトチェーンや非正規エンドポイントの検出に役立ちます。

バーチャルホストサーバー/CDNでは、openssl s_clientを使用する際は常に-servernameオプションを指定してください。SNIがないと、誤った証明書が返される可能性があります。

ユースケース

証明書の期限切れ障害を防止

有効期限が近づいている証明書を特定し、ユーザーやボットがブラウザエラーに遭遇する前に更新できます。

  • 週次の証明書健全性チェック
  • DNSやCDN変更後のドメイン監査

不完全な証明書チェーン問題を修正

古いクライアントや一部のクローラーで問題を引き起こす、中間証明書の欠落（カスタムサーバー設定でよく発生）を検出します。

  • Nginx/Apacheのチェーンバンドル設定ミス
  • ロードバランサーの中間証明書欠落

ホスト名/SAN不一致のデバッグ（wwwとapex）

証明書が、www/非wwwやサブドメインを含む、ユーザーがアクセスする正確なホストをカバーしていることを確認します。

  • apexドメインは動作するがwwwでエラー
  • SANリストにAPIサブドメインが含まれていない

リダイレクトによるHTTPS強制の検証

http URLが有効な証明書を持つ正規のhttpsエンドポイントにリダイレクトされていることを確認します。

  • http→httpsへの301リダイレクト
  • 非www→wwwへの正規化

❓ Frequently Asked Questions

❓HTTPSが有効でも、ブラウザが「証明書が信頼されていません」と表示するのはなぜですか？

一般的な原因は、証明書の期限切れ、不完全なチェーン（中間証明書の欠落）、ホスト名不一致（SANにホストが含まれていない）、またはSNI/バーチャルホスト設定ミスによる誤った証明書の提供です。

❓SANとは何ですか？なぜ重要ですか？

SAN（Subject Alternative Names）は、証明書が有効なホスト名のリストです。サイトがexample.comとwww.example.comの両方でアクセスされる場合、証明書は両方をカバーする必要があります（または、カバーされているホストに一貫してリダイレクトする必要があります）。

❓httpがhttpsにリダイレクトされるのは問題ありませんか？

はい、推奨される方法です。最終的なHTTPS先が有効な証明書を提示し、リダイレクトチェーンが短く一貫していることを確認してください（正規リダイレクトには301を推奨）。

❓このツールはTLSバージョン/暗号をチェックしますか？

このツールは証明書の検査と一般的な設定ミスに焦点を当てています。プロトコル/暗号の強化（TLS 1.2/1.3、脆弱な暗号）については、専用のTLS設定スキャナーを使用してください。

❓リーフ証明書、中間証明書、ルート証明書の違いは何ですか？

リーフ証明書はサイトの証明書です。中間証明書はそれを信頼されたルートCAにリンクします。ブラウザはルートを信頼するため、中間証明書が欠落していると有効な信頼チェーンを構築できません。

Pro Tips

Best Practice

証明書は早期に更新し、可能な限り自動更新（ACME）を設定しましょう。

Best Practice

SAN（サブジェクト代替名）に公開するすべてのホスト名（www、apex、APIサブドメイン等）を含めるか、リダイレクトで単一の正規ホストを強制しましょう。

Best Practice

常に完全な証明書チェーン（リーフ証明書＋中間証明書）を提供しましょう。移行後の不完全なチェーンバンドルによる障害が多く発生しています。

Best Practice

リダイレクトを有効にする場合は最小限に留め、正規のHTTPS URLへの1回のホップが理想的です。

Best Practice

有効なTLSにHSTSとセキュリティヘッダーを組み合わせて、実環境での保護を強化しましょう。

Additional Resources

OpenSSL s_client ドキュメント
Documentation
RFC 5280: Internet X.509公開鍵基盤証明書およびCRLプロファイル
Documentation
Let's Encrypt: 証明書の基礎
Documentation

Other Tools