неподдерживаемое назначение сертификата: почему промежуточный CA не проходит

Назначение серверного сертификата выглядит правильным, ключ совпадает, даты в порядке, а соединение по-прежнему завершается ошибкой unsupported certificate purpose. Подробность, которая это решает, обычно находится в той же строке, что и ошибка: значение глубины и subject, называющие сертификат выше в цепочке. Выполняются две разные проверки, и только одна из них касается конечного сертификата. Их сравнение объясняет, почему замена серверного сертификата ничего не меняет.

Какой сертификат проверяющий действительно отклонил

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

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

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

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

Назначение конечного сертификата и политика цепочки — две проверки

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

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

Отсутствующий EKU — не ограничивающий EKU

RFC 5280 делает расширение расширенного использования ключа необязательным и, при наличии, ограничивающим. Поэтому сертификат CA без расширения не сказал «нет» аутентификации сервера, тогда как сертификат, перечисляющий только постороннюю цель, сказал нечто весьма конкретное. Обращение с этими двумя состояниями как с равнозначными даёт неверный диагноз и, что хуже, неверное исправление. Различие также объясняет, почему два центра, похожие в консоли, ведут себя совершенно по-разному в цепочке.

Поведение библиотек здесь тоже не единообразно. документ OpenSSL о параметрах проверки описывает собственную трактовку проверок назначения для сертификатов CA, и эта трактовка является политикой реализации, а не правилом, которому все стеки TLS следуют одинаково. Опишите, что делает ваш проверяющий, и подтвердите это на той версии, которую вы действительно запускаете.

Воспроизведите сбой офлайн, прежде чем перевыпускать

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

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

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

Исправляйте политику выпуска, а не вызов проверки

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

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