SSL証明書チェッカー
任意のドメインの SSL 証明書をすぐに確認できます。有効期限、発行者、信頼状態、証明書チェーンをまとめて表示。無料、ログイン不要。
SSL証明書の結果の見方
結果の各項目は、証明書について異なる意味を持ちます。ここでは各情報の意味と、確認すべきポイントを説明します。
発行者 (CA名)
証明書に署名し発行した組織です。Let's Encrypt、DigiCert、Sectigo、GlobalSign などの著名な CA であるべきです。発行者とサブジェクトの CN と O が同一なら、その証明書は自己署名であり、ブラウザーは警告を表示します。
Subject Alternative Names (SAN)
この証明書が有効なドメインとサブドメインの一覧です。本番環境では apex ドメインと www の両方が含まれているか確認してください。ワイルドカード (*.example.com) は第 1 レベルのサブドメインをカバーしますが、apex や第 2 レベルのサブドメインは対象外です。
有効期限とカウントダウン
この日付を過ぎると証明書は無効になります。カウントダウンバーは、残り 30 日超で緑、8〜30 日で黄、7 日未満で赤に変わります。Let's Encrypt は 90 日証明書、商用証明書は通常 1 年です。
TLS プロトコルバージョン
サーバーがこの接続で実際にネゴシエートした TLS バージョンです。TLS 1.3 は現在の標準で、より高速かつ安全です。TLS 1.2 も許容範囲です。TLS 1.0 と 1.1 は非推奨のため無効化すべきで、SSLv3 と SSLv2 には重大な脆弱性があります。
シリアル番号
CA がこの証明書に割り当てた一意の識別子です。証明書管理、OCSP stapling の確認、同一ドメインに複数の証明書がある場合のインシデント追跡に役立ちます。
SHA-256 フィンガープリント
証明書全体の内容に対する暗号学的ハッシュです。同じフィンガープリントは同一の証明書を意味します。証明書ローテーションの前後で比較すれば、更新が正しく反映されたか、予期しない証明書差し替えがないか確認できます。
証明書失効時の対応ガイド
SSL 障害で最も多い原因は証明書の失効です。残り日数に応じて、取るべき対応をこの表で確認できます。
| 失効までの日数 | ステータス | 推奨アクション |
|---|---|---|
| > 30日 | 正常 | 対応は不要です。残り 30 日の時点で更新リマインダーを設定してください。 |
| 8〜30日 | 要注意 | 今すぐ更新手続きを開始してください。多くの CA や自動更新サービス (Let's Encrypt、Certbot) は残り 30 日で更新を実行します。 |
| 1〜7日 | 緊急 | 直ちに更新してください。証明書が失効するとブラウザーエラーが発生し、すべての HTTPS 通信が遮断されます。 |
| 0日以下 | 期限切れ | 証明書はすでに失効しています。直ちに交換してください。サイトの訪問者全員にセキュリティエラーが表示されている状態です。 |
Chrome / Firefox / Safari でよくある SSL エラー — 原因と対処
ブラウザーでよく表示される SSL エラーと、その意味をまとめました。このツールで根本原因を特定し、適切な対処を行ってください。
証明書の valid_to 日付が過去になっています。証明書はすでに失効しており、ブラウザーに信頼されるには更新が必要です。
CA またはホスティング事業者経由で証明書を更新してください。自動更新が正しく設定されているか確認しましょう。多くの CA は失効の 30 日前から自動更新します。
ブラウザーのアドレスバーに表示されるドメインが、証明書の CN または SAN に含まれていません。ドメイン移行、サブドメイン不一致、誤ったドメイン向けに発行された証明書でよく起こります。
正しいドメインを含めて証明書を再発行してください。apex ドメイン (example.com) と www サブドメイン (www.example.com) の両方が SAN 一覧に含まれているか確認しましょう。
証明書が、ブラウザーまたは OS の信頼ストアに含まれていない CA によって発行されています。自己署名証明書、社内 CA で発行した証明書、中間 CA がチェーンから欠落した証明書がこれに該当します。
公開信頼ストアで信頼される CA の証明書を使用してください。社内 CA を使う場合は、クライアント側の信頼ストアにルート証明書をインストールします。また、サーバーが中間証明書チェーンを完全に送信していることを確認してください。
証明書が発行元 CA によって明示的に失効させられています。通常は秘密鍵の漏えい、ドメイン所有者の変更、または誤発行が原因です。
直ちに新しい証明書を取得してください。自分で失効させた覚えがない場合は、秘密鍵が漏えいしている可能性があります。鍵をローテーションし、証明書を再発行し、漏えい範囲を調査してください。
サーバーが HTTPS ポートで HTTP 応答を返しているか、TLS ハンドシェイク完了前にプロキシが HTTP エラーを返しています。443 番ポートが TLS ではなく平文を受け取っている状態です。
接続先ポートで TLS を提供するようサーバーが設定されているか確認してください。ロードバランサーやプロキシの設定を見直し、SSL 終端が正しく構成されていることを確認します。
クライアントとサーバーが TLS バージョンまたは暗号スイートで合意できていません。サーバーが TLS 1.0 / 1.1 しかサポートしていない場合 (Chrome 84+、Firefox 74+、Safari 14+ では非推奨) や、現行ブラウザーから削除された暗号スイートを使っている場合によく発生します。
サーバーで TLS 1.2 と TLS 1.3 を有効にし、TLS 1.0 と TLS 1.1 は無効化してください。RC4、3DES、export-grade cipher を削除するよう暗号スイート一覧を更新し、Nginx や Apache の設定には Mozilla の TLS configuration generator を利用してください。
SSL証明書の確認方法 (3ステップ)
ドメインを入力
入力欄に github.com や api.example.com などのドメイン名を入力します。https:// のプレフィックスは自動で削除されます。HTTPS サービスが既定の 443 番ポート以外で動作している場合は、カスタムポートも指定できます。
証明書を確認
数秒で、有効期限とカウントダウン、証明書チェーン、信頼状態、プロトコルバージョン (TLS 1.2 または 1.3)、暗号スイート、SAN、SHA-256 フィンガープリントを確認できます。データは保存されません。
結果を読む
証明書が期限切れ、自己署名、またはホスト名不一致の場合は、結果に問題が明確に表示されます。有効期限バーは残り 30 日以内で黄色、7 日以内で赤になります。詳細は 1 クリックでコピーできます。
SSL証明書でわかること
SSL/TLS 証明書は、Web サイトの身元を証明し、暗号化通信を可能にするデジタル証明書です。HTTPS でサイトにアクセスすると、ブラウザーは暗号化チャネルを確立する前に、信頼された Certificate Authority (CA) が発行した証明書を検証します。有効な証明書がなければ、ブラウザーはセキュリティ警告を表示し、アクセスをブロックすることがあります。これはユーザーの信頼や検索順位に直接影響します。
すべての SSL 証明書には 3 つの重要な情報が含まれます。
- •サブジェクト — 証明書が発行されたドメイン名 (OV/EV では組織名も含む)
- •発行者 — 証明書に署名し検証した Certificate Authority (CA)
- •有効期間 — 証明書が信頼される正確な開始日と終了日
このツールで確認しないこと
このツールは TLS ハンドシェイクを実行して証明書を読み取りますが、次の項目は確認しません。
- 暗号スイートの強度評価 (A–F) — 完全な TLS 監査には SSL Labs を利用してください
- HSTS ヘッダーや preload list の状態確認
- OCSP stapling 設定の検証
- 証明書ピンニング (HPKP) の検出
- HTTP から HTTPS へのリダイレクト挙動の確認
SSL証明書の種類
証明書の種類によって、確認される身元情報のレベルが異なります。違いは暗号化強度ではなく、発行者が署名前に何を検証したかにあります。
CA は申請者がドメインを管理していることだけを確認し、企業実体までは確認しません。自動化された DNS または HTTP チャレンジにより数分で発行されます。ブログ、個人サイト、社内ツールに適しています。サブジェクトには通常 CN (ドメイン名) のみが表示され、O (組織) フィールドはありません。
CA はドメインの管理権に加え、組織の法的実在性も検証します。通常 1〜3 営業日かかります。証明書の O フィールドに会社名が表示されるため、訪問者は証明書の詳細から運営主体を確認できます。企業サイトや API に適しています。
最も厳格な検証方式で、CA はドメイン、組織、所在地、法的地位、事業実在性まで確認します。以前はブラウザーのアドレスバーに緑色表示を出すことで知られていました。現在は証明書詳細に会社名が表示されます。金融機関や決済データを扱う EC プラットフォームでよく利用されます。
CN または SAN に *.example.com パターンを使うことで、ルートドメインと第 1 レベルのサブドメインをカバーできます。1 枚のワイルドカード証明書で www.example.com、api.example.com、cdn.example.com などを保護できます。ただし dev.api.example.com のような第 2 レベルのサブドメインは対象外で、別の証明書が必要です。
1 枚の証明書で、Subject Alternative Name 拡張を使って複数の異なるドメインをカバーできます。example.com、example.io、app.example.net など、複数の製品を 1 枚の証明書で運用するケースで一般的です。現在の証明書の多くは単一ドメインでも SAN を使用し、CN は SAN 一覧にも反映されます。
SSL証明書を確認すべきタイミング
導入前
証明書が本番公開する正確なドメインをカバーしているか確認します。DNS を本番環境に向ける前に、発行者が信頼された CA であること (自己署名ではないこと)、SAN に www と apex の両方が含まれていること、プロトコルが TLS 1.2 以上であることを確認してください。
証明書更新の監視
有効期限は早めに確認しましょう。Let's Encrypt 証明書は 90 日ごとに失効するため、自動更新に失敗すると障害につながります。商用証明書は通常 1 年有効です。このツールをブックマークして、残り 30 日未満の証明書を毎月確認してください。
セキュリティ監査
TLS 1.0 / 1.1、弱い暗号スイート、自己署名証明書をまだ使っているサーバーを特定できます。証明書ローテーション後は、SHA-256 フィンガープリントを想定値と照合し、MITM による差し替えが起きていないか確認してください。
ドメイン移行後
ドメインを新しいホストや CDN に移行した後は、新しい証明書が対象ドメインをカバーしているか、発行者が正しいか、SAN が想定どおりかを確認します。古いサーバーに証明書が残り、新しいサーバーに設定されていないと、DNS が正しくてもブラウザーエラーが発生します。