Contents of this directory is archived and no longer updated.
Примітка: даний матеріал публікується як обов'язковий для знання IT-фахівцями, які займаються або тільки збираються займатися темою PKI (Public Key Infrastructure).
Як відомо, кожен виданий в CA сертифікат (крім самоподпісанного сертифікатів. Кореневий сертифікат так само є самоподпісанного сертифікатом) містить 2 розширення:
Ці посилання беруться не з повітря, а з налаштувань CA. Ось як вони виглядають для дефолтной інсталяції Certificate Services:
Ось як будуть виглядати розширення CDP і AIA в видаваних сертифікатах при таких налаштуваннях:
Як ви бачите, посилання в розширеннях розташовані в тому ж порядку, що і в настройках CA.
Це важливо знати, оскільки certificate chaining engine (скорочено назвемо його CCE) буде перевіряти посилання в тому порядку, в якому вони наведені в розширеннях сертифіката. Тобто спершу буде пробувати завантажити файл з Active Directory протягом 10 секунд. Якщо за 10 секунд файл не скочується, CCE намагатиметься завантажити вказаний файл за наступним посиланням (HTTP). При цьому часу на це буде відводитися в 2 рази менше (тобто 5 секунд), ніж в попередній спробі. І так буде відбуватися з кожною наступною посиланням, поки не буде здобутий файл, закінчаться посилання або відвалиться по таймаут. На обробку кожного розширення для CCE виділяється рівно 20 секунд.
За замовчуванням в Windows Server основні CRL (Base CRL) публікуються раз в тиждень і інкрементні CRL (Delta CRL) публікуються раз на добу. Файли сертифікатів CA зазвичай оновлюються через проміжки рівні часу життя сертифіката самого CA (або частіше, якщо сертифікат CA оновлюється позапланово). Якщо сертифікати CA потрібно оновлювати досить рідко (раз в декілька років) і до цього слід готуватися окремо, то оновлення CRL відбувається автоматично без втручання адміністратора і тут потрібні особливі коригування про які ми зараз і поговоримо.
Якщо подивитися на CRL, то ми побачимо наступне:
Зараз нас будуть цікавити тільки 3 поля:
Прімеченіе: час в цих полях вказується в форматі UTC без урахування тимчасових зон.
Для цього в реєстрі на сервері CA шляхом HKLM \ System \ CurrentControlSet \ Services \ CertSvc \ Configuration \ CA Name існує 4 ключа:
- CRLOverlapUnits - вказує час до закінчення терміну дії поточного основного CRL, за яке буде публікуватися новий основний CRL.
- CRLOverlapPeriod - вказує одиницю виміру цього часу для основного CRL
- CRLDeltaOverlapUnits - вказує час до закінчення терміну дії поточного інкрементального (якщо використовується) CRL, за яке буде публікуватися новий інкрементальний CRL
- CRLDeltaPeriodPeriod - вказує одиницю виміру цього часу для інкрементального CRL.
Якщо ви використовуєте LDAP посилання в розширеннях CDP / AIA сертифікатів і / або у вас є латентність реплікації файлів між веб-серверами, то ви повинні відрегулювати це час, який повинен бути не менше, ніж максимальний час реплікації каталогу AD в усьому лісі або DFS як для основних, так і для інкрементальних CRL (якщо вони у вас використовуються). Дану операцію можна автоматизувати утилітою certutil:
certutil -setreg ca \ CRLOverlapUnits 1
certutil -setreg ca \ CRLOverlapPeriod "days"
certutil -setreg ca \ CRLDeltaOverlapUnits 8
certutil -setreg ca \ CRLDeltaOverlapPeriod "hours"
net stop certsvc net start certsvc
[AuthorityInformationAccess]
Empty = true
[CRLDistributionPoint]
Empty = true
Зміна шляхів в уже існуючих інфраструктурах питання досить серйозний, хоч і простий в реалізації. Якщо ви зважилися на такий крок, то слід керуватися наступними правилами:
Спасибі, дуже цікаво. З приводу LDAP питання не такий однозначний. З одного боку, для внутрішніх клієнтів, за умови не зовсім вже сильно розподіленого лісу AD, затримками, як правило, можна знехтувати - бо доступність зазвичай важливіше. А доступність, як правильно підмітив колега Mikhail, при використанні LDAP забезпечити і простіше і дешевше. З іншого боку, немає нічого хорошого, якщо для зовнішніх клієнтів в CRL фігурує частина контексту іменування мого лісу. І хрін та з ним, з десятьма секундами затримки - проблеми негрів шерифа не настільки сильно займають. Звідси з неминучістю виникає хотелка: Для зовнішніх сервісів публікувати CRL тільки по URL, а ось для внутрішніх - по LDAP і URL. Вважаю, не сильно помиляюсь, якщо скажу, що переважна кількість компаній мають досить статичний набір зовнішніх ресурсів. Причому, настільки статичний, що за весь життєвий цикл інфраструктури PKI число запитів на операції по видачі / оновленню сертифікатів для них можна перерахувати по пальцях. Може бути з ногами. Внутрішні змінюються куди як частіше. І ось тепер я можу сформулювати питання: наскільки життєвим є такий процес обслуговування CA: - У нормальному режимі у мене видається в якості CDP LDAP і URL - Якщо мені необхідно видати сертифікат для зовнішнього сервісу, я перенастроювати CA на публікацію тільки URL, видаю сертифікат і повертаю взад LDAP / URL Тому як тримати окремий CA для видачі сертифікатів зовнішніх сервісів раз в п'ятирічку досить накладно. Або, можливо, є якийсь ще, невідомий мені, більш прямий спосіб вирішення поставленого завдання? Заздалегідь дякую.
найпряміший спосіб - мати 2 CA: один для внутрішніх клієнтів тільки і другий для зовнішніх.