FileZilla-プライマリ接続とデータ接続の証明書が一致しない
私のクライアントの1つが最近、 FileZilla Client ソフトウェア（Windows 7の場合）で上記のエラーメッセージを受け取り始めました。 FTPサーバーに接続しています（ WS_FTPサーバーby Ipswitch ）。これまでのトラブルシューティングで行ったことに入る前に、この問題に関するいくつかのポイントを次に示します。
- これは私のクライアントの中でこの問題を経験している（または少なくとも報告している）唯一のクライアントであり、FileZilla Clientソフトウェアを使用している他のクライアントがいることを私は知っています。
- FileZilla Clientソフトウェアを自分で使用していますが、同じサーバーに接続しているときにエラーを再現できません。
- このエラーは最近発生し始めたばかりです（過去数日以内）。それ以前は、ユーザーはエラーなしで同じサーバーに接続できました。
- WS_FTPサーバーログには、ユーザーが正常に接続したことが示されますが、その接続に問題があることを示すエラーは示されません。
この問題を解決するために、私は次のことを試しました。
- FTPサーバーのSSL証明書がまだ有効であることを確認しました（約10か月で有効期限が切れます）。
- WS_FTPサーバー構成のSSL/TLSに関するすべての設定を確認しました。
- ユーザーのFileZilla Clientソフトウェアの接続設定を、サイトマネージャーの設定と比較して確認しました。
- FileZilla Forums のいくつかの投稿からの指示に従い、
trustedcerts.xmlファイルの名前を（%APPDATA%\FileZilla\trustedcerts.xml）に変更し、を許可して、「キャッシュされた証明書」をクリアしました。 ）FileZilla Clientソフトウェアを再作成します。 - ユーザーのFileZilla Clientソフトウェアを最新バージョンに更新しました。
FileZillaフォーラムページ からこの情報をクロスポストしましたが、問題はクライアントソフトウェア、ユーザーのネットワーク内の何か、またはサーバー内の何かである可能性があることを認識しているため、ネットを少し広げます。現時点では、他に何を見るべきかわからないので、誰かが少なくとも私を正しい方向に向けてくれることを願っています。私は問題を引き起こしている可能性のあるユーザーのネットワーク上の何かに傾倒していますが、別のIT部門を「非難」する前に、その証拠を入手しようとしています。あなたが提供できるどんな助けでも大いに感謝されるでしょう。
UPDATE：クライアントのワークステーションに接続し、 @Martinによって提案された項目を確認しましたコメントのプリクリル。クライアントがドメイン制御のインストールを使用していることがわかりました WebrootSecureAnywhere®BusinessEndpointProtection ソフトウェア。彼らはまだ接続できないので、今回はメインFileZillaクライアントウィンドウからログ情報をコピーしました：
Status: Resolving address of ftp.company.com
Status: Connecting to XX.XX.XX.86:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Status: Server sent passive reply with unroutable address. Using server address instead.
Command: MLSD
Response: 150 Transferring directory
Error: Primary connection and data connection certificates don't match.
Error: Transfer connection interrupted: ECONNABORTED - Connection aborted
Response: 226 Transfer completed
Error: Failed to retrieve directory listing
また、私は彼のマシンと私のマシンの間で証明書の詳細を比較しました。これが私の Certificate Details ダイアログのスクリーンショットです： 
そして、これが彼の証明書の詳細ダイアログのスクリーンショットです： 
画像のURLを編集しましたが、すべて一致しています。 Fingerprint の値と Certificate issuer ブロックの詳細を見ると、明らかにいくつかの矛盾があります。私はユーザーに一時的にWebroot保護を無効にしてもらい（彼のIT部門の誰かが幸運にも私たちを助けてくれました）、再試行しました。残念ながら、同じ問題が発生しました。証明書を再度確認したところ、コンピューターにリストされているものと比較した場合でも、同じ不一致が見られました。
彼らのIT担当者は、同じネットワーク上の別のPCにFileZillaクライアントソフトウェアを新規インストールして接続を試みました。その接続で同じエラーが発生しました。別のネットワーク（携帯電話のWiFiホットスポットなど）に接続されたラップトップでFileZillaクライアントソフトウェアを構成して、問題が解決するかどうかを確認する可能性を提案しましたが、まだその機会がありませんでした。
私たちのSSL証明書 [〜＃〜]は[〜＃〜] COMODO PositiveSSL証明書なので、彼のシステム/ネットワークが発行者をピックアップする原因を特定する必要があります。フォーティネット。
EDIT：気まぐれに、FileZillaクライアントで新しい接続を設定し、上記で投稿したユーザーの接続ログからIPアドレスを明示的に指定しました。 way 接続していたことについて何も変わっていないことを確認するためだけに。エラーは発生せず、証明書の詳細ダイアログに以前と同じ内容が表示されます（DNS名ではなくIPアドレスとしてホストが表示される点が異なります）。これが私の最新のセッションからのログです：
13:35:44 Status: Connecting to XX.XX.XX.86:21...
13:35:44 Status: Connection established, waiting for welcome message...
13:35:44 Status: Initializing TLS...
13:35:44 Status: Verifying certificate...
13:35:44 Status: TLS connection established.
13:35:45 Status: Logged in
13:35:45 Status: Retrieving directory listing...
UPDATE＃2：クライアントから電話があり、IT部門が問題の原因を見つけ、社内で変更を加えて取得したことを通知しました。彼の接続は機能しています。要約は次のとおりです。
1年以上前に、当社はFTPサーバーのIPアドレスを変更しました。その際、すべてのクライアントとパートナーにこの変更を通知する電子メール「ブラスト」を送信しました。ただし、このクライアントのIT部門は、IPアドレスを認識せず、ファイアウォールにそのトラフィックを許可する適切なルールがなかったため、そのメモを受け取らなかったようです。
1年以上エラーなしで動作しているという事実は、まだ少し困惑していますが、現在動作している限り、（今のところ）手放すつもりです。トラブルシューティングの概要を後で回答として投稿しますが、仕事に戻らなければなりません。
「プライマリ接続とデータ接続の証明書が一致しません」というエラーメッセージが報告されました。 FileZilla Clientソフトウェアによると、ほとんどのソリューションはFTPサーバーの設定ミスを示しているようです。これは確かに有効なトラブルシューティングの「手順」ですが、調査する追加の手順がいくつかあります。特に、エンドユーザーが以前に正常に接続できた場合はそうです。
この特定のエラーは、FileZilla ClientソフトウェアとFTPサーバーの間に基本的なインターネット接続が確立されていることを意味します。問題はFTPサーバーに接続することではなく、通信のSSL/TLS暗号化のネゴシエーションにあります。 （リリース）FileZillaクライアントソフトウェアは、SSL証明書の有効性に疑問がある場合、TLS接続の続行を許可しません。
次のトラブルシューティング手順は、エラーの原因を特定および/または解決するのに役立つか、少なくともいくつかの可能性を排除するのに役立ちます。
クライアント側のトラブルシューティング
- 次のようなFTPクライアントの接続設定を確認します。
- ホスト名/ IPとポート
- SSL/TLSオプション
- FTPサーバーのログイン情報（ユーザー名/パスワード）
- サーバータイプ
- 転送モード（アクティブ/パッシブ）
- クライアントマシンにキャッシュされている証明書情報を確認/クリアします。
- FileZilla Clientソフトウェアでは、これは、これらの証明書を格納するXMLファイルを削除/名前変更することによって行われます（
%APPDATA%\FileZilla\trustedcerts.xml）
- FileZilla Clientソフトウェアでは、これは、これらの証明書を格納するXMLファイルを削除/名前変更することによって行われます（
- FTPクライアントソフトウェアが最新であることを確認してください。他の変更（FTPサーバーの更新、ネットワーク構成の変更、セキュリティソフトウェアの更新など）が通信に問題を引き起こしている可能性があります可能性があります。
- FTPクライアントがローカルネットワーク上にある場合は、同じネットワーク上の別のコンピューターから接続してみてください。この他のコンピューターが接続できる場合、問題は1台（または複数）のコンピューターに固有です。
- クライアントマシンにインストールされているセキュリティソフトウェアを無効にしてみてください。一部のA/Vまたはその他のインターネットセキュリティアプリケーションは、FTPクライアントとFTPサーバー間の通信を妨害する可能性のある「man-in-the-middle」として機能する可能性があります。
- 可能であれば、別のインターネット接続を使用してFTPサーバーにアクセスしてみてください。
- これをテストするために私が見つけた「最も簡単な」方法は、携帯電話のWiFiホットスポットをオンにして、ラップトップをそのネットワークに接続することです。
- FTPクライアントがファイアウォールの背後にある場合は、ファイアウォールがFTPトラフィックをブロックまたは干渉していないことを確認してください。ファイアウォールによっては、これはファイアウォールのポートを開く、FTPサーバーのIPアドレスをホワイトリストに登録する、またはその他の構成オプションを意味する場合があります。
FTPサーバーを制御している場合
もちろん、使用しているFTPサーバーソフトウェアによっては、確認する必要がある/確認したいことがたくさんあります。ここに「基本」をリストしているだけです。
- 失敗した接続に関する追加の詳細については、FTPサーバーのログを確認してください。
- FTPサーバーにインストールされているSSL証明書の有効期限が切れておらず、まだ有効であることを確認してください。
- FTPサーバーのSSL/TLS構成設定を確認します。
- FTPサーバーを指すパブリック（および/または内部）DNSレコードと構成を確認します。
- FTPサーバーで、ユーザー名またはIPアドレスのいずれかによってユーザーがブロック/ブラックリストに登録されていないことを確認してください。これには、（おそらく）パスワードの更新/リセットが必要なユーザーアカウントやその他の内部セキュリティ設定などが含まれる場合もあります。
FTPサーバーを制御しない場合
FTPサーバーを担当する個人/会社に連絡してください。 クライアント側のトラブルシューティングの結果を提供して、管理者が接続の終了のトラブルシューティングを行うのを支援します。
- 注：FileZillaはオープンソースプロジェクトであるため、ソフトウェアがこの潜在的な危険を無視するように、ソースコードを取得して変更することができます。行う変更の説明は FileZilla Forums にあります。ただし、このリンクを含めている間は、非常にでこのソフトウェアをのみ使用している場合を除き、注意してください。制御された環境では、notこの手順を実行することをお勧めします。
クライアントのローカル環境によっては、他のトラブルシューティング手順も実行する必要がある場合があります。また、ここでの手順で明らかなことを見逃した場合は、他の誰かがこの問題に遭遇した場合に備えて追加できるようにコメントしてください。