Одне спільне ім’я, два сертифікати: список дозволених чи відкликання?

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

Почніть із політики іменування, яку використовує сервер

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

Прочитайте конфігурацію сервера й занотуйте, яке джерело ідентичності використовується. username-as-common-name робить автентифіковане ім’я користувача чинним ім’ям для пошуку за конкретним клієнтом. Без нього використовується спільне ім’я суб’єкта із сертифіката. Якою б не була відповідь, запишіть її, перш ніж торкатися будь-якого списку дозволених.

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

Перевірте, що насправді допускає клієнта

Пов’язаний із відповідним файлом client-config-dir надає параметри для конкретного клієнта; сам по собі він не є правилом допуску. Для допуску за ім’ям потрібен ccd-exclusive, який відмовляє клієнтам без відповідного файлу. Увімкнення цього в робочому розгортанні відключає всіх, чиє ім’я не має файлу, тож порахуйте файли, перш ніж щось перемикати.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

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

Потім переконайтеся, що кожне ім’я файлу точно відповідає чинній ідентичності, включно з регістром і пробілами. Файл для office-laptop нічого не робить для сертифіката, суб’єкт якого читається як Office-Laptop. Пробіли в кінці теж ховаються від звичайного переліку, і саме так файл, який виглядає наявним, залишається непрочитаним.

Перевірте CRL, яку завантажує шлюз

CRL називає відкликані сертифікати за видавцем і серійним номером, і це та деталізація, якої бракує перевірці імені. Два сертифікати можуть мати спільне ім’я й різнитися серійним номером, і лише список на рівні серійного номера розділяє їх.

Підтвердьте налаштований шлях, дату випуску та поле наступного оновлення, перш ніж взагалі довіряти файлу.

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

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

Замініть, потім доведіть обидва результати

Випустіть заміну під тим самим спільним ім’ям, зафіксуйте обидва серійні номери й лише тоді відкличте старий. Такий порядок зберігає робочу ідентичність доступною, поки ви готуєте зміну.

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

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

Чого перевірка імені не може ніколи

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

Там, де потрібен контроль на рівні сертифіката, використовуйте механізм, який називає сертифікат: записи CRL або хук перевірки, що звіряє відбиток, який підтримує оператор. Обидва потребують обслуговування, і обидва чесні щодо об’єкта, який перевіряють. посібник OpenVPN 2.6 документує crl-verify і допуск для конкретного клієнта як окремі параметри, саме з цієї причини.

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