SSLエラーとは？閲覧者・サイト運営者別の直し方

SSLエラーとは、ブラウザがHTTPS接続を始める際に、証明書や暗号化通信を安全に検証できなかったことを示す警告です。現在のHTTPSでは主にTLSが使われますが、ブラウザやサーバー管理画面では「SSLエラー」「SSL証明書」という名称が残っています。SSLとTLSの違いや通信の仕組みは、LUFTMEDIAのSSLとTLSの違いとは？HTTPSの仕組みを解説で確認できます。

警告の原因は、証明書の期限切れだけではありません。アクセスしたホスト名との不一致、中間証明書の不足、端末時刻のずれ、対応TLSバージョンの不一致、HTTPSページ内に残ったHTTP通信などがあります。閲覧者側で直せる場合と、サイト運営者しか直せない場合を分けて判断することが重要です。以下の画面名、操作順、仕様は、特記がない限り2026年10月15日時点です。

SSLエラーが表示されたときブラウザは何を検証できなかったのか？

ブラウザはページを表示する前にTLSハンドシェイクを行い、サーバーから提示された証明書を検証します。主な確認対象は、有効期間内か、開いているホスト名が証明書のSAN（Subject Alternative Name）に含まれるか、信頼済みルート認証局まで署名をたどれるか、サーバーと共通して利用できるTLSバージョンや暗号方式があるかです。

Chromeでは「この接続ではプライバシーが保護されません」とともに、NET::ERR_CERT_DATE_INVALID、NET::ERR_CERT_AUTHORITY_INVALID、ERR_CERT_COMMON_NAME_INVALIDなどが表示されます。Firefoxでは「警告: 潜在的なセキュリティリスクあり」または「安全な接続ができません」と表示され、SEC_ERROR_EXPIRED_CERTIFICATE、SEC_ERROR_UNKNOWN_ISSUER、SSL_ERROR_BAD_CERT_DOMAINなどで原因を区別できます。Microsoft EdgeもChromium系のエラーコードを表示する場合があります。

Google Chromeヘルプは、証明書、無効な名前、端末日時などに関するエラーを区別して案内しています。Firefoxでは警告ページの「詳細」からエラーコードを確認できます。エラーコード、発生日時、開いたURL、使用ブラウザ、同じ回線の別端末でも再現するかを記録すると、閲覧環境の問題かサイト全体の問題かを切り分けやすくなります。

なお、混在コンテンツは証明書そのものの検証失敗とは異なります。ページ本体のHTTPS接続は成立していても、内部のスクリプトやCSSなどをHTTPで取得しようとしたため、ブラウザが一部の通信を遮断している状態です。

最初に警告画面のエラーコードとURLを控えれば、証明書・端末・ページ内部の問題を混同せずに済みます。

期限切れ・ホスト名不一致・信頼チェーンをエラーコードからどう見分ける？

期限切れは、証明書の有効期間と現在時刻が一致しない状態です。ChromeのNET::ERR_CERT_DATE_INVALIDやFirefoxのSEC_ERROR_EXPIRED_CERTIFICATEが手掛かりになります。ただし、証明書が正常でも端末時刻が大きくずれていれば同種のエラーになるため、証明書と端末の両方を確認します。

ホスト名不一致は、アクセスした名前が証明書の対象外である状態です。例えば、証明書がexample.jpだけを対象とし、www.example.jpがSANに含まれていなければ、www側で警告が出ます。*.example.jpというワイルドカード証明書も、通常はshop.example.jpのような1階層には使えても、dev.shop.example.jpまで一律に対象とするものではありません。ChromeのERR_CERT_COMMON_NAME_INVALID、FirefoxのSSL_ERROR_BAD_CERT_DOMAINを確認します。

信頼チェーンのエラーは、サーバー証明書から中間認証局、端末が信頼するルート認証局まで署名をたどれない場合に起きます。Firefoxの証明書警告コードの公式解説は、SEC_ERROR_UNKNOWN_ISSUERについて、サーバーが適切な中間証明書を送っていない可能性を挙げています。社内プロキシやセキュリティソフトによるTLS検査が独自の証明書へ差し替えているケースでは、MOZILLA_PKIX_ERROR_MITM_DETECTEDが表示されることもあります。

ブラウザの証明書表示では、「有効期限」「発行先またはSubject Alternative Name」「発行者」を確認します。2026年10月15日時点のEdgeでは、開発者ツールを開いて「Security」→「Security Overview」→「View certificate」からメインオリジンの証明書を確認できます。通常のサイト情報メニューはブラウザ更新で配置が変わることがあるため、見つからない場合は開発者ツールを利用します。

一つの端末だけで不明な発行者になる場合は端末の証明書ストアやTLS検査を疑い、複数の端末・回線・ブラウザで同じエラーが出る場合はサーバー側の証明書配置を優先して調べます。

「期限」「アクセス中のホスト名」「発行者からルートまでの連鎖」を別々に確認するのが近道です。

閲覧者はChrome・Firefox・Edgeでどの順番に安全確認する？

閲覧者が警告を見たときは、警告を迂回する前に、次の順で原因を絞ります。

1. アドレスバーのURLを見て、綴り、サブドメイン、wwwの有無が目的のサイトと一致するか確認します。メールやメッセージ内のリンクなら、組織の公式アプリや検索結果ではなく、保存済みの正規URLや公式案内から開き直します。
2. ログイン、購入、決済、個人情報入力を止めます。警告ページに「詳細設定」「危険性を承知で続行」相当の項目があっても、原因を確認できない公開サイトでは進みません。HSTSが設定されたサイトなど、ブラウザ側で迂回できない場合もあります。
3. 同じURLを別の最新ブラウザ、別端末、モバイル回線などで開きます。すべてで再現すれば運営者側、特定端末だけなら日時、OS、プロキシ、セキュリティ製品を疑います。
4. 公衆Wi-Fiでは認証画面が未完了でないか確認します。Chrome公式は、Wi-Fiのログインポータルを開く方法としてHTTPページへのアクセスを案内しています。銀行やメールなどのサイトで警告を迂回して認証画面を探すのではなく、施設が指定した接続手順を使います。
5. ブラウザとOSを正式な更新機能で更新し、再起動します。Chromeは「メニュー」→「ヘルプ」→「Google Chromeについて」、Edgeは「設定など」→「ヘルプとフィードバック」→「Microsoft Edgeについて」、Firefoxは「メニュー」→「ヘルプ」→「Firefoxについて」が2026年10月15日時点の代表的な順路です。OSや配布形態で名称が異なる場合があります。
6. サイト運営者へ、URL、エラーコード、発生時刻、OS・ブラウザ名、他端末での再現有無を伝えます。警告画面に個人情報や社内URLが含まれる場合は、共有範囲を確認します。

証明書を手動で端末へインストールする操作は、一般の公開サイトを閲覧するための標準的な解決策ではありません。会社や学校が管理する端末で独自認証局を使う場合は、組織のIT管理者が指定した証明書と配布手順だけを利用します。自己判断でWeb上の証明書を追加すると、本来拒否すべき接続まで信頼するおそれがあります。

公開サイトの警告では入力を止め、URLと再現範囲を確認して運営者へ知らせるところまでにしましょう。

端末時刻・Wi-Fi・セキュリティソフトが原因ならOS別にどう直す？

端末時刻が実際とずれていると、有効な証明書を「まだ有効でない」「すでに失効した」と誤判定します。Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」とタイムゾーンを確認し、「今すぐ同期」を実行します。macOSでは「システム設定」→「一般」→「日付と時刻」、iPhone・iPadでは「設定」→「一般」→「日付と時刻」、Androidでは「設定」→「システム」→「日付と時刻」などを確認します。Androidはメーカーにより順路が異なります。これらの画面名は2026年10月15日時点です。

時刻がすぐ再びずれる場合は、端末の再起動、ネット接続、組織の時刻同期ポリシーを確認します。古いPCで電源を切るたび日時が初期化されるなら、ハードウェア保守が必要なこともあります。会社支給端末の時刻や証明書ストアを管理者権限で変更せず、IT管理者へ連絡してください。

ホテル、空港、店舗などのWi-Fiでは、接続後の利用規約同意や認証が完了していないため、別ページへの転送がHTTPS検証に阻まれる場合があります。施設の案内に従ってポータルを開き、改善しなければWi-Fiを切ってモバイル回線で試します。モバイル回線では正常なら、サイト証明書ではなくWi-Fi側の認証、DNS、通信検査が原因候補です。

特定端末だけで「不明な発行者」やMITM検出になる場合は、VPN、プロキシ、ペアレンタルコントロール、セキュリティソフトのHTTPS検査を確認します。ただし、保護機能を恒久的に無効化する案内は適切ではありません。個人端末なら製品の公式サポートで証明書更新や再設定を確認し、管理端末なら管理者へエラーコードを伝えます。機能を停止して原因確認する必要がある場合も、管理者の指示と限定された検証時間の下で行い、検証後に元へ戻します。

ブラウザのキャッシュ削除は、証明書の期限切れやホスト名不一致そのものを修復しません。別ブラウザやシークレットウィンドウで改善した場合に限り、拡張機能や保存状態を追加調査します。OSの証明書警告を消す目的で端末を初期化するのは、原因の範囲に比べて影響が大きいため先に行う操作ではありません。

端末だけで再現するなら、時刻同期、別回線、管理されたTLS検査の順に確認してください。

運営者は証明書の期限・SAN・中間証明書・SNIをどう確認する？

運営者は、まず利用者が実際に開くすべてのホスト名を列挙します。ルートドメイン、www、管理画面、API、サブドメイン、旧URL、CDN用ホスト名を含め、DNSのA・AAAA・CNAMEレコードがどこを向くか確認してください。DNSとURLの関係は、LUFTMEDIAのドメインとは？URL・DNSとの関係と取得後に行う設定でも整理できます。

ChromeまたはEdgeで対象URLを開ける環境では、サイト情報または開発者ツールの「Security」から証明書を表示し、有効期間、SAN、発行者を確認します。サーバーへ直接確認できる管理者は、openssl s_client -connect example.jp:443 -servername example.jp -showcertsを実行すると、SNIでホスト名を指定した状態の提示証明書とチェーンを確認できます。WindowsにOpenSSLがない場合は、無理に非公式配布物を導入せず、レンタルサーバーやCDNの管理画面、正式な管理環境を使用します。

中間証明書を手動設定する環境では、サーバー証明書だけでなく、認証局が指定した中間証明書を正しい順序で配信します。ルート証明書を代わりに配置すれば解決するとは限りません。Let’s Encryptは公式用語集で、証明書チェーンを、エンドエンティティ証明書から信頼済みルートへ結び付ける中間証明書の列として説明しています。古い中間証明書を固定した構成は、認証局側のチェーン変更時に問題になり得るため、ACMEクライアントやホスティング事業者の推奨構成を使います。

SNIは、TLS接続時にブラウザが接続先ホスト名を伝え、同じIPアドレス上の複数サイトから適切な証明書を選ぶ仕組みです。SNI設定や仮想ホストの紐付けを誤ると、別サイトの証明書が提示されてホスト名不一致になります。IISでは、2026年10月15日時点の代表的な順路として「IISマネージャー」→対象サイト→「バインド」→HTTPSバインドを開き、ホスト名、「Server Name Indicationを要求する」、証明書の選択を照合します。MicrosoftのIIS SNI公式資料も、ホスト名と証明書名を一致させる手順を示しています。

修正後は、wwwあり・なし、IPv4・IPv6、主要サブドメインを別々に確認します。一方だけ旧サーバーへ向くAAAAレコードが残ると、回線によって異なる証明書が提示されるためです。

実際のホスト名をSNI付きで検査し、SAN・提示チェーン・DNSの接続先を一組として照合しましょう。

古いTLSや暗号方式の不一致をサーバー側でどう切り分ける？

ERR_SSL_VERSION_OR_CIPHER_MISMATCH、SSL_ERROR_NO_CYPHER_OVERLAP、「安全な接続を確立できません」などは、証明書の期限だけでなく、クライアントとサーバーに共通するTLSバージョンまたは暗号方式がない場合に発生します。極端に古いサーバーが旧式TLSだけを提供しているケースと、古い端末が現行サーバーの方式へ対応できないケースを分けます。

運営者はWebサーバー、ロードバランサー、WAF、CDNのどこでTLSを終端しているかを特定します。ブラウザから見える証明書やTLS設定は、公開元サーバーではなくCDNの設定である場合があります。設定変更前に、現在のTLSバージョン、暗号スイート、証明書、アクセスログ、エラー発生端末を記録してください。

古いTLSを無条件に再有効化して警告を消すのではなく、サーバーOS、Webサーバー、ミドルウェアをサポート中の版へ更新し、ホスティング事業者が提供する標準設定へ合わせます。古い業務端末だけが接続できない場合は、その端末のOS・ブラウザ更新可否を確認し、更新不能ならネットワーク分離やシステム更改を検討します。公開サイト全体の暗号設定を古い端末へ合わせると、他の利用者にも影響します。

CDNを利用している場合は、利用者からCDNまでの「エッジ」と、CDNから公開元までの「オリジン」を別々に調べます。Cloudflareであれば、2026年10月15日時点の画面名は対象ドメインの「SSL/TLS」→「Overview」と「Edge Certificates」です。Cloudflare公式のエラー診断は、エッジ証明書の状態、プロキシ対象DNS、期限切れカスタム証明書、多階層サブドメインを確認項目として挙げています。利用中のCDNが別製品なら、その事業者の公式手順に読み替えます。

一部の利用者だけが失敗する場合は、OS・ブラウザ版、IPv4・IPv6、企業プロキシ、接続地域を比較します。全利用者が同時に失敗した場合は、直前の証明書更新、CDN設定、ロードバランサー変更、Webサーバー再起動を優先して確認します。

TLS終端がCDN・ロードバランサー・公開元のどこかを確定してから、その層の設定を直してください。

混在コンテンツをConsoleとNetworkでどう特定してHTTPSへ直す？

混在コンテンツは、HTTPSで開いたページがHTTPのスクリプト、CSS、フォント、iframe、音声、動画などを要求する状態です。ブラウザは一部をHTTPSへ自動昇格し、危険度の高いリソースを遮断します。その結果、証明書警告がなくても、メニューが動かない、装飾が消える、フォームが送れないといった症状が起こります。MicrosoftのEdge開発者ツールのSecurity公式資料も、混在コンテンツの確認と、HTTPSで取得できないリソースが遮断されることを説明しています。

ChromeまたはEdgeでは、対象ページでF12キーまたは右クリックの「検証」から開発者ツールを開き、「Console」でMixed Contentを検索します。続いて「Network」を開いてページを再読み込みし、SchemeまたはURLがhttp://の要求を確認します。Firefoxでは「ウェブ開発ツール」内の「コンソール」と「ネットワーク」を使います。これらの画面名は2026年10月15日時点で、表示言語や版によって表記が変わります。

直す場所は、検出されたURLの生成元です。WordPressなら「設定」→「一般」の「WordPress アドレス（URL）」「サイトアドレス（URL）」、テーマ設定、メニュー、ウィジェット、投稿本文、カスタムフィールド、CSS、プラグイン設定を確認します。設定変更前にファイルとデータベースをバックアップしてください。データベース内を置換する場合は、シリアライズデータに対応した移行機能やWP-CLIなどを使い、単純な文字列置換で構造を壊さないようにします。

外部リソースがHTTPSに対応していなければ、URLの先頭だけを書き換えても読み込めません。提供元のHTTPS版へ差し替える、自サイトで利用許諾の範囲内に置く、別サービスへ切り替える、不要なら削除する、のいずれかを選びます。CSPのupgrade-insecure-requestsは移行補助になりますが、公開元にHTTPS版がなければ失敗します。根本のHTTP URLを修正したうえで利用します。

修正後は、キャッシュプラグイン、サーバーキャッシュ、CDNキャッシュを対象範囲だけ更新し、ログアウト状態とスマートフォン表示でも再検査します。トップページだけでなく、投稿、固定ページ、フォーム、検索結果、404ページも対象です。WordPressのHTTPS設定全体は、LUFTMEDIAのSSLとは？HTTPSの仕組みと証明書をレンタルサーバーで設定する方法も参照できます。

Consoleで遮断されたURLを見つけ、最終出力ではなくURLを生成している設定やデータを修正しましょう。

自動更新・CDN・レンタルサーバーをどう構成すれば再発を防げる？

証明書を一度発行して終わりにすると、更新失敗を公開後に利用者から知らされる可能性があります。Let’s Encryptなどを自分で運用する場合は、ACMEクライアントの自動更新だけでなく、更新後のWebサーバー再読み込み、失敗通知、有効期限監視まで確認します。Let’s Encryptの証明書プロファイル公式資料が示すように、有効期間はプロファイルによって異なり、短期証明書ほど確実な自動化が前提になります。固定した日数を想定せず、実際に発行された証明書のnotAfterと利用プロファイルを確認してください。

テストでは自動更新コマンドの試行モード、ACMEアカウント、HTTP-01またはDNS-01の認証条件、ポート80、DNS API資格情報、ファイル権限を確認します。更新成功ログだけでなく、新しい証明書が実際の443番ポートから提示されることまで検証します。複数台構成では、更新したノードだけ証明書が新しくなり、他ノードに旧証明書が残っていないかも確認します。

CDN利用時は、エッジ証明書とオリジン証明書を別々に管理します。CloudflareのFull (strict)公式資料では、オリジン証明書が有効期間内で、公開認証局またはCloudflare Origin CAから発行され、接続先ホスト名と一致することが検証条件です。設定変更後に526エラーが出る場合は、オリジンの443番ポート、証明書、有効期限、SANを確認します。オリジン用証明書をブラウザが直接信頼するとは限らないため、CDNのプロキシを解除して公開元へ直接接続させる構成変更にも注意が必要です。

共用レンタルサーバーは、証明書の発行、配置、中間証明書、自動更新を事業者側で管理できることが多く、専任管理者がいないサイトでは運用負担を減らせます。比較時は「無料SSL」の有無だけでなく、更新失敗通知、www・サブドメイン対応、外部DNS利用時の条件、CDN連携、バックアップ、障害時の問い合わせ方法を確認してください。料金、プラン名、無料SSLの対象、管理画面名、更新条件は2026年10月15日時点の各社公式サイトと申込画面で最終確認します。候補の整理にはLUFTMEDIAのレンタルサーバーおすすめ比較を利用できます。

運用表には、対象ホスト名、証明書の管理場所、更新方式、通知先、CDNのTLSモード、担当者、確認日を記録します。月次確認に加え、DNS変更、サーバー移転、CDN導入、サブドメイン追加、担当者変更の後に再検査します。通知先は個人メールだけにせず、引き継げる共有アドレスを選びます。

参照した公式情報

• Google Chromeヘルプ「Get help with common error messages in Chrome」
• Mozilla Support「What do the security warning codes mean?」
• Microsoft Learn「Understand security issues using the Security tool」
• Microsoft Learn「IIS Server Name Indication」
• Let’s Encrypt「Glossary」
• Let’s Encrypt「Profiles」
• Cloudflare「ERR_SSL_VERSION_OR_CIPHER_MISMATCH」
• Cloudflare「Full (strict)」

自動更新の成否ではなく、公開中の全ホスト名から新しい証明書が提示されるところまで監視しましょう。