TLS証明書エラーの対処法

1. ログから証明書エラーと接続失敗を見分ける

「TLSハンドシェイク失敗」は結果を示すもので、具体的な原因ではありません。まずv2rayNのメイン画面下部にあるログ欄で、直近の接続に関するエラー全文を確認します。ログ欄が折りたたまれている場合は、該当パネルを開いてください。バージョンによって画面上の位置は異なりますが、ブラウザーに表示された「接続がリセットされました」だけでなく、x509、tls、certificateを含むコアのログを確認してください。

ノードを1つ選び、接続時刻を記録して、リクエストを1回だけ送信します。以下はよくある英語のエラー例です。実際のログにはコアのモジュール名や接続先、詳細な原因が追加される場合があります。ログを共有する際は、サブスクリプションURL、ユーザー識別情報、アクセス先に含まれる機密情報を削除してください。

2. システム時刻を同期して証明書の期限を確認する

TLSでは現在時刻を証明書のnotBefore、notAfterと照合します。停電後に時計がリセットされた、仮想マシンを古いスナップショットに戻した、日付を手動で変更したなどの理由で、有効な証明書が「まだ有効ではない」または「期限切れ」と判定されることがあります。タスクバーの時刻だけでなく、年月日と分まで確認してください。

1. 日付と時刻を確認

   Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、日付、時刻、現在のタイムゾーンを確認します。時刻が正しく同期されている別の端末とも比較してください。

2. 時刻を今すぐ同期

   「時刻を自動的に設定する」を有効にし、「その他の設定」で「今すぐ同期」をクリックします。同期に失敗する場合は、まず通常のネットワーク接続に戻してから、Windowsの時刻サービスを再試行してください。

3. 再接続

   クライアントに戻り、現在のノードを再度有効にして新しいリクエストを送信します。同期前に記録された古いエラーではなく、新しいログを確認してください。

4. 証明書の有効期間を確認

   時刻が正確なのに期限切れと表示される場合は、サーバーから実際に返された証明書の有効期間を確認します。現在時刻が本当にnotAfterを過ぎている場合は、管理者が証明書を更新し、TLSサービスに再読み込みさせる必要があります。

Androidでは、システムの「設定」で「日付と時刻」を検索し、自動設定を有効にします。メニューの位置はOSによって異なります。タイムゾーンは時刻の表示方法に影響しますが、基準となる時刻が正しければ、タイムゾーンを変えただけで証明書エラーが発生することは通常ありません。反対に、時計を過去に戻すと一時的に接続できても、ほかのサービスに影響するため修正方法として使わないでください。

時刻同期とノードへの接続は別の通信経路です。ノードが443番ポートを使っていても、時刻同期が同じポートを使うとは限りません。同期サービスのネットワーク設定を調べる場合は、実際に使われている時刻サーバーとプロトコルを確認し、端末の受信ポートをむやみに開放しないでください。

3. SNI、サーバーアドレス、Hostを確認する

ノードの「アドレス」、TLSの「サーバー名」、WebSocketの「Host」はそれぞれ別の項目です。サーバーアドレスは接続先を指定し、SNIはTLSハンドシェイクでサーバーにサイトと証明書を選択させます。HTTPのHostやHTTP/2のauthorityはアプリケーション層のリクエストで使われます。Hostを変更しても、証明書検証に使う名前は自動では修正されません。

v2rayNのメイン画面でノードをダブルクリックし、サーバー編集画面でTLSが選択されていることを確認してから、「SNI」またはサーバー名にあたる項目を確認します。バージョンによって項目名が異なるため、serverNameの意味と照らし合わせてください。v2rayNGではノードカードの編集画面を開き、TLS設定のSNIを確認します。ホスト名の欄にhttps://、:443、URLのパスを含めないでください。

• 接続先にIPアドレスを使う場合でも、SNIにはドメイン名を明示する必要があることがあります。設定しないとクライアントがIPアドレスで証明書を検証し、証明書にはドメイン名しか含まれていないためです。
• *.example.comは通常a.example.comには一致しますが、example.comやa.b.example.comにも一致するとは限りません。
• 「偽装ドメイン」は画面上で複数の意味に使われることがあります。まず実際にSNIとHostのどちらを指すか確認し、管理者から提供された設定値と照らし合わせてください。
• サブスクリプションを更新すると問題が再発する場合は、サブスクリプション内のSNIが古い値のままではないか確認してください。ローカルのコピーだけを変更すると、次回の更新で上書きされることがあります。

4. 証明書チェーンとサーバーから返される証明書を確認する

「unknown authority」は「証明書の期限切れ」と同じではありません。ドメイン証明書が有効でも、中間証明書が送信されないと、クライアントが信頼チェーンを構築できないことがあります。ブラウザーで開けても、この問題がないとは限りません。ブラウザーとプロキシコアでは、信頼ストア、キャッシュ、中間証明書の取得方法が異なる場合があります。

OpenSSLがインストールされている場合は、次のコマンドでサーバーを確認できます。ここでのexample.comは説明用の予約ドメインで、このサイトのノードではありません。実行前にコマンド内のドメイン名とポートを実際の値に変更してください。接続先とSNIが異なる場合、-connectには実際の接続先を、-servernameと-verify_hostnameにはTLSで使用するホスト名を指定します。

openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_hostname example.com -verify_return_error

• 返されたリーフ証明書が想定したサイトのものか確認します。別サイトの証明書が返された場合は、SNIとサーバーの仮想ホスト設定を確認してください。
• Certificate chainに必要な中間証明書が含まれているか確認します。通常、サーバーはリーフ証明書と中間証明書を送信しますが、ルート証明書を含める必要はありません。
• 検証結果を確認します。Verify return code: 0 (ok)は、このツールの現在の信頼環境で検証に成功したことを示します。すべての端末で必ず成功するという意味ではありません。
• OpenSSLのCA信頼パスが正しく設定されていない場合も、発行者に関するエラーが発生することがあります。サーバーの問題と誤認しないよう、まずテストツールの信頼環境を確認してください。

管理者は、実際にTLSを終端するサービスに完全な証明書チェーンを設定してください。たとえば前段にリバースプロキシがある場合は、バックエンドのコアのディレクトリだけでなく、リバースプロキシが読み込む証明書を更新します。証明書の更新後は関連サービスを再読み込みし、外部から再度ハンドシェイクして新しい証明書が返されることを確認してください。

5. 修正後は同じ条件で再テストする

ノードの変更、SNIの修正、DNSの切り替え、Tunの有効化を同時に行うと、結果を比較できなくなります。同じノードとテスト先を使い、変更は一度に1つだけにしてください。次の手順なら、設定の修正による改善か、たまたま別の経路で接続できただけなのかを見分けられます。

1. 修正前の状態を記録：ノードのアドレス、ポート、TLSの種類、SNI、エラー発生時刻を記録します。ノードの認証情報は公開しないでください。
2. 時刻同期後に再テスト：ノードの設定は変えず、システム時刻だけを同期します。有効期間のエラーが解消したら、名前や信頼チェーンに関するエラーが残っていないか確認してください。
3. SNI修正後に再テスト：管理者から指定された値にSNIを修正して再接続し、新しいログで検証対象の名前が想定どおりか確認します。
4. ネットワークを変えて比較：同じ端末とノードを別のネットワークで試します。特定のネットワークだけ異なる証明書が返される場合は、通信の遮断、名前解決、中間機器を確認してください。
5. 修正が維持されるか確認：サブスクリプションを更新し、クライアントを再起動してからもう一度テストします。修正値がサブスクリプションで上書きされていないか、サーバーが古い証明書を返し続けていないか確認してください。

正しい時刻とSNIを設定しても証明書の期限切れやチェーン不備が表示される場合、クライアント側で解決できる範囲は限られます。管理者には、エラーの原文、テスト時刻、クライアントとコアのバージョン、接続ポート、想定するSNIを伝えると、「ノードが使えない」というスクリーンショットだけより原因を特定しやすくなります。ネットワークやコアに関する問題はトラブルシューティングガイドもご覧ください。

6. よくある質問：検証のスキップとハンドシェイクの中断