Чому два сертифікати OpenVPN можуть спільно використовувати одну політику CCD

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

Сервер визначає ім'я, а не серійний номер

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

Так перевірка унікальності на боці CA проходить, хоча VPN усе одно стикається. Дві перевірки відповідають на різні питання.

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

Яке ім'я зіставлення насправді використовує

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

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

Що б не створювало зіставлення, саме це значення й треба резервувати. Резервувати спільні імена в CA, коли сервер спирається на імена користувачів, означає резервувати не те.

Два CA можуть схвалити одне й те саме ім'я

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

Ті самі міркування стосуються CA, яка вимагає унікальності повного суб'єкта, а не унікальності спільного імені.

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

Поновлення — це зарезервоване повторне використання, а не колізія

Поновлення, яке зберігає ім'я, — це навмисне повторне використання, і реєстр має сказати це простими словами. Запишіть старий і новий відбитки під одним ім'ям, щоб рецензент міг відрізнити заміну від захоплення. Параметр duplicate-cn сервера тут ні до чого: він керує одночасними сеансами, а не реєстрацією чи резервуванням імен. Вирішіть, як довго можуть існувати обидва облікові дані та коли старі перестають прийматися.

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

openssl x509 -in device42.crt -noout -subject -serial -issuer

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