TLS証明書エラーの対処法｜システム時刻のずれ・SNI設定ミスを確認

1. まずログを確認：証明書エラーはポート接続エラーとは限らない

TLSハンドシェイクはトランスポート接続の確立後に行われます。TCP接続に成功しても、接続先ポートが応答したことしか分からず、証明書の信頼性やドメインの一致、プロキシ認証の成功までは確認できません。v2rayNのTCPingでは応答があるのに、実際の接続テストに失敗することもあります。矛盾ではないため、ローカルのプロキシポートを何度も切り替えないでください。

クライアント名とバージョン、実際に動作しているコアのバージョン、ノードのセキュリティ方式、失敗した時刻を記録します。バックグラウンドでの連続テストを止め、1つのノードで接続を1回だけ試し、ログから同じ時刻に発生した最も内側のエラーを探してください。外側に表示される failed to find an available destination は概要にすぎません。その後に記録された具体的な原因も確認しましょう。

2. システム時刻を同期：日付・タイムゾーン・証明書の有効期間を確認

証明書には notBefore と notAfter の時刻が記録されています。検証に使われるのはシステム時計が示す絶対時刻で、タスクバーに表示される時刻だけではありません。絶対時刻が正しいままタイムゾーンだけを変更しても、通常は証明書エラーになりません。一方、現地時刻を別のタイムゾーンの時刻に手動で合わせると、数時間のずれが生じることがあります。

1. 日付を確認

   まず年・月・日が正しいか確認します。端末を長期間電源オフにした後や、スナップショットの復元後、マザーボードの時計に問題がある場合、日付が過去に戻っていることがあります。分だけを調整して近い時刻に合わせないでください。

2. パソコンの時刻を同期

   Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にします。「タイムゾーン」を確認してから「今すぐ同期」をクリックしてください。macOSでは「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を有効にします。

3. Androidの時刻を同期

   Androidでは通常、「設定」→「システム」→「日付と時刻」から、「時刻を自動設定」とタイムゾーンの自動設定を有効にできます。項目名はシステムによって異なる場合があります。設定内で「日付と時刻」を検索してください。

4. 再接続して結果を記録

   同期が完了したことを確認してから、クライアントを再起動して接続します。それでも期限切れのエラーが出る場合は、エラーに表示された現在時刻と証明書の有効期間を記録し、ノードの管理者にサーバーが実際に提供している証明書を確認してもらいましょう。

Windowsでは、ターミナルで w32tm /query /status を実行すると時刻同期の状態を確認できます。同期コマンド w32tm /resync の実行には通常、管理者権限が必要で、Windows Timeサービスも動作している必要があります。コマンドが失敗した場合は、サービスとネットワークを確認してください。コマンドを実行しただけで同期済みとは限りません。Linuxでは timedatectl status でシステム時計と時刻同期サービスの状態を確認できます。有効化の方法はディストリビューションによって異なります。

3. SNI・接続先・Host：3つの項目を個別に確認

SNIはTLS ClientHelloで接続先のホスト名を示す拡張です。クライアント設定の serverName は通常、ハンドシェイクに使う名前と証明書名の検証に使われますが、具体的な動作はコアによって異なります。サーバー側の指定に合致し、証明書のSANに含まれるドメインを設定してください。「偽装ドメイン」は共通のプロトコル項目名ではありません。提供元に、それがSNI、WebSocketのHost、その他のトランスポート設定のどれを指すのか確認しましょう。

接続先にIPアドレス、SNIにドメイン名を設定するのは正常な構成です。たとえばIPアドレスに直接接続しながら、ドメイン名を使ってTLSの名前を検証できます。反対に、SNIを削除してIPアドレスで検証すると、証明書にドメイン名しか含まれていない場合、cannot validate certificate ... because it doesn't contain any IP SANs が発生することがあります。「接続先とSNIが異なる」だけで誤設定と判断しないでください。

• v2rayNのメイン画面で対象ノードをダブルクリックし、編集画面でアドレス、ポート、トランスポートのセキュリティ設定、SNIを確認します。保存前に元の値を記録してください。画面上の項目名はバージョンによって異なり、SNIが「サーバー名」と表示される場合もあります。
• v2rayNGとv2flyNGでは、ノード一覧から対象の編集ボタンをタップし、トランスポートまたはTLSの設定を開いて各項目を確認します。変更は対象ノードだけに行い、ついでに全体のルーティング設定を変えないでください。
• SNIには example.com のようなホスト名を指定します。https://example.com:443/path のような形式は使えません。ここでのドメイン名は形式の例です。実際の値はノード設定で確認してください。
• ワイルドカード証明書の *.example.com は通常、a.example.com には一致しますが、ルートドメインの example.com や a.b.example.com には一致しません。

以下は通常のTLSの部分的な設定例で、接続可能な完全なノード設定ではありません。REALITYにも適用できません。実際のノードで設定されているトランスポートの種類は変更しないでください。この例では接続先、認証情報、その他のアウトバウンド設定を省略しています。

{
  "streamSettings": {
    "network": "tcp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com",
      "allowInsecure": false
    }
  }
}

4. allowInsecure：証明書の修正には使えない

allowInsecure を true にすると、通常のサーバー証明書検証がスキップされます。画面上の「安全でない接続を許可」や「証明書の検証をスキップ」は、通常この動作に該当します。TLS暗号化が行われる場合でも、通常の証明書チェーンや名前の検証で接続先の正当性を確認できなくなります。互換性を高めるための万能な設定ではありません。

• 公開CAの信頼できる証明書：サーバー側でリーフ証明書と必要な中間証明書を提供し、クライアントでは検証を有効にします。
• プライベート証明書基盤：証明書の発行元を確実に管理できる場合に限り、組織の基準に従って信頼ルートやサポート対象の証明書制約を設定します。見慣れない警告をきっかけに、安易にルート証明書をインストールしないでください。
• 古いシステムの信頼ストア：システムの更新状況と信頼されたルート証明書を確認します。出所不明の証明書をインポートするのは最初の対処にしないでください。

5. フィンガープリントとREALITY：実際のコアに合わせて切り分ける

クライアントのフィンガープリントはTLSハンドシェイクの特徴を示すもので、証明書のドメイン名でも検証をスキップする設定でもありません。対応機能を備えたXray設定では、fingerprint に chrome など、コアがサポートする値を指定できます。変更しても期限切れの証明書は有効にならず、SANにないドメインが自動的に追加されることもありません。

v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。機能や設定項目をそのまま流用することはできません。v2rayNでは、対象ノードが実際に使っているコアを確認してください。REALITYやXTLS Visionを使う場合は、選択したコアが対応していることを先に確認します。リンクをインポートできても、すべてのパラメーターが反映されているとは限りません。

• 通常のTLS：現在のフィンガープリント設定はそのままにして、時刻とSNIを修正します。ログやサーバー側の指定からハンドシェイクの互換性が原因と判断できる場合に限り、サポートされているフィンガープリントを1つ試してください。
• REALITY：提供元が指定したサーバー名、公開鍵、shortIdを一字ずつ確認します。端末の時刻も確認してください。サーバー側に時刻の許容範囲が設定されている場合、時計のずれが認証に影響することがあります。
• VLESSのflowは別の設定項目です。ノードで xtls-rprx-vision が指定されている場合は、サーバー側の設定と一致させてください。ただしflowを変更しても、通常のTLSにおける証明書名の不一致は解決しません。

6. ハンドシェイクツールで切り分け：ポート・証明書チェーン・サーバーを確認

OpenSSLがインストール済みの場合、通常のTLS接続先の証明書を直接確認できます。以下のコマンドにある example.com は形式例です。実行前に、実際の接続先とサーバーが要求するSNIに置き換えてください。接続ポートもノードの設定に従います。このテストで確認できるのはTLS層のみで、VMessやVLESSの認証は検証されません。

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

• 証明書の有効期間、SAN、発行者を確認します。返された証明書が対象サービスのものかを確認してください。ゲートウェイ、ログイン画面、別のサイトの証明書ではないことも確かめましょう。
• 検証結果とエラーの原因を確認します。ツールとクライアントで異なる信頼ストアが使われる場合があるため、ツールで検証に成功しても切り分けの手がかりにすぎません。クライアントでも再テストしてください。
• 証明書が返される前に接続が切れる場合は、そのポートが実際にTLS接続先か、SNIが許可されているか、前段プロキシの転送設定が正しいかを確認してください。
• 信頼できる別のネットワークに切り替えた後で返される証明書が変わった場合は、ネットワーク機器やセキュリティソフトによる証明書の差し替えを確認してください。出所が分からない証明書をそのまま受け入れないでください。
• 通常のOpenSSLによる接続確認では、REALITY固有の認証パラメーターを検証できません。REALITYはクライアントコアのログとサーバーログを照らし合わせて調べてください。

7. 修正後の確認とよくある質問

変更するたびにノードを保存してから接続し直してください。既存の長時間接続には新しい設定がすぐ反映されないことがあります。「コアが正常に起動 → ノードのハンドシェイク成功 → 実際のリクエストが利用可能」の順で確認します。クライアントログに証明書エラーがなくなったのにブラウザーで問題が続く場合は、システムプロキシ、アプリのプロキシ設定、ルーティングルールを確認してください。TLS設定全体を再び調べ直す必要はありません。

1. 時刻の自動同期が成功し、端末を再起動した後も日付が正しいことを確認します。
2. SNIがサーバーの指定と一致し、証明書検証が有効で、トランスポート層のHostとパスが誤って変更されていないことを確認します。
3. 修正したノードを選び、実際の接続テストを1回行ってから、プロキシを正しく設定したアプリで対象サイトにアクセスします。
4. 修正した項目と結果を記録します。サブスクリプションの設定を使っている場合は提供元に元データの修正を依頼し、次回の更新でローカルの変更が上書きされないようにしてください。