Примітка: перед проведенням будь-яких змін, що описуються в цій статті, обов'язково виконайте бекап.
Більшість адміністраторів при установки ролі Active Directory Certificate Services (AD CS) роблять дуже просто Next -> Next ->. -> PROFIT. З одного боку це і добре, але часто це не дуже добре. Чим це добре - воно буде працювати. Чим це погано - при появі якихось специфічних умов (наприклад, зовнішні по відношенню до поточного лісі клієнти) воно починає працювати гірше і навіть перестає бути працездатним. Сьогодні я планую розглянути ці питання, як нестанадртние клієнти (які не підтримують LDAP) і зовнішні клієнти, тим більше це досить поширений сценарій.
Найперша рекомендація буде полягати в тому, що не треба встановлювати службу IIS на сервер CA (крім випадків, коли у вас в мережі всього один сервер). При установці ролі AD CS майстер пропонує встановити IIS для роботи HTTP посилань на CRT і CRL файли. Я вважаю, що при наявності внутрішнього і / або зовнішнього веб-сервера встановлювати ще один на сервер CA - затія дурна. Ви цим самим просто додаєте собі зайвої роботи і не вирішуєте деяких завдань. Установка нової ролі збільшує площу атаки для зловмисників, забирає час адміністраторів, підвищує витрати на організацію захисту IIS і не вирішує питання обслуговування зовнішніх клієнтів, оскільки публікація сервера CA в інтернет (хоч і тільки ролі IIS. При успішній атаці ролі можна отримати контроль над усім сервером ) ідея настільки дурна і невдала, що її розглядати немає ніякого бажання. Я взагалі вважаю, що на сервері CA крім ролі CA нічого бути не повинно. Тому при установці ролі CA розсудливо відмовляємося. Замість цього ми будемо використовувати виділений веб-сервер, який швидше за все встановлений у вашій компанії. При цьому він може працювати під управлінням будь-якої ОС, хоч лінупса. Про це буде написано трохи нижче.
Ми вже розглядали загальну проблематику питання в одному з попередніх постів: CRL Distribution Points і Authority Information Access. З причин описаним в зазначеному пості ми похмуро випилюємо всі посилання на LDAP.
- Необхідні кроки для випадків свіжої інсталяції ролі CA вироблені ДО випуску першого сертифікату.
Цим кроком ми скасуємо використання LDAP посилань, які можуть бути зовсім не придатні для ряду типів клієнтів, як мобільні клієнти, клієнти з інтернету, клієнти робочих груп, інших лісів і т.д. А так же видалили дефолтні HTTP посилання, які вказують на сервер CA.
- Необхідні кроки для випадків, коли сервер CA вже випустив сертифікати.
Для цього запустіть оснащення CertSrv.msc, виберіть властивості CA і перейдіть на вкладку Extensions. У цій вкладці перейдіть до прямої адреси, що починається з LDAP: //. Зніміть всі галочки, крім Publish CRLs to this location і Publish Delta CRLs to this location (якщо ви плануєте використовувати Delta CRL). А так же видаліть посилання HTTP, які вказують на сам сервер CA. Збережіть зміни і запустіть службу Certificate Services.
Цим кроком ми відключили публікацію LDAP і HTTP посилань у знову видаються сертифікати. Однак, у нас вже працює інфраструктура PKI, отже, раніше випущені сертифікати містять посилання на LDAP. Для забезпечення їх працездатності ми продовжуємо публікацію CRT / CRL файлів в LDAP.
Невеликий вбросік. Я думаю, що багато хто помічав як іменуються файли. Наприклад, дефолтний CRT має ім'я наступного формату:
Те ж саме буде стосуватися і CRL. Відповідно до параграфа § 3.2.5.1.6 специфікації протоколу [MS-CSRA]:
1.When this method is invoked, the CA SHOULD create a new base and / or delta CRL for each CA key, as specified in the following steps 2, 3, 4, 5, 6, and 7. The type of CRL to create (base, delta, or both) for each CA key is determined as follows:<38>
The CA SHOULD create a new base CRL for each CA key.
If the CA has enabled delta CRLs, as indicated by a nonzero Config_Delta_CRL_Validity_Period value, the CA MUST create a new delta CRL in addition to a new base CRL, for each CA key.
If delta CRLs are currently disabled (Config_Delta_CRL_Validity_Period is 0) and were enabled previously (Previous_Delta_CRL_Validity_Period is not equal to zero), the CA MUST create a new delta CRL in addition to a new base CRL for each CA key.
На веб-сервері створіть папку з довільним ім'ям (наприклад, з ім'ям pki), в якій будуть зберігатися наші файли. Расшарьте цю папку і додайте в неї права записи для облікового запису комп'ютера, на якому працює сервер CA. При цьому врахуйте, що права необхідно відредагувати як на рівні NTFS Rights і Share Permissions. В принципі, права Create files / Write data цілком достатньо для даного завдання. В IIS в довільному веб-сайті створіть віртуальну директорію і в якості шляху до неї вкажіть папку, в якій зберігаються CRT / CRL файли.
Оскільки ми будемо публікувати файли на виділений веб-сервер, ми повинні відредагувати розширення відповідним чином. Запустіть оснащення CertSrv.msc, виберіть властивості CA і перейдіть на вкладку Extensions. Натисніть кнопку Add і в поле Location вкажіть шлях виду:
Я виділив обов'язкову складову імені CRL файлу. Інше вже на ваш смак. І встановити чек-бокси на Publish CRLs to this location і Publish Delta CRLs to this location (якщо ви плануєте використовувати Delta CRL). Якщо Delta CRL на сервері CA використовуватися не буде,
Тепер треба додати посилання, яка буде публікуватися в видаються сертифікати. Для цього додайте нову посилання HTTP, яка буде вказувати на веб-сервер, наприклад:
І поставте галочки: Include in the CDP extensions of issued certificates і Include in CRLS. Clients use this to find Delta CRL Locations (якщо використовується Delta CRL).
Те ж саме зробити для розширення AIA, щоб отримати посилання виду:
І поставити галочку навпроти Include in the AIA extension of issued certificates. Як я вже говорив, не представляється можливим автоматично публікувати CRT в нестандартні локації, тому їх доведеться перейменувати вручну.
Примітка: імена фізичних файлів повинні бути ідентичними імені в HTTP посиланням.
В принципі, в кінцевому підсумку ви повинні отримати приблизно такий вигляд посилань і встановлених галочок:
CDP - нова інсталяція
C: \ WINDOWS \ system32 \ CertSrv \ CertEnroll \
Publish CRLs to this location
Publish Delta CRLs to this location
file: // \\ WebServerName \ pki \ Company_RCA
Publish CRLs to this location
Publish Delta CRLs to this location
CDP - успадкована інсталяція
C: \ WINDOWS \ system32 \ CertSrv \ CertEnroll \
Publish CRLs to this location
Publish Delta CRLs to this location
Примітка: не слід видаляти цей шлях, оскільки він використовується самим сервером CA.
file: // \\ WebServerName \ pki \ Company_RCA
Publish CRLs to this location
Publish Delta CRLs to this location
ldap: /// CN =
Publish CRLs to this location
Publish Delta CRLs to this location
AIA - нова і успадкована інсталяції
C: \ WINDOWS \ system32 \ CertSrv \ CertEnroll \
немає галочок. Залишається без змін.
Я не закликаю відразу кидатися і все переробляти. Ці рекомендації були направлені тільки для розуміння суті проблеми і яким чином її можна вирішити. З їх допомогою при необхідності можна самостійно підготувати план зміни розширень CDP і AIA.