FileZilla - Первичные сертификаты подключения и подключения к данным не совпадают

Question

Один из моих клиентов недавно начал получать вышеупомянутое сообщение об ошибке в программном обеспечении FileZilla Client (в Windows 7) при подключении к моему FTP-серверу (WS_FTP Server от Ipswitch). Прежде чем перейти к тому, что я уже сделал для устранения неполадок, вот несколько моментов об этой проблеме:

• Это единственный из моих клиентов, который столкнулся (или хотя бы сообщил) с этой проблемой, и я знаю, что есть другие клиенты, использующие программное обеспечение FileZilla Client .
• Я использую программное обеспечение FileZilla Client самостоятельно и не могу воспроизвести ошибку при подключении к тому же серверу.
• Эта ошибка только недавно начала появляться (в течение последних нескольких дней). До этого пользователь мог подключаться к одному серверу без ошибок.
• Журналы сервера WS_FTP показывают, что пользователь успешно подключился, но не показывают ошибок, указывающих на проблемы с этим подключением.

Чтобы решить эту проблему, я попробовал следующее:

1. Проверено, что сертификат SSL для моего FTP-сервера все еще действителен (срок его действия истекает примерно через 10 месяцев).
2. Рассмотрены все параметры, касающиеся SSL/TLS в конфигурации сервера WS_FTP .
3. Проверьте параметры подключения в клиентском программном обеспечении FileZilla пользователя, сравнив их с параметрами в моем диспетчере сайтов.
4. Следуя инструкциям из нескольких сообщений на форумах FileZilla, очистите "кэшированные сертификаты", переименовав trustedcerts.xml (%APPDATA%\FileZilla\trustedcerts.xml) и разрешив программному обеспечению клиента FileZilla его воссоздать.
5. Обновил программное обеспечение клиента FileZilla до последней версии.

Я перекрестно опубликовал эту информацию на странице форумов FileZilla, но, поскольку я знаю, что проблемой может быть клиентское программное обеспечение, что-то в сети пользователя или даже что-то на моем сервере, я хотел немного расширить сеть. На данный момент, я не уверен, что еще посмотреть, и я надеюсь, что кто-то может, по крайней мере, указать мне в правильном направлении. Я склоняюсь к тому, что в сети пользователя может вызвать проблему, но я хочу попытаться получить некоторые доказательства этого, прежде чем я буду "обвинять" другой ИТ-отдел. Любая помощь, которую вы можете предоставить, будет принята с благодарностью.

ОБНОВЛЕНИЕ: я подключился к рабочей станции моего клиента и проверил пункты, предложенные @Martin Prikryl в комментариях. Я обнаружил, что клиент использует управляемую доменом установку программного обеспечения Webroot SecureAnywhere® Business Endpoint Protection . Они все еще не могут подключиться, поэтому на этот раз я скопировал информацию о регистрации из главного окна FileZilla Client :

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

Также я сравнил детали сертификата между его машиной и моей. Вот скриншот моего диалогового окна " Сведения о сертификате" :

И вот скриншот его диалога Сведения о сертификате :

Я отредактировал URL-адреса в изображениях, но все они совпадают. Однако, если взглянуть на значения отпечатков пальцев и детали блока выдачи сертификатов , очевидно, что есть некоторые расхождения. Я заставил пользователя временно отключить защиту Webroot (к счастью, кто-то из его ИТ-отдела помог нам) и попытался снова. К сожалению, возникла та же проблема, и когда я снова проверил сертификат, он все еще показал те же несоответствия по сравнению с тем, что указан на моем компьютере.

Их ИТ-специалист также попытался установить соединение с новой установкой клиентского программного обеспечения FileZilla на другой ПК в той же сети. Это соединение привело к той же ошибке. Я предложил возможность настройки программного обеспечения FileZilla Client на ноутбуке, подключенном к другой сети (например, в точке доступа WiFi сотового телефона), чтобы проверить, сохраняется ли проблема, но у них еще не было возможности сделать это.

Наш сертификат SSL является сертификат COMODO PositiveSSL, так что теперь мне просто нужно , чтобы определить , что является причиной его системы / сети , чтобы быть собирание эмитента в качестве Fortinet.

EDIT: По прихоти, я создал новое соединение в моем клиенте FileZilla , где я явно указанный IP - адрес из журнала подключения пользователя я написал выше, просто чтобы быть уверенным , что не было ничего другого о том , как я соединительном. Я не получил никаких ошибок, и мой диалог сведений о сертификате показывает то же самое, что и раньше (за исключением того, что хост указан в качестве IP-адреса вместо DNS-имени). Вот журнал из моей последней сессии:

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...

ОБНОВЛЕНИЕ № 2: Мне только что перезвонил клиент, который сообщил мне, что его ИТ-отдел нашел причину проблемы и внес внутренние изменения, чтобы заставить его соединение работать. Вот резюме:

Более года назад наша компания сменила IP-адрес нашего FTP-сервера. В то время мы разослали всем нашим клиентам и партнерам по электронной почте "взрыв", уведомив их об этом изменении. Очевидно, однако, что ИТ-отдел этого клиента не получил эту заметку, потому что он не распознал IP-адрес и не имел соответствующих правил в своем брандмауэре, чтобы разрешить этот трафик.

Тот факт, что он работал без ошибок более года, все еще немного озадачивает меня, но пока он работает сейчас, я собираюсь его отпустить (пока). Я опубликую резюме по устранению неполадок в качестве ответа позже, но я должен вернуться к работе.

Answer 1

В моем исследовании сообщения об ошибке « Первичное подключение и сертификаты подключения к данным не совпадают », сообщаемого программным обеспечением FileZilla Client , большинство решений указывают на неправильную настройку FTP-сервера. Хотя это, безусловно, допустимый "шаг" поиска и устранения неисправностей, необходимо изучить несколько дополнительных шагов, особенно если конечный пользователь мог успешно подключиться раньше.

Эта конкретная ошибка означает, что между программным обеспечением FileZilla Client и FTP-сервером установлено основное подключение к Интернету. Проблема не в подключении к FTP-серверу, а в согласовании шифрования связи SSL/TLS. (Выпуск) клиентского программного обеспечения FileZilla не позволит продолжить соединение TLS, если есть какие-либо сомнения относительно действительности сертификата SSL.

Следующие шаги по устранению неполадок должны помочь определить и / или устранить причину ошибки или, по крайней мере, устранить некоторые возможности:

УСТРАНЕНИЕ НЕИСПРАВНОСТЕЙ КЛИЕНТА

1. Проверьте параметры подключения клиента FTP, в том числе:
   • Имя хоста /IP и порт
   • Варианты SSL /TLS
   • Информация для входа на FTP-сервер (имя пользователя / пароль)
   • Тип сервера
   • Режим передачи (активный / пассивный)
2. Проверьте / очистите любую кэшированную информацию сертификата на клиентском компьютере.
   • В клиентском программном обеспечении FileZilla это делается путем удаления / переименования файла XML, в котором хранятся эти сертификаты (%APPDATA%\FileZilla\trustedcerts.xml)
3. Убедитесь, что программное обеспечение клиента FTP обновлено. Возможно, что другие изменения (обновления FTP-сервера, изменения конфигурации сети, обновления программного обеспечения безопасности и т.д.) Могут вызывать проблемы в связи.
4. Если FTP-клиент находится в локальной сети, попробуйте подключиться с другого компьютера в той же сети. Если этот другой компьютер может подключиться, проблема связана с одним (или несколькими) компьютерами.
5. Попробуйте отключить любое программное обеспечение безопасности, установленное на клиентском компьютере. Некоторые A / V или другие приложения Internet Security могут действовать как "посредник", который может мешать взаимодействию между клиентом FTP и сервером FTP.
6. Если возможно, попробуйте использовать другое интернет-соединение для доступа к FTP-серверу.
   • "Самый простой" способ проверить это - включить точку доступа WiFi на моем мобильном телефоне и подключить ноутбук к этой сети.
7. Если FTP-клиент находится за брандмауэром, убедитесь, что этот брандмауэр не блокирует и иным образом не вмешивается в трафик FTP. В зависимости от брандмауэра это может означать открытие портов на брандмауэре, внесение в белый список IP-адреса FTP-сервера или другие параметры конфигурации.

ЕСЛИ ВЫ УПРАВЛЯЕТЕ FTP-СЕРВЕРОМ

Конечно, в зависимости от используемого программного обеспечения FTP-сервера, вам может потребоваться / захотеть проверить огромное количество вещей. Я просто перечисляю здесь "основы".

1. Проверьте журналы FTP-сервера на наличие дополнительных сведений о сбое подключения.
2. Убедитесь, что срок действия SSL-сертификата, установленного на FTP-сервере, не истек и все еще действителен.
3. Просмотрите параметры конфигурации SSL/TLS на FTP-сервере.
4. Проверьте общедоступные (и / или внутренние) DNS-записи и конфигурацию, указывающую на FTP-сервер.
5. Убедитесь, что на FTP-сервере нет заблокированных / занесенных в черный список пользователей по имени пользователя или IP-адресу. Это может также (возможно) включать такие вещи, как учетная запись пользователя, требующая обновления / сброса пароля, или другие внутренние параметры безопасности.

ЕСЛИ ВЫ НЕ УПРАВЛЯЕТЕ FTP-СЕРВЕРОМ

Обратитесь к лицу / компании, отвечающей за FTP-сервер. Предоставьте им результаты устранения неполадок на стороне клиента, чтобы помочь администратору (-ам) в устранении неполадок при завершении соединения.

• ПРИМЕЧАНИЕ. Поскольку FileZilla является проектом с открытым исходным кодом, можно получить исходный код и изменить его так, чтобы программное обеспечение игнорировало эту потенциальную опасность. Объяснение того, что нужно сделать, находится на форумах FileZilla. Пожалуйста, обратите внимание, однако, что, в то время как я в том числе по этой ссылке, если вы не только с помощью этого программного обеспечения в очень контролируемой среде, я не рекомендовал бы этот шаг.

В зависимости от локальной среды клиента могут быть предприняты и другие действия по устранению неполадок. Кроме того, если я пропустил что-то очевидное в моих действиях здесь, пожалуйста, прокомментируйте, чтобы я мог добавить это на случай, если кто-нибудь еще столкнется с этой проблемой.