Використовуйте наявний корпоративний CA для пірів OpenVPN

Ніщо в OpenVPN не вимагає, щоб сертифікат походив з Easy-RSA, а парк, який уже має організаційну PKI, зазвичай не повинен будувати другу. Справжня робота — не вибір інструменту, а рішення про те, що означають видані ідентичності, яких пірів приймає тунель і як поновлення та відкликання доходять до перевіряча. Пройдіть п'ять кроків нижче по порядку, бо пізніший крок не може виправити рішення про роль, ухвалене в першому.

Видайте дві ролі замість однієї спільної ідентичності

Кожному піру потрібен власний сертифікат і відповідний приватний ключ. Попросіть команду PKI про серверну ідентичність із серверним використанням і окремі клієнтські ідентичності з клієнтським використанням, щоб тунель міг розрізняти їх під час рукостискання.

Спротивляйтеся скороченням, які з'являються під тиском термінів. Скопійований на ноутбуки ключ вебсервера стирає відмінність, на якій тримається перевірка ролі, а ключ підпису CA, встановлений на кінцевій точці VPN, перетворює один скомпрометований хост на скомпрометовану ієрархію. Пакет PKCS12 може нести ключ кінцевої точки та його ланцюг, але він ніколи не дає дозволу повторно використовувати цю ідентичність в іншій ролі.

Підключіть входи довіри на кожній стороні

Клієнту й серверу потрібні кожному якір довіри, власна ідентичність і явне очікування ролі. Фрагмент клієнта, у якому вказано всі три, виглядає так.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

Серверна сторона відображає це за допомогою remote-cert-tls client і власного сертифіката, і саме це заважає прийняти клієнтський сертифікат за сервер. Перевірка імені — окреме рішення від перевірки ролі. Прочитайте розгорнуту конфігурацію, щоб побачити, яке поле порівнюється, замість того щоб припускати збіг імені хоста в браузерному стилі. Обидві сторони також мають явно вказувати, якому видавцю вони довіряють, бо спільний шлях до файлу в усьому парку — не те саме, що спільна політика.

Доставляйте проміжні сертифікати, не розширюючи довіру

Двом сторонам не обов'язково ділити один ланцюг випуску. Коли пір подає сертифікат, підписаний проміжним, перевіряльна сторона потребує цього проміжного доступним, і OpenVPN розрізняє вхід якоря довіри від додаткових сертифікатів, які використовуються для завершення локально поданого ланцюга. Довідник параметрів TLS OpenVPN 2.6 документує обидва.

Проміжний CA сам собою не є проблемою, але широкий корпоративний корінь, кинутий у набір довіри, — проблема. Що ширший якір, то більше сертифікатів проходить тест ланцюга, і перевірка ролі не перетворює це на список уповноважених працівників. Звузьте якір до видавця, який справді підписує ідентичності VPN, там де ієрархія це дозволяє. Якщо не дозволяє, задокументуйте ширший якір як навмисно прийнятий ризик, а не залишайте його неявним.

Домовтеся з командою PKI про те, як поновлення й відкликання доходять до перевірячів VPN, зокрема які видавці важливі та хто публікує список. Точка розповсюдження CRL, вбудована в сертифікат, — це інструкція, а не доказ того, що щось її завантажило.

Вирішіть, як відкликання насправді надходить

crl-verify змушує перевіряча звертатися до файлу або кінцевої точки, і такий порядок потребує власника й шляху оновлення. Список, скопійований один раз під час розгортання, тихо перестає вас захищати при першому відкликанні сертифіката.

Запишіть очікуваний час поширення й перевірте його сертифікатом, який ви готові відкликати. Якщо список не можна оновити на хості VPN, альтернатива — коротший термін дії плюс процес поновлення, який справді виконується, а не припущення, що відкликання працює, бо існує URL.

Доведіть прийняття реальним клієнтом

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

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