Щось останнім часом почастішали питання пов'язані з проблемами Web Enrollment Pages. У цьому пості я розгляну 3 моменти:
- Запит сертифікатів для комп'ютера (з установкою сертифіката в сховище LocalMachine);
- Запит сертифікатів від імені іншого користувача (Enroll On Behalf Of);
- Налаштування Web Enrollment Pages при роботі на окремому від CA сервері.
- запитувати сертифікати тільки тих шаблонів, де Subject будувався автоматично на основі даних в Active Directory облікового запису, від імені якої відбувався запит;
- Якщо в шаблоні дозволено використовувати кілька CSP (Cryptographic Service Provider), можна було вибирати той, який потрібен для конкретного сертифіката або який вам просто більше подобається;
- Змінювати довжину ключа;
- Вмикати / вимикати можливість експорту сертифіката разом з закритим ключем (в PKCS # 12);
- Вмикати / вимикати функцію Private Key Strong Protection (тільки для призначених для користувача сертифікатів).
Якщо хочете використовувати шаблон, Subject якого повинен вказуватися в запиті (зазвичай використовується для недоменних клієнтів або клієнтів інших лісів Active Directory) або щось ще, вам було необхідно вирішувати дане питання іншими шляхами. Наприклад, використовувати текстовий файл настройок policy.inf спільно з утилітою CertReq.exe, або Web Enrollment Pages. Web Enrollment Pages був невід'ємною частиною компонента Certification Authority. При установці Web Enrollment Pages встановлювалася роль IIS (в реальності, частіше доводилося його встановлювати заздалегідь, щоб потім не налаштовувати його вручну) і в систему копіювався набір ASP файлів і елемент ActiveX під назвою Xenroll. Цей ActiveX є «прошарком» між клієнтом і сервером і відповідав за cookies і багато чого ще. У цих cookies зберігається деяка службова інформація, наприклад, номер запиту, який був відправлений на сервер CA і за яким ви потім могли отримати сертифікат.
І використовуючи Web Enrollment Pages ви могли запитувати сертифікати для недоменних комп'ютерів (або клієнтів інших лісів Active Directory):
Так само, як і з консоллю MMC, ви не могли перевизначати якісь речі, наприклад, експорт закритого ключа, якщо це не дозволено в шаблоні і інше. Вобщем, як альтернатива, Web Enrollment Pages була вельми корисна і часто потрібна річ.
З наведених причин навіть необхідність в Web Enrollment Pages скотилася до огидно низької позначки. Але жадібні діти користувачі продовжують нагадувати: поверніть все як було! Я не можу з ними погодитися, оскільки дублювати реалізований функціонал зовсім не обов'язково, а підвищення в безпеки зайвим не буде. Просто трапилася міграція необхідного функціоналу з серверної частини (Web Enrollment Pages) в клієнтську (Certificates snap-in).
При установці компонента на Web Enrollment Pages ви вказуєте сервер CA, з яким вони будуть працювати і встановлюєте необхідні компоненти IIS для цього. Однак, відразу це не буде працювати. Якщо бути точніше, то буде, але криво. Отже, які речі потрібно налаштувати для такої конфігурації:
- Включити SSL для веб-сайту, в якому будуть розміщені Web Enrollment Pages:
- Для IIS 7 і IIS 7.5: How to Setup SSL on IIS 7.0
- Відключити анонімну і ядерну (kernel) аутентифікацію і включити тільки Integrated Authentication:
- Для IIS 7 і IIS 7.5: Configure Windows Authentication (IIS 7)
- Налаштувати делегування для облікового запису, від імені якої працює пул, в якому працює веб-сайт з Enrollment Web Pages, як це описано тут: Install Web Enrollment Support on Another Computer (Optional)
Сподіваюся це буде корисним.