ナビゲーションをスキップして本文へ
トラブル対処 読了時間：約10分

Clash起動後に証明書エラーが表示される原因と対処法｜NET::ERR_CERT

プロキシ接続時に「この接続ではプライバシーが保護されません」と表示される場合、時刻のずれ、MITM設定の残存、DNS汚染、接続先ノードによるリダイレクトなどが考えられます。症状別に原因を切り分け、対処法を解説します。

証明書エラーの内容を記録し、アクセスを続行しない

ChromeやEdgeで「この接続ではプライバシーが保護されません」と表示されたら、まずページ下部にあるエラーコードをすべて記録してください。NET::ERR_CERT_DATE_INVALIDとNET::ERR_CERT_AUTHORITY_INVALIDでは確認すべき点が異なり、どちらも「ノードの不具合」と決めつけて対処することはできません。決済、メール、社内ログイン、管理画面などのページでは、直ちにパスワードの入力をやめてください。

通常のClashやClash Meta（mihomo）によるプロキシ転送では、接続先サイトの証明書が再発行されることはありません。ブラウザーがHTTPプロキシ経由でCONNECTトンネルを確立する場合も、TUNで通信を処理する場合も、通常HTTPS接続はブラウザーと接続先サイトの間で確立されます。プロキシを使うために、出所不明のルート証明書をあらかじめインストールする必要はありません。

次の4項目を記録する

NET::ERR_CERTのエラーコードから原因を絞り込む

エラーコード主な意味優先して確認する項目
NET::ERR_CERT_DATE_INVALID証明書がまだ有効になっていない、または期限切れです。端末の時刻が誤っている可能性もあります。システムの日付と時刻、時刻同期、証明書の有効期間。
NET::ERR_CERT_AUTHORITY_INVALID信頼されたルート証明書までの検証チェーンをブラウザーが構築できません。自己署名証明書、中間証明書の不足、HTTPS検査ソフト、ルート証明書の設定。
NET::ERR_CERT_COMMON_NAME_INVALIDアクセス先のホスト名と証明書に記載された名前が一致しません。SAN、名前解決の誤り、ポータルへのリダイレクト、Webサーバーの設定。
NET::ERR_CERT_REVOKED証明書が失効していると判定されました。サイトの証明書ステータスと端末のセキュリティソフトを確認してください。検証を緩めてアクセスを続けないでください。

エラー名にあるCOMMON_NAMEは、証明書のCNフィールドだけを検査するという意味ではありません。現在のブラウザーは主にSANに基づいてホスト名を検証します。たとえばwww.example.comにアクセスしたのに、portal.example.netのみを対象とする証明書が返された場合、ホスト名の検証に失敗します。

ERR_SSL_PROTOCOL_ERRORやERR_TUNNEL_CONNECTION_FAILEDは、上記の証明書エラーとは別の種類です。前者はTLSのネゴシエーション中に発生する場合があり、後者はプロキシトンネルが確立できていない可能性があります。この場合、接続先サイトの証明書をまだ取得できていないこともあるため、まずクライアントの接続記録とログを確認してください。

日付に関するエラー：システム時刻を合わせてからサイトの有効期間を確認

複数のサイトで同時にNET::ERR_CERT_DATE_INVALIDが表示される場合は、まずタスクバーの時刻を確認してください。端末を長期間シャットダウンしていた、バッテリーに異常がある、年を手動で変更したといった原因で、有効な証明書が期限切れまたは未有効に見えることがあります。タイムゾーンの表示が異なるだけで必ずエラーになるわけではありません。重要なのは、システム時刻が正確かどうかです。

  1. Windows 11：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」をオンにします。タイムゾーンを確認したうえで、「その他の設定」の「今すぐ同期」をクリックしてください。
  2. macOS：「システム設定」→「一般」→「日付と時刻」を開き、「日時を自動的に設定」をオンにします。
  3. Android：システム設定で「日付と時刻」を検索し、自動設定をオンにします。メニューの場所はメーカーによって異なります。
  4. 時刻を合わせたら、ブラウザーを完全に終了してから再起動し、同じURLにアクセスします。端末の再起動後に時刻が再びずれる場合は、システムの時刻同期サービスやハードウェアクロックを確認してください。

システム時刻が正しく、特定のサイトだけでエラーが起きる場合は、そのサイトの証明書の有効期間を確認してください。証明書が実際に期限切れなら、サイト管理者による更新が必要です。ノードを変更すると別のサーバーに接続できることはありますが、サイトの証明書を修復することはできません。エラーが起きたドメイン、時刻、証明書の有効期間を記録し、サイト管理者に連絡しましょう。

発行者が不審な場合：MITM、パケットキャプチャツール、セキュリティソフトの残存設定を確認

複数の無関係なサイトで同じ不明な発行者の証明書が表示される場合は、ソフトウェアがHTTPS通信を復号していないか確認してください。MITMとは、中間者方式で通信を検査することです。デバッグ用プロキシ、企業ゲートウェイ、一部のセキュリティソフトは、端末で信頼されている証明書を使ってサイト証明書を再発行できます。これはClashによる通常の通信転送とは別の仕組みです。

まず再発行機能を停止し、証明書の出所を確認する

  1. Fiddler、Charles、mitmproxyなど、パケットキャプチャに使用したツールを終了し、ツールの設定でHTTPS復号またはSSL Proxyingを無効にしてください。ウィンドウを閉じただけでは、バックグラウンドプロセスが終了していない場合があります。
  2. セキュリティソフトのHTTPSスキャンや暗号化接続の検査機能を確認してください。個人用端末では、比較のため一時的に機能を無効にしてテストし、完了後は製品の説明に従って元に戻します。管理対象端末の場合は、先に管理者へ相談してください。
  3. WindowsではWin + Rを押してcertmgr.mscと入力し、現在のユーザーの「信頼されたルート証明機関」→「証明書」を確認します。コンピューター単位の証明書はcertlm.mscで確認できます。
  4. macOSでは「キーチェーンアクセス」を開き、「ログイン」と「システム」の各キーチェーンにある証明書と信頼設定を確認してください。

ルート証明書が残っているだけでは、証明書の再発行が現在行われているとは限りません。該当するプロキシや検査サービスが接続に関与している必要があります。一方、再発行サービスが動作していても信頼用証明書が削除済みなら、発行元が信頼されないというエラーが起きます。証明書マネージャーで追加と削除を繰り返すのではなく、プロキシの接続先、実行中のプロセス、証明書をまとめて確認してください。

名前が一致しない場合：DNSの異常、ネットワークポータル、サイト設定を切り分ける

NET::ERR_CERT_COMMON_NAME_INVALIDは、誤ったサーバーに接続した場合によく発生します。ただし、このエラーだけでDNS汚染やノードによるリダイレクトと断定することはできません。サイトのCDN設定ミス、公衆Wi-Fiのログインポータル、IPアドレスの直接入力でも同様のエラーが起きることがあります。

まず端末側の設定を確認し、次に実際の名前解決経路を調べる

Windowsでは次のコマンドを使って、システムの既定のDNSリゾルバーが返す結果を確認できます。hostsまたはシステムDNSを修正した後は、システムのキャッシュを消去してください。以下のドメインはコマンド例です。実際の調査では、エラーが起きたドメインに置き換えてください。

nslookup example.com
ipconfig /flushdns

nslookupだけでは、ブラウザーが実際にどのIPアドレスを使ったかは特定できません。mihomoのTUN、DNSリダイレクト、fake-ipを有効にしている場合、名前解決の経路が処理されることがあります。fake-ipモードで198.18.0.0/16の範囲にある合成アドレスが返されても、それだけで異常とは限りません。現在の設定にあるdns、enhanced-mode、fake-ip-rangeと、クライアントの接続記録を照らし合わせて判断してください。

DNSを変更しながらノードを切り替え、同時にキャッシュも消去するのは避けてください。一度に変更するのは1項目だけにし、既存の接続を閉じてから再試行します。CDNがネットワークごとに異なるIPアドレスを返すのはよくあることで、IPアドレスが異なるだけでは汚染の証拠になりません。確認すべきなのは、証明書がアクセス先のドメインを対象としているかどうかです。

直接接続とプロキシノードを比較して、接続経路の問題を特定する

プロキシを有効にしたときだけ問題が起きる場合は、条件をそろえて比較テストを行います。ログイン不要の公開ページを選び、同じドメインへの直接接続、ノードA、ノードBでの結果を記録してください。自動選択のプロキシグループでは実際のノードが切り替わることがあるため、グループ名だけでなく、接続記録で最終的な送信先を確認してください。

  1. 現在の状態を保存：現在の設定、ルールモード、システムプロキシとTUNの状態を記録します。接続経路が重複しないよう、他のVPNやパケットキャプチャ用プロキシは一時停止してください。
  2. 直接接続でテスト：ClashのシステムプロキシとTUNを無効にします。システムに手動プロキシや自動構成スクリプトが残っていないことを確認してから、クライアントを終了し、ブラウザーを再起動してください。クライアントを終了しても、すべてのプロキシ設定が自動的に解除されるとは限りません。
  3. プロキシ接続でテスト：元の設定に戻し、固定ノードで同じドメインにアクセスします。接続記録で適用されたルールと送信先を確認してください。
  4. 変更するのは1項目だけ：ルールとDNS設定は変えず、別の信頼できるノードに切り替えて、証明書の名前、発行者、エラーコードを比較します。

コマンドラインで比較する場合は、ローカルポートを明示する

以下は、クライアントにHTTPポートまたは混合ポートとして7897が表示されている場合のWindowsの例です。実際のポート番号はクライアントで確認してください。明示的なプロキシを使ってテストする場合は、いわゆる「直接接続」が透過的に処理されないよう、先にTUNを無効にします。macOSとLinuxでは、通常コマンド名をcurlに変えれば実行できます。

curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/
curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7897 https://example.com/

1つ目のコマンドは明示的なプロキシを経由せず、2つ目はローカルHTTPプロキシを指定します。今回確認する証明書検証を回避してしまうため、-kや--insecureは追加しないでください。-IはHEADリクエストを送信します。一部のサイトが405を返しても、証明書エラーとは限りません。HTTPレスポンスを受信できた場合、その接続では通常TLS検証が完了しています。

curlとブラウザーでは、信頼ストアやプロキシ経路が異なる場合があります。そのため、コマンドが成功してもブラウザーでのテストの代わりにはなりません。-vの出力を共有する前に、認証ヘッダー、Cookie、社内ネットワークのアドレスなどの機密情報を削除してください。テストのためにサブスクリプションURLをコマンドラインや公開検査サイトに貼り付けることも避けてください。

比較結果をもとに次の対処を決める

設定を元に戻して再テストする：検証スキップを設定に残さない

設定のskip-cert-verify: trueは、ブラウザーの証明書エラーを解決する汎用的な方法ではありません。TLSを使うプロキシプロトコルでは、通常この項目はカーネルがプロキシサーバーの証明書を検証するかどうかを制御します。ブラウザーに接続先サイトを信頼させる設定ではありません。変更するとノード接続の本人確認が弱くなる可能性がありますが、Webページの証明書に関するドメイン名、有効期間、信頼チェーンの問題は解決しません。

同様に、TUNが変えるのは主に通信を処理する経路であり、それ自体がサイトの証明書を発行することはありません。TUNを有効にしたときだけエラーが起きる場合は、通信が別のノードに向かっていないか、DNSが処理されていないか、別のVPNと競合していないかを確認してください。すぐにシステムへ証明書をインストールする必要はありません。

証明書エラーは「エラーコード全体を確認する→システム時刻を調べる→証明書の発行者と名前を確認する→直接接続とノード接続を比較する」の順に対処できます。この手順なら、端末の信頼設定、サイトの設定、プロキシ経路の問題を切り分けられ、設定変更や検証の無効化を繰り返して運任せにすることを避けられます。

Clashインストーラー