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 Web Server, тож сертифікат партнера справді має заявляти цю мету. Сертифікат, виданий для автентифікації клієнта, не задовольняє її, навіть якщо обидва підписані тією самою установою.
Це важливо, бо спільний 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Якщо розширення показують роль сервера, а журнал усе ще повідомляє про збій ролі, профіль, імовірно, вказує на неправильний файл сертифіката, а не на поганий сертифікат. Якщо розширення показують лише автентифікацію клієнта, припиніть дивитися на клієнт і виправте видачу. У будь-якому разі відновіть перевірку, перш ніж назвати з’єднання здоровим, бо успішне рукостискання після видалення перевірки доводить менше, ніж помилка, яку воно замінило.