RFC 4217 описывает согласование TLS для FTP. Он отдельно рассматривает защиту управляющего соединения и данных. Поэтому фраза «вход по TLS успешен» не достаточна для вывода, что сам файл передан защищенным способом.

Серверный режим и клиент должны совпадать

Запросите точный способ подключения, назначение и условия защиты обеих частей обмена. Не выбирайте режим по одному знакомому порту из чужой инструкции. Этот текст не назначает универсальный порт или набор шифров всем услугам.

ПроверкаЧто подтвердить
РежимУсловия, поддерживаемые обеими сторонами
СертификатИмя, доверие, цепочку и срок
УправлениеРазрешенную защищенную сессию
ДанныеЗащиту и результат выбранной передачи
ФайлыСогласованное назначение и сохранность старого

Документ 2005 года используется для модели FTP/TLS, не как утверждение о рекомендуемых версиях защиты сегодня. Конкретные поддерживаемые параметры клиента и сервера надо сверять отдельно.

Не обходите ошибку сертификата

Для идентификатора есть SAN, для общей защиты - TLS. Если клиент предупреждает об имени или доверии, сначала выясните причину. Не отключайте проверку только ради появления списка файлов.

Также не считайте SFTP другим названием FTPS. Его транспорт SSH имеет свою модель проверки стороны. Для исходной двухсоединительной модели есть FTP.

Приемка без рабочих клиентских данных

Согласуйте маленький контрольный набор, разрешенного пользователя, направление и критерий результата. Сохраните безопасные сведения о соединениях. Не выкладывайте секреты, сертификатные ключи и дампы заказов в отчет.

Источник прочитан 7 октября 2026 года. Службы, TLS-параметры, доверие, порты и файлы не менялись; тестовая передача для статьи не выполнялась. Подготовьте правила возврата до рабочей операции, а значения неизвестных условий оставьте неизвестными. Определения собраны в словаре.