OpenVPN клиент, который работал в прошлом месяце, теперь падает при запуске с ca md too weak, а профиль на диске байт в байт совпадает с тем, что работал. Сообщение касается подписи на сертификате удостоверяющего центра, а не шифра данных, auth-дайджеста или пароля учётной записи. Три условия решают, будет ли исправлением новый идентификационный материал, новая цепочка или сознательное изменение политики. Пройдите их по порядку, и вы избежите обычного исхода, когда туннель возвращается ценой ослабления каждого TLS-соединения на хосте.

Что на самом деле называет ошибка

OpenSSL поднимает эту ошибку проверки при построении цепочки, когда сертификат, действующий как CA, несёт дайджест подписи, который уровень безопасности библиотеки больше не принимает. MD5 отклоняется на уровне по умолчанию, а SHA-1 отклоняется, как только уровень повышается. Дайджест на листовом сертификате здесь менее важен, чем дайджест издателя, который его подписывает. Та же политика может отклонить корень, который в день выпуска был совершенно обычным.

Поэтому правка auth или data-ciphers ничего не даёт для этого сбоя. Эти настройки управляют тем, как пакеты защищаются после рукопожатия, а отвергнутый объект — это удостоверяющий документ, который проверяется до появления туннеля. Сертификат может спокойно находиться внутри окна действительности и всё равно нести подпись, которую библиотека не примет.

Держите проверки раздельно в голове, и ошибка перестанет казаться загадочной. Даты действия, использование ключа и дайджест подписи — независимые проверки, и ровно одна из них только что провалилась.

Условие первое: отвергнутый объект — это корень?

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

Объединённые файлы CA часто содержат несколько блоков, поэтому определите, какой блок действительно загружается, а не предполагайте, что виноват первый. Команда openssl x509 -in ca.pem -noout -subject -issuer -text описывает один сертификат за раз, то есть при наличии нескольких пакет нужно сначала разделить. Сравните напечатанный алгоритм подписи с дайджестом, который можно ожидать из эпохи создания корня.

Лист, подписанный SHA-256 под слабым корнем, всё равно падает, потому что проверка цепочки идёт до самого верха. Именно этот порядок делает следующее условие важным.

Условие второе: контролируете ли вы издателя?

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

Если цепочку выпустила третья сторона, исправление — запрос этому оператору, а единственное полезное локальное действие — перестать полагаться на старый материал. Правка текста PEM или пересохранение файла не меняет ничего из того, что покрывает подпись.

Один промежуточный случай заслуживает названия: внутренний корень, который старше нынешних значений по умолчанию, но всё ещё подписывает материал, которому доверяют другие системы. Его замена означает аудит каждого потребителя, включая устройства, закрепляющие старый сертификат по отпечатку. Сочтите этих потребителей до планирования изменения, потому что замена корня, пропустившая одного, меняет ошибку запуска на простой.

Условие третье: что ещё принимает понижение уровня

Понижение уровня безопасности или выбор устаревшего профиля сертификатов OpenVPN заставляет клиент снова принимать старый дайджест. Это также ослабляет другие проверки в той же библиотеке — для каждого соединения, которое делает этот процесс.

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

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

Решение, записанное как правило

Заменяйте цепочку, когда контролируете издателя и можете перечислить его потребителей. Обращайтесь к издателю, когда не контролируете. Понижайте уровень только как датированное, ограниченное исключение с уже запланированной заменой. Всё остальное оставляет тот же сертификат на месте и переносит риск туда, где его меньше видно.

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

Похожие статьи