У цій статті я розгляну такі теми про тонкощі і кращі практики для реалізації PKI від Microsoft - Active Directory Certificate Services:
Загальні уявлення про PKI
Чим більш інтегрованою, складною і захищеною стає інфраструктура на Windows Server, тим більше вона покладається на додаток до традиційної Active Directory на PKI (Public Key Infrastructure, переводять як інфраструктура відкритого ключа) для забезпечення довірчих відносин і перевірки автентичності між комп'ютерами, користувачами і службами. Active Directory Certificate Services - це реалізація PKI від Microsoft, яка складається з наступних елементів:
- Центр сертифікації (ЦС, Certification Authority), кореневою і підлеглі
- відносини загального довіри до ЦС
- видаються ЦС сертифікати для комп'ютерів, користувачів і служб
- різні служби підтримки PKI
- списки відгуків сертифікатів (CRL)
- мережевий відповідач (Online Responder, більш прогресивна альтернатива CRL)
- Web Enrollment (засіб запиту сертифікатів через Web)
Автоматичний запит сертифікатів
Ручна установка сертифікату кореневого ЦС
Якщо в середовищі Active Directory і локальної мережі довіру до кореневого центру сертифікації налаштовується автоматично, то для довіри до ЦС з боку недоменних віддалених комп'ютерів необхідно встановити сертифікат ЦС в їх сховище Довірені кореневі центри сертифікації. Інакше або будуть видаватися попередження про потенційну небезпеку підписаного невідомо ким сертифіката, або взагалі з'єднання з таким сервером будуть відхиляться, як, наприклад, у випадку з Remote Desktop Services Gateway буде видаватися така помилка:
Комп'ютера не вдається перевірити посвідчення шлюзу віддалених робочих столів "server.argon.com.ru". Зайдіть до серверів без посвідчень небезпечно. This computer can not verify the identity of the RD "server.argon.com.ru". It's not safe to connect to servers that can not be identified. Цей сертифікат не вдалося перевірити, простеживши його до довіреної центру сертифікації
Потрібно врахувати, що сертифікат вашого кореневого ЦС потрібно встановлювати не в сховище поточного користувача, а в сховищі локального комп'ютера, так як тільки його вміст діє на всіх користувачів і системні облікові записи. Існує кілька способів додати сертифікат ЦС в сховище локального комп'ютера.
Відкрити MMC з правами адміністратора »додати оснастку Сертифікати» вибрати в якості області Локальний комп'ютер »імпортувати потрібний сертифікат в сховищі Довірені кореневі центри сертифікації. Більш докладно в статті TechNet Manage Trusted Root Certificates.
Через властивості сертифіката
Запустити командний рядок з правами адміністратора »викликати в ній з: \ path \ to \ cert.crt» відкриється вікно властивостей сертифікату »натиснути кнопку Встановити» відзначити галку Показувати фізичні сховища »вибрати сховище для установки сертифіката Довірені кореневі центри сертифікації» Локальний комп'ютер.
Через командний рядок
Буде потрібно утиліта CertMgr. за допомогою неї потрібно виконати наступну команду:
certmgr.exe -add -c "з: \ path \ to \ cert.crt" -s -r localMachine root
Перевірка відкликання сертифікатів
Чи не вдалося перевірити, чи не був відкликаний цей сертифікат. A revocation check could not be perfomed for the certificate.
Перевірити справну роботу пристроїв перевірки відкликання (CRL або OCSP) будь-якого сертифіката можна за допомогою наступної команди:
certutil -url name.cer
де name.cer - ім'я виданого сертифіката.
Слід мати на увазі, що перевірка відкликання по протоколу OCSP проходить успішно тільки в тому випадку, якщо сертифікат ЦС, що видав сертифікат, що перевіряється, встановлений в сховище довірених сертифікатів локального комп'ютера.
Веб-служби реєстрації сертифікатів
Вони ж Certificate Enrollment Web Services, якщо по-англійськи. Дуже корисна роль, яка дозволяє:
- запитувати сертифікати користувачами без участі адміністратора
- надавати на вимогу сертифікат кореневого ЦС
- виконувати особливі вже підготовлені запити (Custom Request), наприклад для веб-серверів під управлінням Linux або інших мережевих пристроїв
- робити це все через інтернет
- сам Web Enrollment може працювати на відмінному від ЦС комп'ютері, що підвищує безпеку кореневого ЦС
Установка і настройка Web Enrollment проста і тривіальна за винятком таких моментів
- в разі установки Web Enrollment на відмінний від ЦС комп'ютер, необхідно обов'язково виконати кроки, описані в статті TechNet Configuring Delegation Settings for the Certificate Enrollment Web Service Account. інакше служба не буде працювати, видаючи таку помилку:
Сталася неочікувана помилка: Служба центру сертифікації (ЦС) не запущено. An unexpected error has occurred: The Certification Authority Service has not been started.
Запит сертифіката з альтернативним ім'ям
За замовчуванням ЦС на Windows Server не налаштований на видачу сертифікатів, що містять SAN. Щоб включити цю функцію на комп'ютері з ЦС потрібно виконати:
certutil -setreg policy \ EditFlags + EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
Запит через консоль MMC
Запит через утиліту certreq
Більш гнучким і універсальним способом запиту сертифікатів з SAN є наступний, який використовує утиліту certreq. Щоб створити сертифікат потрібно діяти за таким алгоритмом:
[Version]
Signature = "$ Windows NT $"
[NewRequest]
Subject = "CN = server.argon.local, OU = IT, O = Argon, L = Kirov, S = Kirovskaya, C = RU"
KeySpec = 1
KeyLength = 2048
HashAlgorithm = SHA256
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
RequestType = PKCS10
KeyUsage = 0xa0
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
FriendlyName = "server.argon.local with SAN"
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1; Server Authentication
[RequestAttributes]
CertificateTemplate = WebServer
[Extensions]
2.5.29.17 = ""
_continue_ = "DNS = *. argon.com.ru"
_continue_ = "DNS = argon.com.ru"
_continue_ = "DNS = server.argon.local"
_continue_ = "DNS = server"
_continue_ = "DNS = localhost"
2. На машині, для якої передбачається запитується сертифікат, виконати команду
certreq -new request.inf
Нам запропонують зберегти підготовлений файл запиту в форматі .req. Одночасно з цим в сховище сертифікатів комп'ютера буде збережений закритий ключ для майбутнього сертифіката.
3. Надіслати запит центру сертифікації та отримати у відповідь .cer файл. Для цього можна скористатися MMC-конcолью управління Certification Authority (і вказати .req файл) або Web Enrollment (в вікно розширеного запиту вставити вміст .req файлу і вибрати шаблон веб-сервера).
4. Виконати установку отриманого сертифіката на цільовий комп'ютер за допомогою такої команди
certreq -accept request.cer
Узагальнені кращі практики
Корисні посилання
«Наприклад з'єднання з віддаленим робочим столом відхиляється, видаючи помилку:
Чи не вдалося перевірити, чи не був відкликаний цей сертифікат. »
Ігор, добрий день!
Отримую саме таку помилку, хоча, як мені здається, налаштував все вірно, не могли б допомогти розібратися в даній проблемі?
Можу надіслати скріншот, де чітко видно, як все налаштовано, але не знаю, куди саме треба слати.
Заздалегідь вдячний за сприяння.
1. Зайди на комп, при підключенні до якого є проблеми, в оснащенні сертифікатів комп'ютера експортує сертифікат, який використовується для RDP в файл (без закрритого ключа).
2. Скинь цей сертифікат на комп, при підключенні з якого видається помилка перевірки сертифікатів.
Виконай certutil -url name.cer
Повинна пройти перевірку відкликання сертифікату, або по CRL, або по OCSP.
Спробую, звичайно, але виконати дану операцію на 150 користувачів нереально, хотілося б, щоб ці речі відпрацьовували автоматично, тим більше, що для цього начебто все налаштовано, потрібно розібратися в причинах, чому саме відпрацьовується перевірка відкликання, а примусово - це вже крайній випадок ...
Один раз спробувати перевірити примусово в контрольованому середовищі, щоб знайти і усунути причину. Про всіх користувачів я і не говорив;)
C: \ Users \ administrator> certutil -url c: \ ts.cer
CertUtil: -URL - команда успішно виконана.
Даж гублюся, що ще запропонувати. Почнемо з простого.
1. Перевірити, що сертифікат на терміналі дійсно довірений клієнтським компьютеором, весь ланцюжок від сертифіката до Root CA. Причому довіра повинна бути не на рівні сховища користувача, а на рівні комп'ютера.
2. Якщо є машини, при доступі з яких не виникає цієї проблеми, то порівняти конфіги з хворими.
3. Якщо ще не варто, спробувати розгорнути Online Responder. Правда при цьому потрібно сертифікати перевипускати, щоб вони містили інфу про нього.
Звичайно можемо, але я вважаю, що публічне обговорення може бути корисно і іншим читачам.
Тепер у справі, можна викласти скріни властивостей сертифікатів, або самі сертифікати. Якщо турбуєшся про конфіденційність, то можна посилання скинути мені в форму зворотного зв'язку.
1. Зберегти на комп і перевірити на валідність за допомогою certutil.
2. Зберегти на комп і імпортувати в сховище «довірені ЦC» компа, just for fun
Якщо в результаті цих дій нічого нового не виявиться, то надсилай повні сертифікати, без приватних ключів, ессно.
Ну і Ліхі е шляху ...
4. Відключити в GPO перевірку CRL для RDP
5. Через GPO встановити на клієнтські комп'ютери самоподпісанного сертифікати TS в якості довірених.
«При установці ЦС в домені Active Directory за замовчуванням повинні створюватися групові політики, які прописують довіру клієнтів до кореневого ЦС»
«Але відкликані вони центром сертифікації»
Мабуть, має місце помилка і малося на увазі «не».
«CRL (Certificate Revocation List, список відкликання сертифікатів) на веб-сервері, регулярно оновлюваний»
Особисто я налаштовую центри сертифікації на публікацію CRL'ей в DFS (з реплікацією, в разі необхідності), звідки вони спокійно лунають IIS'ом - ніяких «регулярних оновлень» не потрібно - все автоматом. Приклад такого налаштування я показував тут.
Ну а в чому складність зробити те ж саме, коли зовнішнє доменне ім'я відрізняється від внутрішнього? Забезпечення «прозорості» доменного суфікса, з моєї подачі, описані тут.
«Слід мати на увазі, що перевірка відкликання по протоколу OCSP проходить успішно тільки в тому випадку, якщо сертифікат ЦС, що видав сертифікат, що перевіряється, встановлений в сховище довірених сертифікатів локального комп'ютера»
Я б ще хотів додати, що успішна перевірка по OCSP пройде тільки в тому випадку, коли сам OCSP-сервер має доступ до CRL-файлів - саме звідти він бере інформацію, рятуючи клієнта від їх скачування;).
«Вони ж Certificate Enrollment Web Services, якщо по-англійськи. Дуже корисна роль »
А я б сказав, що роль марна і особисто я від її використання давно відмовився. Поданс, до речі, з цією думкою солідарний (тут і тут) :).
«За замовчуванням ЦС на Windows Server не налаштований на видачу сертифікатів, що містять SAN.»
Загальна помилка;). Центри сертифікації прекрасно видають SAN-сертифікати і без включення даної опції - колись Вадим мені «не вірив», але за попередньою посиланням сам зізнався в своєму омані і шкідливості даного прапора.
Зовсім не обов'язково;).
«Більш гнучким і універсальним способом запиту сертифікатів з SAN є наступний, який використовує утиліту certreq.»
На рахунок універсального не посперечаєшся, а ось на рахунок гнучкості повністю не згоден :). На мій погляд, самий гнучкий - запит через MMC-консоль в нових системах. І просто і зручно і наочно і без створення файлів з купою параметрів, які в голові не втримаєш і потрібно звертатися до заздалегідь заготовленим шаблонами.
«Відправити запит центру сертифікації та отримати у відповідь .cer файл. Для цього можна скористатися MMC-конcолью управління Certification Authority (і вказати .req файл) або Web Enrollment (в вікно розширеного запиту вставити вміст .req файлу і вибрати шаблон веб-сервера). »
Я вважаю за краще, якщо буде потреба, відправляти запит командою «certreq -Submit -attrib« certificatetemplate: WebServer »Request.req Response.cer».
«Якщо ЦС у тебе на винде, інтегрований з AD, то його потрібно налаштувати на публікацію CRL / AIA в AD»
Теж велика помилка;). Ці посилання в інтернет-сценаріях тільки заважають і найкращим варіантом є їх повне «випилювання» з сертифікатів - залишити тільки публічні HTTP-посилання.
Можеш навчити, як це зробити не з доменного компа?