Що нового в ad cs certificate services в windows server 2018 r2 vs

Як відомо, сертифікати потрібні для надійної аутентифікації, створення SSL-з'єднань, відправки S / MIME-повідомлень та інших дій, спрямованих на забезпечення безпеки. З кожним роком використання сертифікатів зростає, і для того, щоб задовольняти новим вимогам, Microsoft досить серйозно переробила стару службу Certificate Services.

  1. Certification authorities (CAs) - цей компонент дозволяє встановити і налаштувати кореневої (root) або підлеглий (subordinate) центри сертифікації (вони ж «засвідчують центри»), які служать для видачі сертифікатів користувачам, комп'ютерам і службам.
  2. Web enrollment необхідний для запиту сертифікатів і отримання інформації про відкликаних сертифікатах через веб-браузер.
  3. Online Responder дозволяє клієнтам отримувати інформацію про статус одного сертифіката без отримання списку відкликаних.
  4. Network Device Enrollment Service (NDES) використовується маршрутизаторами і іншими мережевими пристроями без облікових записів в домені для отримання сертифікатів. Служба подачі заявок на мережеві пристрої використовує протокол SCEP (Simple Certificate Enrollment Protocol), який був розроблений Cisco. Розширення NDES для IIS конфигурируется через ключі реєстру HKEY_LOCAL_ROOT \ Software \ Microsoft \ Cryptography \ MSCEP.
  5. Certificate Enrollment Web Service дозволяє клієнтам автоматично подавати заявки на сертифікати і отримувати їх по HTTPS.
  6. Certificate Enrollment Policy Web Service дозволяє визначити політики для автоматичної реєстрації сертифікатів і передавати їх клієнтам по HTTPS. У той час, як Web Service отримує інформацію про політиків з AD по протоколу LDAP.

Варіанти установки і управління AD CS

Установка AD CS проводиться через додавання ролей в оснащенні Server Manager. Як і раніше, для налаштування параметрів установки застосовується конфігураційний файл CAPolicy.inf, який повинен знаходитися в% SYSTEMROOT%. Якщо необхідно встановити на сервер два компонента Certification Authority і Certificate Enrollment Web Service, то це треба робити в два етапи, так як при установці CA можна вибрати для установки компонент Web Service.

Enterprise PKI дозволяє одночасно відстежувати стан і доступність декількох CA, перевіряє статус сертифікатів CA, доступність AIA (Authority Information Access) і списку відкликаних. За допомогою різнокольорових відміток можна судити про доступність та стан PKI. Pkiview зручно використовувати, коли в організації розгорнуто кілька CA, і інформацію про них можна отримати з кількох джерел, що працюють по різних протоколах.

шаблони сертифікатів

За допомогою шаблонів сертифікатів можна визначити формат і вміст видаваного сертифіката, а також задати дозволу на запит сертифікатів для користувачів і комп'ютерів. Тільки Enterprise CA можуть використовувати шаблони сертифікатів.

Нові способи запиту сертифікатів

До речі, а яким чином користувачі і комп'ютери отримують сертифікати? Інакше кажучи, як вони можуть подавати запит на сертифікат і встановлювати його на комп'ютер? Можна, звичайно, руками створити PKCS # 10 запит і за допомогою командного рядка і certreq передати запит на CA, але не завжди є можливість пояснити користувачам, як це зробити. Якщо користувач доменний і підключений до корпоративної мережі, то можна за допомогою групових політик налаштувати автоматичну подачу і обробку заявок. В результаті користувач може навіть не підозрювати, що йому був встановлений новий сертифікат або оновлений старий.

Клієнти, які не входять до домен або не мають прямого доступу в мережу з CA, можуть запросити сертифікат через веб-інтерфейс. Компонент Web Enrollment, який необхідний для цього, присутній і раніше, але був істотно перероблений. Стара бібліотека XEnroll.dll, яка була написана багато років назад і довго доповнювалася новими функціями і багами, була замінена на нову - CertEnroll.dll, так як виявилося легше написати з нуля, ніж виправити те, що було. Web Enrollment дозволяє подавати заявки в форматі PKCS # 10 або створювати запити інтерактивно через браузер, автоматична подача заявок не підтримується.

Якщо необхідно уникнути запитів до CA на нові сертифікати з інтернету, але є клієнти, яким треба оновлювати сертифікати, коли вони, наприклад, у відрядженнях, то можна використовувати режим тільки оновлення (renewal-only). У цьому випадку клієнти при першому отриманні сертифікату повинні бути в тій же мережі, що і CA, а в разі поновлення сертифікатів можуть скористатися можливостями CA Web Enrollment.

Політики для цих служб налаштовуються через групові політики або на клієнті, через оснащення Certificates.

Списки відкликання vs. Online Responder

При перевірці валідності сертифіката серед іншого перевіряється термін його дії і стан відкликання. Сертифікат може бути відкликаний, як в разі компрометації ключа, так і при зміні інформації про власника, приміром, зміні посади або прізвища. Традиційно інформація про відкликаних сертифікатах міститься в списки відкликання (CRL (certificate revocation list)). Щоб дізнатися, чи був відкликаний сертифікат, треба отримати список відкликання і перевірити наявність в ньому розглядається сертифіката. Якщо в організації велика кількість сертифікатів, то список буде швидко рости, а клієнти при перевірці статусу сертифіката чекатимуть закачування списку. Крім звичайних списків існують ще й різницеві (Delta CRL), які містять в собі тільки інформацію про сертифікати, статус яких був змінений у порівнянні з попереднім списком відкликання. Delta CRL частково вирішують проблеми з об'ємом списку відкликаних, але не вирішують усіх проблем, пов'язаних з актуальністю інформації. Так як списки публікуються через встановлені проміжки часу, то може бути така ситуація, що сертифікат вже відкликаний, а інформації про це в CRL ще немає.

Протокол OCSP підтримують клієнти, починаючи з Windows Vista. Вони можуть бути налаштовані за допомогою нових параметрів групової політики (Certificate Path Validation Settings вкладка Revocation).

На відміну від використання списку відкликаних, Online Responder потрібно спочатку встановити і налаштувати. Для цього треба виконати наступні кроки:

висновок

По-перше, домагалася підтримка нових протоколів і криптографічних алгоритмів. Протокол OCSP, який вже не один рік був присутній в інших програмних продуктах, нарешті дійшов до серверних ОС Microsoft. Таким чином, у адміністраторів і програмістів з'явилися різні варіанти для перевірки статусу відкликаних сертифікатів, які дозволяють вибирати між швидкістю, об'ємом даних і актуальністю інформації. Важливо й поява підтримки алгоритмів на еліптичних кривих. На жаль, не підтримуються російські, а американські стандарти, але очікувати іншого було б дивно.

По-друге, багато бібліотек (наприклад, Crypto API і XEnroll.dll) переписані з нуля, через що можна сподіватися на порятунок від старих помилок і проблем, і чекати нових.
По-третє, значно розширилися подання запитів та отримання сертифікатів. Тепер сертифікати можуть отримувати і мережеві пристрої без запису в домені, і користувачі без прямого доступу до мережі з CA.

І нарешті, без уваги не залишені і любителі автоматизації і скріптопісанія - нові об'єкти і функції дозволять їм реалізувати свої фантазії.

Покажи цю статтю друзям:

Схожі статті