TLS 1.0 и 1.1 на старых серверах: как пережить legacy-клиента и не ослабить всю систему
Старые инструкции часто предлагают просто понизить системную crypto policy, когда приложение не подключается из-за TLS 1.0 или 1.1. Это быстрый, но плохой путь: ради одного legacy-клиента вы ослабляете все сервисы, которые используют системные криптографические настройки.
Сначала найдите виновника
Определите, какой клиент или сервер требует старый TLS. Проверьте журналы, договоритесь о тестовом соединении и зафиксируйте поддерживаемые версии протокола. Не меняйте глобальную политику на основании одной общей ошибки handshake.
Лучший вариант — обновить конечную систему
Если можно обновить приложение, библиотеку, прошивку или ОС, это почти всегда лучше, чем возвращать TLS 1.0/1.1. После обновления проверьте TLS 1.2 или 1.3 и удалите временные обходные настройки.
Когда обновить нельзя
Изолируйте legacy-сервис: отдельный reverse proxy, отдельная виртуальная машина, VLAN или строго ограниченный listener. Старый протокол должен существовать только на минимально необходимом участке, а не становиться новой политикой всего сервера.
Контролируйте доступ
- ограничьте исходные IP;
- не публикуйте legacy-listener в интернет без необходимости;
- включите журналирование подключений;
- создайте срок, когда обходное решение должно быть удалено;
- не смешивайте старый TLS с административными интерфейсами.
CentOS 8 и старые рецепты
Старые статьи про CentOS 8 часто завязаны на конкретные crypto policies и версии OpenSSL. Для нового сервера этот рецепт не нужен: выбирайте поддерживаемую ОС и решайте совместимость на уровне конкретного приложения или выделенного прокси.
Итог: задача не в том, чтобы «включить TLS 1.0», а в том, чтобы временно обеспечить совместимость, не распространяя слабую криптографию на всю инфраструктуру.
