Проєктування шаблонів AD CS для ролей VPN-шлюзу та клієнта

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

Напишіть таблицю ролей до відкриття консолі шаблонів

Дві ролі, два призначення. Шлюз доводить ідентичність служби, тому його сертифікату потрібні Server Authentication (1.3.6.1.5.5.7.3.1), використання ключа для цифрового підпису й шифрування ключа, а також ім'я вузла, до якого підключаються клієнти, в альтернативному імені суб'єкта. Клієнтам, які автентифікуються сертифікатами, потрібні Client Authentication (1.3.6.1.5.5.7.3.2) та ідентичність, що збігається з тим, що шлюз очікує під час перевірки іншої сторони. Сертифікат користувача й сертифікат комп'ютера не взаємозамінні, бо вони живуть у різних сховищах і використовуються різними процесами.

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

Копіюйте шаблон, а не редагуйте спільний

Почніть із шаблону з приблизно правильним призначенням, наприклад RAS and IAS Server для шлюзу або Computer для пристроїв, приєднаних до домену, потім скопіюйте його й дайте копії ім'я, що каже, для чого вона. Розширення шаблону, який уже використовують інші служби, — це зміна, яка через шість тижнів зламає щось не пов'язане. У копії задайте політики застосування за призначенням із таблиці ролей, збережіть узгодженість використання ключа, виберіть алгоритм і довжину ключа, які приймають ваші шлюзи, і позначте приватний ключ як неекспортований, якщо пристрою не потрібно експортувати його для переміщення.

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

Вирішіть, звідки береться суб'єкт

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

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

Опублікуйте шаблон, потім звузьте дозволи

Створення об'єкта шаблону в AD DS і його публікація на CA, що видає, — окремі операції, які виконуються в різних консолях. Опублікуйте копію з консолі Certification Authority у розділі Certificate Templates, потім з командного рядка перевірте, що CA тепер її пропонує:

certutil -CATemplates
certutil -TCAInfo

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

Зареєструйте одного пілота в реальному споживачі

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

certlm.msc
certutil -dump vpn-gateway.cer

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