remote-cert-tls server: что проверяет эта директива в профиле OpenVPN
Директива проверяет роль, закодированную в сертификате партнёра, а не его имя. Сравните роль, якорь доверия и проверку имени хоста, прежде чем что-либо отключать.
На три разных вопроса отвечают три разные части профиля OpenVPN, и именно их смешение приводит к тому, что люди в итоге отключают проверку, которая работала. Подписан ли сертификат партнёра тем удостоверяющим центром, которому я доверяю? Объявляет ли этот сертификат роль сервера TLS? Это тот самый сервер, до которого я хотел добраться? remote-cert-tls server отвечает только на средний вопрос, и делает это, читая расширения внутри сертификата.
Три проверки, которые легко смешать в голове
Якорь доверия живёт в директиве ca. Проверка роли относится к remote-cert-tls. Проверка личности относится к verify-x509-name, когда профиль её использует, или к любой проверке имени, которую добавляет развёртывание.
Они покрывают разные отказы:
| Question | Directive | Failure it catches |
|---|---|---|
| Who signed this? | ca | Certificate from an unrelated authority |
| Is this a server? | remote-cert-tls | Client certificate presented by a peer |
| Is this my server? | verify-x509-name | Another valid server from the same CA |
У профиля могут быть все три, и он всё равно останется слабым, если CA разделён слишком широко, а это вопрос управления ключами, а не директивы.
Что читает проверка роли
Директива — это макрос. Она разворачивается в требование использования ключа и требование расширенного использования ключа с указанием роли веб-сервера TLS, поэтому сертификат партнёра должен действительно объявлять эту цель. Сертификат, выданный для аутентификации клиента, этому не соответствует, даже если тот же центр подписал оба.
Это важно, потому что общий CA часто встречается в небольших развёртываниях. Один центр подписывает каждого клиента и сервер, и без проверки роли любой из этих сертификатов мог бы завершить серверную сторону рукопожатия. Проверка не делает такой сценарий невозможным, но убирает его тривиальную версию.
Директива асимметрична по замыслу: клиенты несут remote-cert-tls server, а серверы несут remote-cert-tls client. Поменяйте их местами, и каждое соединение будет падать с ошибкой роли, которая выглядит как сломанный сертификат.
Старые профили иногда используют ns-cert-type для той же цели. Текущие страницы руководства считают этот параметр заменённым, поэтому профиль, который всё ещё полагается на него, стоит переносить, а не отлаживать.
Почему отключение кажется исправлением
Когда проверка роли не проходит, соединение останавливается с ошибкой проверки, и очевидный шаг — удалить строку. Затем соединение поднимается, что кажется прогрессом и на самом деле является тем режимом отказа, который директива должна предотвращать. Теперь вы принимаете партнёра, сертификат которого никогда не предназначался для этой роли.
Вместо этого прочитайте ошибку. Она называет проверку, которая не прошла, а сертификат на другой стороне можно исследовать, чтобы увидеть, какие расширения он действительно несёт. Две минуты чтения решают, в выпуске проблема или в конфигурации. Догадки стоят половины дня и обычно заканчиваются ослабленным профилем. Обновлённый серверный сертификат, потерявший расширенное использование ключа, — это настоящая ошибка при продлении, а не повод ослаблять клиент.
Проверка имени — отдельная директива
Выполнение проверки роли говорит, что партнёр — какой-то сервер, подписанный вашим центром. Она ничего не говорит о том, какой именно, а это важно, когда один и тот же CA выпускает сертификаты для нескольких шлюзов и один из них скомпрометирован или перепрофилирован.
verify-x509-name сравнивает субъект сертификата со значением, которое вы настраиваете, с режимами сопоставления для точного субъекта, префикса или одного поля. Используйте поле, которое действительно идентифицирует шлюз, и ожидайте, что будете осознанно обновлять его при смене имени.
Ни одна из директив не заменяет хорошее обращение с ключами. Если файл ключа клиента копируется вместе с профилем, идентичность партнёра настолько же сильна, насколько широк список распространения.
Изучите сертификат, прежде чем редактировать профиль
Прочитайте сертификат партнёра и журнал клиента, именно в этом порядке. Сертификат сообщает, какие роли он объявляет; журнал сообщает, какая проверка его отклонила.
Эти команды выводят расширения использования и строки проверки из подробного соединения:
openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verifyЕсли расширения показывают роль сервера, а журнал всё ещё сообщает об ошибке роли, профиль, вероятно, указывает на неправильный файл сертификата, а не на плохой сертификат. Если расширения показывают только аутентификацию клиента, перестаньте смотреть на клиент и исправьте выпуск. В любом случае восстановите проверку, прежде чем называть соединение здоровым, потому что успешное рукопожатие после удаления проверки доказывает меньше, чем ошибка, которую оно заменило.