Установка ланцюжка серверів сертифікації
як частина впровадження PKI в домені
Частина 1
Microsoft рекомендує ретельно спланувати PKI, перш ніж приступати до дій з розгортання компонентів. Що стосується СА, то потрібно вирішити, чи буде використовуватися тільки свій власний центр сертифікації або ж доведеться вдаватися до послуг і відкритих (публічних) СА, таких як VerySign. Особливу роль має планування розташування, кількості і типу СА. Існує два основних типи СА: СА підприємства (enterprise CA) і ізольований СА (stand-alone CA). У свою чергу вони поділяються на два підтипи: кореневої (root) і підлеглий (subordinate). Тип СА визначає, де зберігається база сертифікатів (локально або в Active Directory), як видаються сертифікати (автоматично по шаблонах або вручну) і т. П. Крім того, котрий подає (issuing) називається СА, який обробляє запити кінцевих користувачів.
Вибір структури CA
Необхідно спланувати багаторівневу структуру СА. Теоретично можливе використання одного центру сертифікації одночасно в якості кореневого СА підприємства і видає одночасно, але така конфігурація настійно не рекомендується як з міркувань безпеки, так і з міркувань подальшої масштабованості.
Microsoft рекомендує використовувати число рівнів СА від 2 до 4: використання більш глибокої структури стає важким в управлінні.
Можна назвати «класичної» схему з трьох рівнів СА (див. Рис. 1):
- перший рівень: ізольований кореневої СА;
- другий рівень: ізольований підлеглий СА (ще він називається проміжним, (intermediate), або policy CA);
- третій рівень: підлеглий СА рівня підприємства, він же випускає СА.
Малюнок 1. Структура з трьох СА
Розгортання саме такої структури і буде розглядатися в цій статті. Що вона дає: ізольований СА першого рівня (RootCA) випускає самоподпісанний сертифікат сам собі і використовується в якості кореня структури. Ізольований підлеглий СА другого рівня (SubCA) отримує сертифікат від кореневого СА і використовується, по-перше, для посилення безпеки всієї структури, а по-друге, в разі, коли на другому рівні більше ніж один СА, для призначення різних операційних політик чи політик безпеки для CA нижніх рівнів. У розглянутій схемі введення проміжного другого рівня не є обов'язковим і використовується з метою приведення до «класичного» виду і для можливості маштабіруємостью надалі. За рекомендацією Microsoft з міркувань безпеки, СА перших двох рівнів повинні бути ізольовані від мережі, а після установки і первинної настройки - зберігатися в надійному, захищеному від доступу сторонніх місці в вимкненому стані. Виконання цієї вимоги може допомогти застосування віртуальних машин - використання VMware або Virtual Server ідеально підходить як для забезпечення безпеки на етапі розгортання інфраструктури, так і для подальшої фізичної ізоляції серверів.
І нарешті, підлеглий СА рівня підприємства (EntCA) отримує сертифікат від проміжного СА, знаходиться в домені Active Directory і випускає сертифікати за запитами кінцевих користувачів або в ручному, або в автоматичному режимі за шаблонами (рекомендується). Для відмовостійкості потрібно мати як мінімум два випускають СА на кожен проміжний СА, проте ми будемо розглядати установку тільки одного сервера.
Визначення функціональних параметрів для СА
Коли структура СА визначена, потрібно врахувати ще ряд важливих параметрів, що впливають на роботу кожного з СА. До таких параметрів належать:
Після вибору передбачуваних робочих параметрів кожного з СА можна перейти безпосередньо до їх установлення. Треба мати на увазі, що ім'я комп'ютера і доменну приналежність після установки служб сертифікації міняти вже буде не можна. Як доменного оточення будемо розглядати ліс, що складається з одного дерева і двох доменів. Домен Dedicated.Root є кореневої домен, домен Res.Dom - дочірній (ресурсний). Служби сертифікації на третьому рівні будемо розгортати на комп'ютері EntCA - члені домену Dedicated.Root.
Установка кореневого СА
Оскільки кореневої СА буде ізольований, то перед установкою переконайтеся, що комп'ютер не включений в домен, а також має ім'я, яке згодом не планується змінювати - в нашому випадку RootCA.
Далі треба підготувати спеціальний файл capolicy.inf, який повинен бути поміщений в% Systemroot%. Наявність цього файлу для установки кореневого СА дуже важливо, оскільки в ньому задаються всі вихідні параметри для СА. Більш того, майстер установки служб сертифікації не тільки не попередить вас про відсутність цього файлу, але і не буде перевіряти його коректність.
Відсутність файлу capolicy.inf або його неправильне конфігурація призведе до того, що СА буде встановлений з параметрами за замовчуванням, оскільки для нього немає батьківського СА, від якого можна було б їх успадкувати. Змінити деякі з них після установки буде неможливо, і, як наслідок, доведеться встановлювати заново служби сертифікації заново. Це не так страшно, поки СА єдиний в структурі, але практично неможливо після розгортання СА нижчих рівнів.
Значення параметрів в розділі [Certsrv_Server] повинні бути не менше, ніж ті, які будуть запитуватися майстром установки.
Як вже було сказано, кореневої СА видає самоподпісанний сертифікат, який не має списку відгуків. Тому дуже важливо розділи [CRLDistributionPoint] і [Authority InformationAccess] вказати в явному вигляді і залишити порожніми.
В результаті у нас виходить ось такий вміст файлу capolicy.inf:
Signature = "$ Windows NT $"
Також перед установкою служб сертифікації має сенс встановити служби Internet Information Services і підтримку ASP.NET. Для роботи кореневого і проміжного СА їх наявність зовсім не обов'язково, але це може дещо полегшити подальший випуск сертифікатів для СА нижніх рівнів, незважаючи на те що майже всі дії, доступні через веб-інтерфейс, можна продублювати і через консоль управління службами сертифікації.
На наступному кроці нас попросять вказати ім'я нашого СА і відмітне ім'я (distinguished name). В останньому випадку треба вказати правильне ім'я по відношенню до контексту Active Directory, незважаючи на те що цей СА не є СА рівня підприємства. Отже, в якості імені СА використовуємо RootCA, як відмітний імені вводимо DC = dedicated, DC = root. Значення Validity Period вказує на час життя сертифіката. Як було зазначено вище, термін служби для кореневого СА зробимо рівним в 20 років. Далі відбувається генерація кріптоматеріала, і потрібно трохи почекати закінчення цього процесу.
Заключним кроком є вказівка розташування файлів баз даних сертифікатів, журналів реєстрації та загальної папки для розташування інформації, необхідної для клієнтів (за замовчуванням це C: \ CAConfig). Незважаючи на те що це ізольований СА, все одно локальна папка буде створена і, в разі наявності мережевого інтерфейсу, відкрита для загального доступу.
Перевірка і настройка RootCA
Малюнок 2. самоподпісанного сертифікат кореневого СА
Що повинно бути в сертифікаті:
- на вкладці General: значення полів Issued by і Issued to повинні збігатися і вказувати на тільки що встановлений СА (в нашому випадку це RootCA). Діапазон часу, протягом якого сертифікат вважається дійсним, повинен бути вірний і відповідати тому, що задавали при установці;
- на вкладці Details: в переліку атрибутів сертифіката мають бути відсутні атрибути CRL Distribution Points і Authority Information Access;
- на вкладці Certification Path: в нижньому полі повинна бути напис This certificate is OK.
Подивитися сертифікат можна і іншим методом - скористатися оснащенням Certification Authority, яка доступна в розділі Administrative Tools панелі управління.
Після її запуску повинно автоматично статися підключення до поточного сервера, при цьому в дереві зліва він повинен бути позначений зеленою галочкою. Клацнувши на ньому правою кнопкою миші і вибравши Properties на вкладці General, можна виявити кнопку View Certificate. Цей метод краще, так як відразу дозволяє переконатися в тому, що служби сертифікації успішно запустилися, інакше виникла б помилка підключення до СА. До того ж саме тут ми і продовжимо конфігурація СА і перейдемо до вказівкою точок розповсюдження CRL і AIA.
Нагадаю ще раз про важливість CRL для перевірки дійсності сертифіката. Задати точки розповсюдження CRL (CRL Distribution Points - CDP) можна перейшовши на вкладку Extensions (Розширення) у вікні властивостей СА. Список, що випадає у верхній частині вікна містить лише два параметри: CRL і AIA. Залишимо запропонований за умовчанням CRL і звернемося до наступного поля, де перераховані місця розташування для CRL.
Тут треба бути дуже обережним - по-перше, зазначені тут точки розповсюдження CRL можуть включатися в усі видаються цим СА сертифікати. Тобто теоретично можливо змінити або доповнити цей список і після того, як СА почне працювати, на практиці ж це буде означати необхідність перевипустити всі сертифікати, які були випущені до того, як цей список змінився.
По-друге, відсутність CRL означає недійсність сертифікату, тому треба передбачити як мінімум два різних місця розташування CRL.
По-третє, не рекомендується залишати в списку невикористовувані точки розповсюдження.
Крім того, до кожної з CDP можна вказати додаткові опції:
Повернемося до завдання точок розповсюдження CRL. Оскільки наш СА буде відключений від мережі, то необхідно залишити локальну точку поширення, яка йде в списку першої і за замовчуванням вказує в папку C: \ WINDOWS \ system32 \ CertSrv \ CertEnroll \. Зверніть увагу, що для цієї CDP позначена опція Publish CRL in this location. Для забезпечення доступності CRL ми залишимо також LDAP-точку (вказавши опції Include in all CRLs і Include in the CDP extension of issued certificates) і створимо нову точку, яка вказує на загальну мережеву папку в локальній мережі (з опцією Include in the CDP extension of issued certificates). В якості такої папки введемо UNC-шлях до спільної папки, яку розташуємо згодом на нашому майбутньому СА рівня підприємства з ім'ям EntCA: file: // \\ Ent_CA \ CDP \
Малюнок 3. Завдання CDP на кореневому СА
Малюнок 4. Завдання точок AIA
Тепер можна натиснути ОК і погодитися з тим, що служби сертифікації повинні бути перезапущени.
Однак перш ніж можна буде публікувати CRL, треба зробити відображення простору імен Active Directory в реєстр СА. Це потрібно для того, щоб зазначені нами LDAP CDP були представлені в коректній формі. Робиться це за допомогою команди certutil.exe і для домену Dedicated.Root виглядає наступним чином:
certutil.exe -setreg ca \ DSConfigDN CN = Configuration, DC = dedicated, DC = root
Результат повинен бути приблизно таким: