Два сертифікати OpenVPN, одне ім'я CCD: що пішло не так

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

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

Ваші інструменти для сертифікатів не попередять вас, бо унікальність усередині X.509 і унікальність імені політики OpenVPN — це різні вимоги, які забезпечують різні системи.

Сервер шукає ім'я, а не відбиток

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

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

Де два органи сходяться на одному імені

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

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

Документація OpenSSL CA описує параметр unique_subject, який керує думкою її власної бази даних, і чесна відправна точка — прочитати свою конфігурацію видачі, а не припускати, що діє якесь конкретне типове значення EasyRSA чи OpenSSL.

Зарезервуйте чинне ім'я до підпису

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

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

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

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

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

Підтвердьте зіставлення інструментами на машині

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

openssl x509 -in device42.crt -noout -subject -nameopt sep_multiline
ls -l /etc/openvpn/ccd/device42
grep -n "duplicate-cn" /etc/openvpn/server.conf

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

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