Microsoft windows third party component ca 2012 скачать

After we submit 2 HLC for our driver, we realize we get the 2 different certificate from Microsoft, one is issued by «Microsoft Windows PCA 2010», another one is issued
by «Microsoft Windows Third Party Component CA 2012».

i had confirmed with Digicert, our digital signing can valid up to 10 year. but when we get the certificate issued by «Microsoft Window PCA 2010», it only valid 1 year
or short. But if the certificate issued by «Microsoft Windows Third Party Component CA 2012», this certificate still can use event the valid date is expired, (Please refer to the attachment).

My question is, if we submit HCL to get the certification from Microsoft, we should no click » Perform test-signing for Win10 and above»? (Please see below image)

because if i click » Perform test-signing for Win10 and above», the certification will we get will issued by «»Microsoft Window PCA 2010» which is only
can valid on short time.

Please tell me which one is a correct? if we provide the our driver with valid date only 1 year, this is a impact to our company.

Microsoft Windows 3rd party Component — 0.032% Detection Rate *

Did you just run into a download or a file on your computer that has been digitally signed by Microsoft Windows 3rd party Component? If so, please read on.

You will probably notice Microsoft Windows 3rd party Component when running the file. The publisher name is displayed as the «Verified publisher» in the UAC dialog as the screencap shows:

Screenshot where Microsoft Windows 3rd party Component appears as the verified publisher in the UAC dialog

You can view additional details from the Microsoft Windows 3rd party Component certificate with the following procedure:

  1. Open up Windows Explorer and locate the Microsoft Windows 3rd party Component file
  2. Right-click on the file and select Properties
  3. Click the Digital Signatures tab
  4. Click the View Certificate button

Here’s a screenshot of a file that has been digitally signed by Microsoft Windows 3rd party Component:

Screenshot of the Microsoft Windows 3rd party Component certificate

As you can see in the screenshot above, Windows reports that «This digital signature is OK». This implies that the file has been published by Microsoft Windows 3rd party Component and that no one has tampered with the file.

If you click the View Certificate button shown in the screenshot above, you can examine all the details of the certificate, such as when it was issued, who issued the certificate, how long it is valid, and so on. You can also view the address for Microsoft Windows 3rd party Component, such as the street name, city and country.

Microsoft Windows Third Party Component CA 2012 has issued the Microsoft Windows 3rd party Component certificates. You can also examine the details of the issuer by clicking the View Certificate button shown in the screencap above.

The following are the Microsoft Windows 3rd party Component files I have gathered, thanks to the FreeFixer users.

The FreeFixer tool treats files from Microsoft Windows 3rd party Component as safe, which means that the Microsoft Windows 3rd party Component files will appear with a green background and that there’s no removal checkbox for the file. However, as you can see in the scan results below, a few of the anti-virus scanners detects the Microsoft Windows 3rd party Component file(s). I’m pretty sure those detections are false positives and that the files are safe. It’s unlikely that Microsoft Windows 3rd party Component would ship a malware file.

Detection Ratio File Name
1/54 FlashUtil_ActiveX.exe
0/47 FlashUtil_ActiveX.exe
0/62 winsqlite3.dll
0/45 FlashUtil_ActiveX.exe
0/55 FlashUtil_ActiveX.exe
0/46 FlashUtil_ActiveX.dll
0/49 FlashUtil_ActiveX.exe
0/57 FlashPlayerCPLApp.cpl
0/48 FlashUtil_ActiveX.exe
0/48 FlashUtil_ActiveX.exe
0/56 FlashUtil_ActiveX.exe

Scanner and Detection Names

Here is the detection names for the Microsoft Windows 3rd party Component files. I have grouped the detection names by each scanner engine. Thanks to VirusTotal for the scan results.

As mentioned above, I think these detections are incorrect since it is very unlikely that Microsoft Windows 3rd party Component would ship a malware file.

Scanner Detection Names
AegisLab AdWare.MSIL.DomaIQ

* How the Detection Percentage is Calculated

The detection percentage is based on that I have collected 3092 scan reports for the Microsoft Windows 3rd party Component files. 1 of these scan reports came up with some sort of detection. If you like, you can review the full details of the scan results by examining the files listed above.

Analysis Details

The analysis has been done on certificates with the following serial numbers:

  • 3300000013463999b5c7e12baf000000000013
  • 61032f5e000000000006
  • 330000002b1160aea776772bf000000000002b
  • 330000000b8b9486a892605c5700000000000b

Установка и настройка подчиненного центра сертификации Microsoft CA на MS Windows Server 2012 R2

При установке подчиненного центра сертификации будет считать, что домен
уже имеется, DNS-сервер и доменная служба Active Directory установлены.
Порядок установки будет следующим:

  1. Установить подчиненный Центр сертификации уровня ЦС предприятия (со
    службой сертификации и службой регистрации в центре сертификации через
    Интернет) MS Windows Server 2012 R2, задать имя центра сертификации,
    подразделение, организацию, город и страну для сертификата, отправить
    запрос на сертификат в корневой центр сертификации.
  2. Установить сертификат корневого центра сертификации и актуальный
    список отозванных сертификатов.
  3. Настроить службу на автоматический выпуск сертификатов.
  4. Включить аудит работы службы, сделать настройки безопасности.
  5. Добавить ссылки на точку распространения отозванных сертификатов и
    корневого сертификата центра сертификации, которые будут добавляться в
    каждый выпущенный сертификат.
  6. Выпустить внеочередной список отозванных сертификатов.

Установка службы сертификации производится с использованием Мастера в следующей последовательности:

  1. Открыть окно Диспетчер серверов.
  2. В окне выбрать Добавить роли и компоненты.
  3. В окне Мастера добавления ролей и компонентов
    оставить по умолчанию тип установки Установка ролей или компонентов.
  4. В окне Выбор целевого сервера оставить все без изменения.
  5. Далее выбрать роль сервера Службы сертификатов Active Directory. В Появившемся
    окне оставить все по умолчанию и нажать кнопку Добавитькомпоненты.

  6. Поставить флажок Служба регистрации в центре сертификации через Интернет.
  7. Нажмите Далее.
  8. После проверки выбранных параметров установки нажмите Установить.
  9. За процессом установки можно наблюдать в окне Результаты.

После установки службы сертификации необходимо ее настроить. Для этого
нажать Настроить службы сертификации Active Directory на конечном сервере.

В окне учетные данные нажать Далее.

В окне выбора службы роли для настройки отметить флажками Центр сертификации и
Служба регистрации в центре сертификации через Интернет. Нажать кнопку Далее.

Далее следует выбрать ЦС предприятия.

Затем Подчиненный ЦС.

При создании нового ключа ЦС выбрать опцию Создать новый закрытый ключ.

Далее следует выбрать криптопровайдер RSA#Microsoft Software Key Storage Provider и
установить опцию Разрешить взаимодействие с администратором, если центр сертификации
обращается к закрытому ключу
.

Далее ввести сведения о ЦС. Имя ЦС может быть введено
как кириллицей, так и латиницей. При этом если имя вводится кириллицей,
то его длина не должна превышать 50 символов.
Если Имя вводится латиницей, то его длина не должна превышать 250 символов.
Имя ЦС по умолчанию состоит из имени сервера и приставки CA.

Ввести сведения о Вашей организации в поле Суффикс различающегося имени, разделив значения
запятыми (после запятой пробел не ставить), по следующему примеру:


OU
= название отдела


O
= название организации


L
= город местонахождения


C
= RU

На сообщение о расширенной кодировке имен выбираем Да:

Сохранить запрос на сертификат в файл:

По окончанию появится окно с успешной установкой:

Файл запроса на сертификат будет сохранен в корне диска C:.

Установка сертификата корневого центра сертификации и актуального списка отозванных сертификатов

Вначале следует загрузить веб-сайт корневого центра сертификации.
Для этого запустить браузер, ввести в строку поиска адрес Вашего корневого центра
сертификации, например, по имени сервера:
https://«имя вашего корневого сервера»/certsrv.
Для изготовления сертификата выберите действие Запрос сертификата:

Выбрать Расширенный запрос сертификата, затем
Выдать запрос, используя base-64 шифрованный файл…:

Открыть файл с запросом на сертификат в Блокноте, выделить все
содержимое в файле (комбинация клавиш Ctrl+A) и скопировать в буфер
обмена (комбинация клавиш Ctrl+C):

Вставить содержимое буфера обмена (комбинация клавиш Ctrl+V) в окно
выдачи запроса на сертификат на веб-сайте корневого центра сертификации
и нажмите кнопку Выдать>:

В результате обработки запроса корневым центром сертификации будет
выдан сертификат, который нужно сохранить на подчиненном центре
сертификации, нажав на строку Загрузить сертификат:

Для запуска подчиненного центра сертификации необходимо встроить
цепочку доверия
к корневому центру сертификации, установив корневой
сертификат и актуальный список отозванных сертификатов. Для загрузки нужно
перейти на начальную страницу веб-сайта корневого центра сертификации,
нажав на ссылку Домой в верхнем правом углу сайта:

Нажать на строку Загрузка сертификата ЦС, цепочки сертификатов или CRL:

Скачать и сохранить на подчиненном центре сертификации сертификат ЦС и
актуальный список отозванных сертификатов, нажав по ссылкамЗагрузка сертификата ЦС
и Загрузка последнего базового CRL:

Установить корневой сертификат на сервер. Для этого кликнуть правой
кнопкой мыши на корневой сертификат, в появившемся контекстном меню
выбрать Установить сертификат. В мастере импорта
сертификатов выбрать хранилище – Локальный компьютер:


Выбрать хранилище вручную, установив переключатель на Поместить все сертификаты в следующее хранилище и
отметить в списке Доверенные корневые центры сертификации/Реестр:

При установке списка отозванных сертификатов выполнить аналогичные
действия, при этом в окне Выбор хранилища сертификата
установить флажок Показать физические хранилища, в
списке выделить Промежуточные центры сертификации/Локальный компьютер.

Запустить Центр сертификации ПускПриложенияЦентр сертификации:

Подчиненный центр сертификации еще не работает, т.к. сертификат для
него не установлен. Установка сертификата проводится при первом старте
службы. Нажать кнопку старта службы:

На запрос об установке сертификата нажать кнопку Да и
указать место, куда был сохранен выданный сертификат.

Если все действия были выполнены правильно, служба центра сертификации успешно запуститься.

Настройка подчиненного Центра сертификации

Чтобы просмотреть настройки Центра сертификации, нужно вызвать
контекстное меню и выбрать Свойства:

Настроить центр сертификации на выпуск сертификатов в автоматическом
режиме. Для этого перейти в закладку Модуль политики,
нажать кнопку Свойства. В открывшемся окне выбрать
режим Следовать параметрам, установленным в шаблоне….:


Перейти в закладку Модуль выхода. Нажать кнопку Свойства:

Установить (если не установлен) флажок Разрешить публикацию сертификатов в файловой системе:

Перейти в закладку Аудит. Включить протоколирование
некоторых событий безопасности, например, архивации и восстановления
базы данных, изменения настроек ЦС и параметров безопасности и т.д.:

Перейти в закладку Безопасность. Разрешить
Администратору запрашивать сертификаты. Установить флажок в графе Разрешить
для строки Запросить сертификаты:

Перейти в закладку Расширения. Выполнить настройку
публикации списка отозванных сертификатов. Для этого в меню Выберите расширение
выбрать Точка распространения списка отзыва (CDP) Удалить
точки распространения, кроме C:Windows….. Добавить
путь, например, https://servername/Public/servername.crl,
где servername – имя сервера, где будет настроено публичное хранилище:


Включить настройки Включать в CDP-расширение выданных сертификатов и
Включать в расширения IDP выданных CRL
. Перезапустить Центр сертификации:

В дополнение к CDP, необходимо сконфигурировать дополнение включающее
информацию о локализации сертификата ЦС AIA. Для этого в поле Выберите
расширение
перейти к Authority Information Access (AIA). Удалить доступы к
сведениям о центрах сертификации, кроме C:Windows…..
Добавить путь, например, https://servername/Public/servername.cer, где
servername – имя сервера, где будет настроено публичное хранилище.
Включить настройки Включать в AIA- расширение выданных сертификатов.
Перезапустить Центр сертификации:


Поскольку значения дополнений CDP и AIA изменены, то для учета изменений
необходимо выпустить и опубликовать CRL. Для публикации CRL необходимо в
дереве консоли Центра сертификации нажать правой кнопкой мыши на узел
Отозванные сертификаты. В появившемся меню выбрать
Все задачи — Публикация:

По умолчанию списки отозванных сертификатов размещены в папке

C:WindowsSystem32CertsrvCertEnroll

Яндекс.Метрика

Автономный центр сертификации windows 2012 r2

Пошаговая инструкция по установке и настройке центра сертификации

Сергей Вессарт | Опубликовано 29.10.2013 в рубрике Новые возможности

Одним из преимуществ ЛОЦМАН:ПГС является применение цифровых подписей достоверно подтверждающих личность и роль подписавшего документ. Для создания цифровых подписей необходимы сертификаты выданные удостоверяющим центром сертификации.

На этапе внедрения не всегда хватает опыта для установки и настройки центра сертификации, чтобы Вам не пришлось собирать крупицы информации по просторам интернета, мы предлагаем подробно рассмотреть установку и настройку центра сертификации.

В наших примерах мы будем использовать контроллер домена на Microsoft Windows Server 2008 и клиент Microsoft Windows 7.

  1. Для начала нам нужно добавить роль Active Directory Certification Services (Службы сертификации Active Directory) на контроллере домена. Откройте Server Manager и выполните команду «Add Role» («Добавить роли»).
  2. Откроется Add Roles Wizard (Мастер добавления ролей). Нажмите Next.
  3. Выберите роль Active Directory Certification Services(Службы сертификации Active Directory). Нажмите Next.
  4. Next.
  5. Проверьте, что отмечена служба Certification Authority(Центр сертификации).
  6. Вариант установки должен быть указан «Enterprise».
  7. Тип центра сертификации Root CA(Корневой ЦС).
  8. Создайте новый приватный ключ.
  9. Укажите параметры шифрования, например:

    Если Вы меняете параметры, рекомендуем Вам ознакомиться с советами компании Microsoft по безопасности в части выбираемой длины ключа.
  10. Проверьте имя и суффиксы центра сертификации, например:
  11. Задайте срок действия сертификата, например:
  12. Next.
  13. Install.
  14. Процесс установки…
  15. Установка завершена. Close.

    Центр сертификации установлен. Теперь нужно создать шаблон сертификатов.
  16. Перейдите в Certificate Templates (Шаблоны сертификатов) и выполните команду Duplicate Template (Скопировать шаблон) на существующем шаблоне, например User.
  17. Выберите версию Windows Server минимально поддерживаемую ЦС.

    Не выбирайте Windows Server 2008, иначе при подписании созданным сертификатом документов в программных продуктах использующих .NET Framework 4.0 Вы получите сообщение «Указан неправильный тип поставщика (mscorlib)». Иными словами Вы не сможете использовать сертификат.
  18. В открывшихся свойствах шаблона укажите имя и отключите Publish certificate in Active Directory (Опубликовать сертификат в Active Directory):
  19. Перейдите на вкладку Request Handling (Обработка запроса) и измените цель на «Signature» («Подпись»).
  20. Проверьте параметры на вкладке Subject Name (Имя субъекта).
  21. На вкладке Security (Безопасность) для группы Authenticated Users (Прошедшие проверку) разрешите Enroll (Заявка).
  22. На вкладке Extensions (Расширения) скорректируйте Application Policies (Политика применения) .

    Выберите Document Signing (Подписывание документа).

    ОК.

    Шаблон сертификата создан, теперь необходимо его опубликовать.
  23. Перейдите в Certificate Templates (Шаблоны сертификатов) и выполните команду «New -> Certificate Template to Issue» («Новый -> Выдать шаблон сертификата»).
  24. Выберите ранее созданный шаблон. ОК.

    Установка и настройка шаблона сертификатов закончена. Перейдем на клиента и попробуем получить сертификат.
  25. На клиенте запустите Certificate Manager Tool выполнив команду certmgr.msc.
  26. Перейдите в Personal (Личное) и создайте запрос на получение сертификата, выполнив Request New Certificate (Запросить новый сертификат).
  27. Next.
  28. Выберите политику Active Directory. Next.
  29. В типах сертификатов отметьте ранее созданный шаблон.

    Если планируется использование нескольких сертификатов для одного пользователя, желательно присвоить имя запрашиваемому сертификату. Откройте свойства заявки.
  30. На вкладке General (Общие) укажите Friendly name (Понятное имя).

    Сохраните и закройте свойства.
  31. Enroll.
  32. Заявка успешно завершена, сертификат получен.
  33. В Certificate Manager Tool можно посмотреть параметры сертификата.

    Мы получили сертификат только для одного пользователя, а когда пользователей много, такой способ не очень удобен. Для облегчения процесса давайте настроим автоматическую раздачу сертификатов групповой политикой.
  34. Для начала необходимо изменить свойства, созданного ранее шаблона, сделать его доступным для автоматической выдачи. Найдите созданный шаблон в Server Manager и откройте свойства.
  35. Перейдите на вкладку Security (Безопасность) и для группы Authenticated Users (Прошедшие проверку) разрешите Autoenroll (Автозаявка).
  36. Следующий шаг — настроить групповую политику автоматической регистрации сертификатов для домена. Можно изменить политику по-умолчанию, но лучше создать новую, так мы сможем ограничить круг пользователей, охватываемых политикой. На домене выполните команду Create a GPO in this domain, and Link it there… (Создать ОГП в документе и связать его…).
  37. Введите имя групповой политики, например:
  38. Отредактируйте созданную политику.
  39. Перейдите в раздел «User configuration — Policies — Widows Settings — Security Settings — Public Key Policies» (Конфигурация пользователя — Политики — Конфигурация Windows — Параметры безопасности — Политики открытого ключа) и откройте свойства Certificate Services Client — Auto-Enrollment (Клиент службы сертификации — автоматическая регистрация).
  40. Включите автоматическую регистрацию сертификатов и флажки:
    • Обновлять сертификаты с истекшим сроком действия или в состоянии ожидания и удалять отозванные сертификаты;
    • Обновлять сертификаты, использующие шаблоны сертификатов.

  • Закройте редактор групповой политики и в Server Manager при необходимости ограничьте круг пользователей или компьютеров, на которые будет применена политика. Как пример, ниже показана политика, которая будет распространена только на ПК DOMAINCOMPUTER.

    Групповая политика создана, проверим как она работает.
  • На клиенте откройте CMD.exe с правам администратора и выполните команду «gpupdate /force /boot /logoff» или перезапустите ПК.
  • Сертификат должен быть автоматически запрошен и получен. Полученный сертификат можно увидеть в Certificate Manager Tool (пункт 33) или в Control Panel — Internet Options, вкладка Content — Certificates — Personal (Панель управления — Свойства обозревателя, вкладка Содержание — Сертификаты — Личные).

    Это всё, что мы хотели сказать про установку и настройку центра сертификации. Спасибо, что читаете наш блог, до свидания!
  • 9 комментариев

    Сергей, спасибо большое. Очень нужная статья.

    Источник

    Записки IT специалиста

    Технический блог специалистов ООО»Интерфейс»

    Windows Server. Создание автономного центра сертификации.

    Перед каждым администратором рано или поздно возникает необходимость обеспечить безопасный обмен информации через интернет, внешние и внутренние сети, а также проверку подлинности каждой из сторон, участвующих в обмене информацией. На помощь здесь приходит инфраструктура открытых ключей (PKI) и службы сертификации Windows.

    Инфраструктура открытых ключей позволяет использовать цифровые сертификаты для подтверждения подлинности владельца и позволяет надежно и эффективно защищать трафик передаваемый по открытым сетям связи, а также осуществлять с их помощью аутентификацию пользователей. Основой инфраструктуры открытых ключей является центр сертификации, который осуществляет выдачу и отзыв сертификатов, а также обеспечивает проверку их подлинности.

    Для чего это может быть нужно на практике? Цифровые сертификаты позволяют использовать шифрование на уровне приложений (SSL/TLS) для защиты веб-страниц, электронной почты, служб терминалов и т.п., регистрацию в домене при помощи смарт-карт, аутентификацию пользователей виртуальных частных сетей (VPN), шифрование данных на жестком диске (EFS), а также в ряде случаев обойтись без использования паролей.

    Для создания центра сертификации нам понадобится сервер, работающий под управлением Windows Server, который может быть как выделенным, так и совмещать роль центра сертификации с другими ролями. Однако следует помнить, что после развертывания центра сертификации вы не сможете поменять имя компьютера и его принадлежность к домену (рабочей группе).

    Центр сертификации (ЦС) может быть двух типов: ЦС предприятия и изолированный (автономный) ЦС, рассмотрим их отличительные особенности:

    ЦС предприятия

    • Требует наличия ActiveDirectory
    • Автоматическое подтверждение сертификатов
    • Автоматическое развертывание сертификатов
    • Возможность запроса сертификатов через Web-интерфейс, мастер запросов и автоматическое развертывание

    Изолированный (автономный) ЦС

    • Не требует наличия ActiveDirectory
    • Ручное подтверждение сертификатов
    • Отсутствие возможности автоматического развертывания
    • Запрос сертификатов только через Web-интерфейс

    Методика развертывания ЦС для Windows Server 2003 и Windows Server 2008 несколько различаются, поэтому мы решили рассмотреть их в отдельности.

    Windows Server 2003

    Для возможности использования Web-интерфейса для выдачи сертификатов нам понадобится установленный web-сервер IIS. Установим его через диспетчер сервера: Пуск — Управление данным сервером — Добавить или удалить роль.
    В списке ролей выбираем роль Сервера приложений. В следующем окне устанавливаем галочку Включить ASP.NET, если IIS уже установлен данный шаг можно пропустить.

    После установки IIS приступим к развертыванию Центра сертификации, это делается через оснастку Установка и удаление программ — Установка компонентов Windows, где выбираем Службы сертификации.

    Следующим шагом выберите тип ЦС и его подчиненность. Так как в нашем случае сеть не имеет доменной структуры, то ЦС Предприятия недоступен для выбора. Поскольку это первый (и пока единственный ЦС) следует выбрать корневой сервер, подчиненный тип следует выбирать для развертывания следующих ЦС, например для филиалов.

    Далее вводим имя ЦС (должно совпадать с именем сервера) и пути размещения файлов. В процессе установки программа предложит перезапустить IIS и, если не была включена поддержка страниц ASP.NET, предложит ее включить, с чем следует согласиться.

    Windows Server 2008 R2

    В Windows Server 2008 (2008 R2) все настройки консолидированы в одном месте, что делает установку ЦС более простой и удобной. Выбираем Диспетчер сервера — Роли — Добавить роли, в списке ролей выбираем Службы сертификации Active Directory.

    В следующем окне обязательно добавляем компонент Служба регистрации в центре сертификации через интернет. При этом будут автоматически определены необходимые службы ролей и компоненты (такие как IIS) и будет предложено их добавить.

    Дальнейшая настройка аналогична Windows Server 2003. Вводим тип ЦС, его имя и место хранения файлов, подтверждаем выбор компонент и завершаем установку.

    Проверка работы ЦС

    Для первоначальной проверки работоспособности ЦС можете запустить оснастку Центр сертификации (Пуск — Администрирование — Центр Сертификации). Если все сделано правильно вы должны увидеть следующее окно:
    Попробуем теперь получить сертификат для клиентского ПК. Запустим браузер, в адресной строке которого укажем адрес http://имя_сервера/certsrv, где имя_сервера — имя сервера ЦС. Вы попадете на главную страницу центра сертификации.
    Прежде всего необходимо загрузить сертификат ЦС и поместить его в хранилище доверенных коренных центров сертификации. Если в вашей сети несколько ЦС следует загрузить и установить цепочку сертификатов. Для этого выбираем: Загрузка сертификата ЦС, цепочки сертификатов или CRL, затем Загрузка сертификата ЦС или Загрузка сертификата ЦС и сохраняем сертификат в любое удобное место.

    Теперь перейдем к установке, для этого щелкнем правой кнопкой на файле сертификата и выберем Установить сертификат, откроется мастер импорта, в котором откажемся от автоматического выбора хранилища вручную выбрав Доверенные корневые центры сертификации, теперь данный ПК будет доверять всем сертификатам выданным данным ЦС.

    Для получения клиентского сертификата снова откроем сайт ЦС и выберем Запрос сертификата — расширенный запрос сертификатаСоздать и выдать запрос к этому ЦС. Заполняем форму запроса, в качестве имени указываем имя ПК или пользователя, в качестве типа сертификата указываем Сертификат проверки подлинности клиента и жмем кнопку Выдать.

    При попытке создать запрос сертификата вы можете получить следующее предупреждение:

    В этом случае можно добавить данный узел в зону Надежные узлы и установить низкий уровень безопасности для этой зоны. В Windows Server понадобится также разрешить загрузку неподписанных ActiveX.

    Теперь на сервере откроем оснастку Центр сертификации и в разделе Запросы на ожидание найдем наш запрос и щелкнув на него правой кнопкой выберем Все задачи — Выдать.

    Теперь вернемся на клиентский ПК и еще раз откроем сайт ЦС. На этот раз выберем Просмотр состояния ожидаемого запроса сертификата, вы увидите свой запрос, щелкнув на которой вы попадете на страницу Сертификат выдан и сможете сразу его установить.

    Если все сделано правильно, то сертификат успешно установится в хранилище личных сертификатов.

    По окончании проверки не забудьте удалить ненужные сертификаты с клиентского ПК и отозвать их в центре сертификации на сервере.

    Источник

    А вот и финальная третья часть нашей серии статей о центре сертификации на предприятии. Сегодня рассмотрим развертывание службы сертификатов на примере Windows Server 2016. Поговорим о подготовке контроллера домена, подготовке веб-сервера, установке корневого и издающего центров сертификации и об обновлении сертификатов. Заглядывайте под кат!

    Первая часть серии

    Вторая часть серии

    Словарь терминов

    В этой части серии использованы следующие сокращения и аббревиатуры:

    • PKI (Public Key Infrastructure) — инфраструктура открытого ключа, набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. Поскольку аббревиатура ИОК не является распространённой, здесь и далее будет использоваться более знакомая англоязычная аббревиатура PKI.
    • X.509 — стандарт ITU-T для инфраструктуры открытого ключа и инфраструктуры управления привилегиями.
    • ЦС (Центр Сертификации) — служба выпускающая цифровые сертификаты. Сертификат — это электронный документ, подтверждающий принадлежность открытого ключа владельцу.
    • CRL (Certificate Revocation List) — список отзыва сертификатов. Подписанный электронный документ, публикуемый ЦС и содержащий список отозванных сертификатов, действие которых прекращено по внешним причинам. Для каждого отозванного сертификата указывается его серийный номер, дата и время отзыва, а также причина отзыва (необязательно). Приложения могут использовать CRL для подтверждения того, что предъявленный сертификат является действительным и не отозван издателем… Приложения могут использовать CRL для подтверждения, что предъявленный сертификат является действительным и не отозван издателем.
    • SSL (Secure Sockets Layer) или TLS (Transport Layer Security) — технология обеспечивающая безопасность передачи данных между клиентом и сервером поверх открытых сетей.
    • HTTPS (HTTP/Secure) — защищённый HTTP, является частным случаем использования SSL.
    • Internet PKI — набор стандартов, соглашений, процедур и практик, которые обеспечивают единый (унифицированный) механизм защиты передачи данных на основе стандарта X.509 по открытым каналам передачи данных.
    • CPS (Certificate Practice Statement) — документ, описывающий процедуры управления инфраструктурой открытого ключа и цифровыми сертификатами.

    Общий план развёртывания

    Для развёртывания службы сертификатов нам потребуется четыре машины с Windows Server 2016, которые будут выполнять следующие функции:

    1. Контроллер домена — необходим для функционирования домена Active Directory;
    2. Веб-сервер — будет обеспечивать доступ к сертификатам ЦС и спискам отзывов для клиентов;
    3. Корневой ЦС — будет выполнять функции корневого ЦС;
    4. Подчинённый ЦС — будет выполнять функции издающего ЦС.

    Развёртывание PKI будет проходить поэтапно на каждом сервере в том порядке, в котором они указаны выше. Подготовка контроллера домена будет сводиться к обеспечению функций Active Directory, GPO и учётных записей.

    Подготовка контроллера домена

    Перед развёртыванием PKI необходимо убедиться в работоспособности домена Active Directory и что все необходимые серверы (а именно, веб-сервер и подчинённый ЦС) введены в домен. А так же, что подготовлены необходимые учётные записи. На данном этапе нам потребуется только учётная запись с правами Enterprise Admins.

    Ряд операций на подчинённом ЦС требуют прав Enterprise Admins, поскольку производится запись в раздел configuration naming context. Если это корневой домен леса, то для этих операций достаточно прав Domain Admins.

    Следующим шагом будет конфигурирование политики автоматической выдачи сертификатов (autoenrollment). Эта политика нужна будет в процессе эксплуатации служб сертификатов для автоматической выдачи и обновления истёкших сертификатов на клиентах. Политика настраивается в конфигурации компьютера и пользователя:

    • Computer ConfigurationPoliciesWindows SettingsSecurity SettingsPublic Key InfrastructureCertificate Services Client – Auto-Enrollment
    • User ConfigurationPoliciesWindows SettingsSecurity SettingsPublic Key InfrastructureCertificate Services Client – Auto-Enrollment

    Политика в обоих разделах должна быть сконфигурирована как показано на следующей картинке:

    Сконфигурированный объект групповых политик (GPO) должен быть пристыкован к корню домена. Данную процедуру необходимо повторить во всех доменах текущего леса Active Directory.

    Далее, необходимо создать запись типа CNAME с именем CDP на сервере ДНС, который будет указывать на веб-сервер (IIS). Эту процедуру необходимо выполнить как на внутреннем, так и на внешнем (который обслуживает зону в интернете) серверах ДНС. Запись можно создать при помощи PowerShell:

    Add-DnsServerResourceRecord -CName -Name "cdp" -HostNameAlias "iis.contoso.com" -ZoneName "contoso.сom" 

    Подготовка веб-сервера

    На веб-сервере нам потребуется выполнить следующее: установить службу IIS (если ещё не установлена), создать общую папку и сконфигурировать веб-сайт на использование этой папки.

    • Установка службы IIS

    Для установки службы IIS можно воспользоваться следующей командой:

    Install-WindowsFeature -Name Web-Server, Web-WebServer -IncludeManagementTools
    • Создание папки PKIdata

    Согласно нашей конфигурационной таблице (см. часть 2), для хранения сертификатов ЦС и списков отзыва нам потребуется общая папка с сетевым именем PKI по следующему пути: C:InetPubwwwrootPKIdata

    New-Item -ItemType Directory -Path C:InetPubwwwroot -Name PKIdata -Force
    New-SmbShare -Path C:inetpubwwwrootPKIdata -Name PKI -FullAccess everyone

    После этого нужно выдать права NTFS на запись в эту папку для группы Cert Publishers.

    • Создание веб-сайта

    Теперь нам необходимо создать отдельный веб-сайт с именем “CDP” и хост-именем “cdp.contoso.com”:

    New-Website -Name CDP -HostHeader cdp.contoso.com -PhysicalPath C:inetpubwwwrootPKIdata
    New-WebVirtualDirectory -Site cdp -Name pki -PhysicalPath C:inetpubwwwrootPKIdata
    • Включение поддержки Delta CRL

    В нашем сценарии издающий ЦС будет публиковать Delta CRL, которые содержат символ плюс «+» в имени файла (например, contoso-pica+.crl). По умолчанию, IIS будет расценивать этот символ в запросе как метасимвол и не позволит клиентам скачать список отзыва. Для этого необходимо включить двойной эскейпинг в настройках IIS, чтобы расценивать знак плюса в запросе как литерал:

    Import-Module -Name WebAdministration
    Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter /system.webServer/security/requestFiltering -name allowdoubleescaping -Value 'true'

    Установка корневого ЦС

    Фактическая установка ЦС будет включать в себя несколько этапов:

    1. Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
    2. Установка компонента ЦС;
    3. Выполнение постустановочной конфигурации;
    4. Проверка установки.

    Перед установкой корневого ЦС, необходимо ещё раз вернуться к конфигурационным таблицам:

    Название параметра Значение параметра
    Сервер ЦС
    Класс ЦС Standalone CA
    Тип ЦС Root CA
    Сертификат
    Имя сертификата Contoso Lab Root Certification authority
    Дополнительный суффикс OU=Division Of IT, O=Contoso Pharmaceuticals, C=US
    Провайдер ключа RSA#Microsoft Software Key Storage Provider
    Длина ключа 4096 бит
    Алгоритм подписи SHA256
    Срок действия 15 лет

    В таблице я выделил только те параметры, которые задаются до и в процессе установки. Остальные параметры будут настраиваться после установки.

    Предварительная конфигурация

    Предварительные конфигурационные файлы необходимы для ряда настроек, которые невозможно задать во время установки компонента (ни при помощи графического интерфейса, ни при помощи командной строки или PowerShell). К ним обычно относятся настройки расширений сертификата ЦС. Например, для настройки расширения сертификата Certificate Policies, необходимо использовать предварительный конфигурационный файл, в котором настраиваются параметры расширения. Для Microsoft ADCS таким файлом является файл CAPolicy.inf, который должен быть расположен по следующему пути: %windir%CAPolicy.inf. С синтаксисом этого файла можно ознакомиться в следующей статье: How CA Certificates Work. Поскольку никаких специфичных или нестандартных настроек в сертификате корневого ЦС мы делать не будем, поэтому и предварительный конфигурационный файл сейчас нам не потребуется.

    Установка компонента ЦС

    Прежде всего необходимо добавить установочные компоненты для AD CS:

    Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

    После этого сверьтесь с предыдущей таблицей, чтобы определить параметры установки. Исходя из данных таблицы, зададим параметры для командлета Install-AdcsCertificationAuthority:

    Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Root Certification Authority" `
        -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" `
        -CAType StandaloneRootCA `
        -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
        -KeyLength 4096 `
        -HashAlgorithmName SHA256 `
        -ValidityPeriod "years" `
        -ValidityPeriodUnits 15 `
        -DatabaseDirectory $(Join-Path $env:SystemRoot "System32CertLog")

    Итоговая настройка

    После установки компонента ЦС необходимо настроить рабочие параметры ЦС. Рассмотрим ещё раз элементы, которые нам необходимо настроить:

    Название параметра Значение параметра
    Сервер ЦС
    Срок действия издаваемых сертификатов 15 лет
    Точки публикации CRT 1) По-умолчанию
    2) C:CertDatacontoso-rca<CertificateName>.crt
    3) IIS:InetPubPKIdatacontoso-rca<CertificateName>.crt*
    Точки распространения CRT 1) cdp.contoso.com/pki/contoso-rca<CertificateName>.crt
    Точки публикации CRL 1) По-умолчанию
    2) C:CertDatacontoso-rca<CRLNameSuffix>.crt
    3) IIS:InetPubPKIdatacontoso-rca<CRLNameSuffix>.crt*
    Точки распространения CRL 1) cdp.contoso.com/pki/contoso-rca<CRLNameSuffix>.crt
    Сертификат
    Состав CRL Base CRL
    Base CRL
    Тип Base CRL
    Срок действия 6 месяцев
    Расширение срока действия 1 месяц
    Алгоритм подписи SHA256
    Публикация в AD Нет

    * — копируется на сервер IIS

    Скрипт настройки

    Для конфигурирования настроек ЦС мы будем использовать BATCH скрипт с использованием утилиты certutil.exe:

    ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
    ::                     Root CA post-installation script                               ::
    ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
    :: все комментарии помечены знаком двойного двоеточия (::)
    :: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
    :: в отдельные переменные
    SET CrlLocal=C:CertDatacontoso-rca%%8.crl
    SET CDP=http://cdp.contoso.com/pki/contoso-rca%%8.crl
    SET AIA=http://cdp.contoso.com/pki/contoso-rca%%4.crt
    
    :: Создаём папку в корне системного диска, куда будут записываться файлы ЦС. Эта папка
    :: создаётся для удобства, чтобы не искать папку CertEnroll в глубине папки Windows.
    md C:CertData
    
    :: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва.
    certutil -setreg CACRLPublicationURLs "1:%windir%system32CertSrvCertEnroll%%3%%8.crln1:%CrlLocal%n2:%CDP%"
    
    certutil -setreg CACACertPublicationURLs "1:%windir%system32CertSrvCertEnroll%%1_%%3%%4.crtn2:%AIA%"
    
    :: Поскольку мы не можем указывать пути публикации для файла сертификата, мы
    :: вручную переименовываем его в необходимый формат и копируем в папку CertData
    ren %windir%system32CertSrvCertEnroll*.crt contoso-rca.crt
    copy %windir%system32CertSrvCertEnrollcontoso-rca.crt C:CertData
    
    :: Задаём срок действия издаваемых сертификатов
    certutil -setreg CAValidityPeriodUnits 15
    certutil -setreg CAValidityPeriod "Years"
    
    :: Задаём время жизни списков отзыва согласно нашей конфигурации
    certutil -setreg CACRLPeriodUnits 180
    certutil -setreg CACRLPeriod "Days"
    certutil -setreg CACRLOverlapPeriod "Months"
    certutil -setreg CACRLOverlapUnits 1
    
    :: Отключаем дифференциальные списки отзыва (или Delta CRL)
    certutil -setreg CACRLDeltaPeriodUnits 0
    
    :: Отключаем генерацию кросс-сертификатов
    certutil -setreg caCRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS
    
    :: Конфигурируем ЦС для включения истёкших отозванных сертификатов в списки отзыва
    certutil –setreg caCRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS
    
    :: Включаем полный аудит событий на ЦС**
    certutil -setreg CAAuditFilter 127
    
    :: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
    :: Windows Server 2016 по умолчанию использует SHA256.
    Certutil -setreg cacspCNGHashAlgorithm SHA256
    
    :: Перезапускаем службу ЦС для применения изменений.
    net stop certsvc && net start certsvc
    
    :: Публикуем списки отзыва.
    certutil -CRL

    Ряд команд нуждается в более развёрнутом пояснении. Команды с настройкой расширений CRL Distribution Points и Authority Information Access имеют специфический синтаксис. Во-первых, пути публикации и распространения указываются в одну строку и разделяются символом новой строки «n». Каждый путь начинается с числа и отделяется от самого пути символом двоеточия. Это число в начале пути указывает битовую маску флагов публикации для конкретного пути. Значение каждого бита для расширений CDP и AIA приведено в следующей таблице:

    Название галочки в MMC Числовое значение Название галочки в MMC Числовое значение
    Publish CRLs to this location. 1 Include in the AIA extension of issued
    certificates.
    2
    Include in the CDP extension of issued certificates. 2 Include in the Online Certificate Status. Protocol (OCSP) extension. 32
    Include in CRLs. Clients use this to find Delta CRL locations. 4
    Include in all CRLs. Specifies where to publish in AD DS when publishing manually. 8
    Publish Delta CRLs to this location. 64
    Include in the IDP extension of issued CRLs. 128

    Если взять путь для CDP: 1:%windir%system32CertSrvCertEnroll%%3%%8.crl, то цифра 1 в начале строки говорит о том, что это путь физического размещения файла (Publich CRLs to this location). Другие опции здесь не используются. Для включения пути, который будет публиковаться в издаваемых сертификатах, мы будем использовать опцию «Include in the CDP extension of issued certificates» с числовым значением 2. Такой же принцип применяется и для остальных путей.

    В каждом пути включены переменные с двойным знаком процента «%%». Это переменные, которые ЦС при формировании пути будет автоматически заполнять исходя из типа переменной.

    Первый знак процента используется как эскейп-символ, чтобы процессор командной строки воспринял следующий знак процента как литерал. Дело в том, что знак процента в командном процессоре CMD является служебным символом. Сервер ЦС так же использует знак процента для указания, что это переменная. Для исключения конфликта в командном процессоре используется последовательность из двух знаков процента.

    Следующая таблица содержит описание всех доступных переменных и их краткое описание:

    Переменная в редакторе расширений CDP и AIA Переменная в скрипте Где используется Значение
    <ServerDNSName> %1 CDP/AIA Полное ДНС имя сервера ЦС
    <ServerShortName> %2 CDP/AIA Короткое (NetBIOS) имя сервера ЦС
    <CaName> %3 CDP/AIA Имя ЦС (атрибут CN в сертификате)
    <CertificateName> %4 AIA Индекс сертификата ЦС. Используется только при обновлении сертификата ЦС.
    <ConfigurationContainer> %6 CDP/AIA Путь к configuration naming context в Active Directory
    <CATruncatedName> %7 CDP/AIA Укороченное (санитизированное) имя сертификата ЦС. В общем случае будет совпадать с полным именем ЦС
    <CRLNameSuffix> %8 CDP Индекс ключа ЦС, которым был подписан данный CRL. Используется при обновлении ключевой пары ЦС.
    <DeltaCRLAllowed> %9 CDP Добавляет суффикс для Delta CRL (знак «+»).
    <CDPObjectClass> %10 CDP Класс объекта в Active Directory
    <CAObjectClass> %11 CDP/AIA Класс объекта в Active Directory

    В нашем конкретном случае будут использоваться только две переменные: <CertificateName> и <CRLNameSuffix>. Для исходного сертификата ЦС эти переменные пустые. При обновлении сертификата ЦС, переменная будет заменяться на «(index)», где index — номер сертификата ЦС. Индексирование начинается с нуля. Например, имя файла для последующего сертификата ЦС будет иметь вид: contoso-rca(1).crt. И так далее. То же самое касается и переменной , только здесь будет указываться индекс ключевой пары ЦС.

    Отдельного внимания заслуживает команда, которая включает аудит операций на сервере ЦС, которые регистрируются в системном журнале Security.evtx. К ним относятся все основные операции: запуск/остановка службы, отправление запроса, выпуск или отклонение сертификата, выпуск списка отзыва. Эту строчку можно найти практически в каждом постустановочном скрипте для ЦС, которые можно найти в похожих статьях в интернете. И практически никто не утруждает себя в подробном объяснении механизма его работы, просто копируют из статьи в статью.

    Особенность ведения аудита ЦС заключается в том, что настройка флагов аудита на ЦС является необходимым, но не достаточным условием. Механизм аудита основан на регистрации событий в журнале Security.evtx, который, в свою очередь зависит от настройки политики Audit Object Access в групповых политиках. Т.е. без настройки групповых политик никакого аудита не будет.

    Опытные администраторы знают к чему приводит включение Audit Object Access — к лавинному созданию записей в журнале от других компонентов ОС. Например, аудит доступа файловой системы, реестра, других установленных ролей и т.д. В результате, журнал может буквально за день-два заполниться до отказа. Поэтому для эффективного использования аудита необходимы меры по фильтрации ненужных событий, например, при помощи функции подписки на интересующие события. Нет смысла в аудите, если его никто не может прочитать и эффективно проанализировать. Но эта тема уже выходит за рамки этой статьи.

    Прочие настройки

    После того как корневой ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

    • Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена;
    • Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям;
    • Найдите в корне системного диска папку CertData и убедитесь, что там находится два файла: сертификат и список отзыва. Убедитесь, что поля списка отзыва соответствуют ожидаемым значениям.

    Если всё хорошо, тогда скопируйте содержимое папки C:CertData на сервер IIS в папку PKIData. Сертификат корневого ЦС уже можно импортировать на все устройства, которые будут использовать нашу PKI.

    Для импорта сертификата на доменные клиенты, достаточно загрузить его в Active Directory и после обновления групповых политик на клиентах, сертификат будет установлен в локальные хранилища сертификатов во всём лесу. Для публикации сертификата в AD необходимо выполнить следующую команду:

    Certutil -f -dspublish pathcontoso-rca.crt RootCA

    Для установки сертификата на клиентах в рабочих группах и мобильные устройства необходимо воспользоваться другими инструментами, которые есть в вашем распоряжении. Например, System Center Configuration Manager или Mobile Device Management. Если подходящих инструментов нет, можно копировать и устанавливать сертификат на компьютеры при помощи утилиты certutil.exe. Для установки сертификата в локальное хранилище сертификатов выполните следующую команду:

    Certutil -f -addstore Root pathcontoso-rca.crt

    Установка издающего ЦС

    Как и в случае с корневым ЦС, установка издающего ЦС включает в себя четыре этапа:

    1. Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
    2. Установка компонента ЦС;
    3. Выполнение постустановочной конфигурации;
    4. Проверка установки и конфигурации.

    Предустановочная конфигурация

    Если для корневого ЦС предустановочный конфигурационный файл нам не требовался, то для издающего ЦС он понадобится. В нём мы настроим расширения Certificate Policies и Basic Constraints для сертификата ЦС. Если с политиками всё понятно, то в расширении Basic Constraints мы запретим выдачу сертификатов другим ЦС с издающего ЦС, поскольку у нас двухуровневая иерархия и добавление новых уровней только усложняет нашу структуру и увеличивает время, затрачиваемое на проверку сертификатов клиентами. Также отключим автоматическую загрузку шаблонов из Active Directory в список выдаваемых шаблонов. По умолчанию, сервер ЦС загружает на выдачу некоторый набор шаблонов сертификатов. Это вредно по двум причинам:

    1. Контроллеры домена практически мгновенно обнаруживают появление ЦС в лесу и даже при отключённой политике автоматической выдачи сами запрашивают себе сертификаты.
    2. Администраторы сами должны определять какие шаблоны будут использовать в организации.

    Поэтому мы сконфигурируем ЦС так, что список шаблонов к выдаче будет пустым. Это возможно сделать только через CAPolicy.inf. В нашем случае он будет иметь следующее содержимое:

    ; заголовок INI файла
    [Version]
    Signature= "$Windows NT$"
    
    ; указываем список политик, которые будут включены в сертификат ЦС. В нашем
    ; случае будет одна политика под названием AllIssuancePolicies.
    [PolicyStatementExtension]
    Policies = AllIssuancePolicy
    ; конфигурируем детали самой политики. Ссылку на документ Certificate Practice
    ; Statement (CPS) и объектный идентификатор политики
    [AllIssuancePolicy]
    URL = http://cdp.contoso.com/pki/contoso-cps.html
    OID = 2.5.29.32.0
    [BasicConstraintsExtension]
    IsCA = True
    PathLegth = 0
    IsCritical = True
    ; секция прочих настроек ЦС
    [certsrv_server]
    ; отключаем автоматическую загрузку шаблонов сертификатов для выдачи
    LoadDefaultTemplates = 0

    Файл с именем CAPolicy.inf необходимо скопировать в системную папку Windows до установки ЦС.

    Установка компонента ЦС

    Прежде всего необходимо добавить установочные компоненты для AD CS:

    Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

    После этого посмотрим на установочную таблицу, чтобы определить параметры установки:

    Название параметра Значение параметра
    Сервер ЦС
    Класс ЦС Enterprise CA
    Тип ЦС Subordinate CA
    Автоматическая загрузка шаблонов Нет
    Сертификат
    Имя сертификата Contoso Lab Issuing Certification authority
    Дополнительный суффикс OU=Division Of IT, O=Contoso Pharmaceuticals, C=US
    Провайдер ключа RSA#Microsoft Software Key Storage Provider
    Длина ключа 4096 бит
    Алгоритм подписи SHA256
    Срок действия 15 лет (определяется вышестоящим ЦС)
    Политики выдачи 1) Имя: All Issuance Policies
    OID=2.5.29.32.0
    URL=http://cdp.contoso.com/pki/contoso-cps.html
    Basic Constraints isCA=True (тип сертификата — сертификат ЦС)
    PathLength=0 (запрещается создание других промежуточных ЦС под текущим ЦС).

    В таблице я выделил только те параметры, которые задаются в процессе установки. Остальные параметры будут настраиваться после установки. Исходя из этих данных сформируем параметры для командлета Install-AdcsCertificationAuthority:

    Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Issuing Certification authority" `
        -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" `
        -CAType EnterpriseSubordinateCa `
        -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
        -KeyLength 4096 `
        -HashAlgorithmName SHA256

    После выполнения этой команды будет выведено сообщение о том, что установка ЦС не завершена и для её завершения необходимо отправить сгенерированный запрос (находится в корне системного диска) на вышестоящий ЦС и получить подписанный сертификат. Поэтому находим файл с расширением «.req» в корне системного диска и копируем его на корневой ЦС и на корневом ЦС выполняем следующие команды:

     # отправляем запрос на ЦС.
    certreq -submit 'C:CA-01.contoso.com_Contoso Lab Issuing Certification authority.req'
    # предыдущая команда выведет номер запроса. Укажите этот номер запроса в следующей команде
    # в моём случае это номер 2
    certutil -resubmit 2
    # после выпуска сертификата сохраните его в файл. При этом укажите тот же самый номер
    # запроса, который был указан после выполнения первой команды
    certreq -retrieve 2 C:subca.crt

    Полученный файл (subca.crt) необходимо скопировать обратно на издающий ЦС и завершить инсталляцию:

    certutil -installcert c:subca.crt
    net start certsvc

    Мы устанавливаем на ЦС выписанный сертификат и запускаем службу сертификатов. После успешной установки можно запустить оснастку Certification Authorities MMC (certsrv.msc) и убедиться, что сертификат успешно установлен и ЦС в работающем состоянии. Теперь осталось дело за постустановочной конфигурацией.

    Итоговая настройка

    По аналогии с корневым ЦС, нам потребуется сконфигурировать ряд параметров на издающем ЦС. Для этого мы снова напишем BATCH скрипт с использованием утилиты certutil.exe. Но прежде всего посмотрим установочную таблицу и выясним параметры, которые нам необходимо настроить:

    Аналогичная таблица составляется и для издающего ЦС.

    Название параметра Значение параметра
    Сервер ЦС
    Срок действия издаваемых сертификатов Максимально: 5 лет (остальное контролируется шаблонами сертификатов)
    Публикация в AD (контейнеры) AIA
    NTAuthCertificates
    Состав CRL Base CRL
    Delta CRL
    Точки публикации CRT 1) По-умолчанию
    2) \IISPKIcontoso-pica<CertificateName>.crt
    Точки распространения CRT 1) cdp.contoso.com/pki/contoso-pica<CertificateName>.crt
    Точки публикации CRL 1) По-умолчанию
    2) \IISPKIcontoso-pica<CRLNameSuffix><DeltaCRLAllowed>.crl
    Точки распространения CRL 1) cdp.contoso.com/pki/contoso-pica<CRLNameSuffix><DeltaCRLAllowed>.crl
    Base CRL
    Тип Base CRL
    Срок действия 1 неделя
    Расширение срока действия По умолчанию
    Алгоритм подписи SHA256
    Публикация в AD Нет
    Delta CRL
    Тип Delta CRL
    Срок действия 1 день
    Расширение срока действия По-умолчанию
    Алгоритм подписи SHA256
    Публикация в AD Нет

    За основу мы возьмём скрипт с корневого ЦС и изменим только отдельные фрагменты:

    ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
    ::                     Issuing CA post-installation script                            ::
    ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
    :: все комментарии помечены знаком двойного двоеточия (::)
    :: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
    :: в отдельные переменные
    SET CrlLocal=\IISPKIcontoso-pica%%8%%9.crl
    SET CDP=http://cdp.contoso.com/pki/contoso-pica%%8%%9.crl
    SET AIA=http://cdp.contoso.com/pki/contoso-pica%%4.crt
    
    :: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва.
    certutil -setreg CACRLPublicationURLs "1:%windir%system32CertSrvCertEnroll%%3%%8%%9.crln65:%CrlLocal%n6:%CDP%"
    
    certutil -setreg CACACertPublicationURLs "1:%windir%system32CertSrvCertEnroll%%1_%%3%%4.crtn2:%AIA%"
    
    :: Поскольку мы не можем указывать пути публикации для файла сертификата, мы
    :: вручную переименовываем его в необходимый формат и копируем в сетевую папку
    ren %windir%system32CertSrvCertEnroll*.crt contoso-pica.crt
    copy %windir%system32CertSrvCertEnrollcontoso-pica.crt \IISPKI
    
    :: Задаём срок действия издаваемых сертификатов
    certutil -setreg CAValidityPeriodUnits 5
    certutil -setreg CAValidityPeriod "Years"
    
    :: Задаём время жизни списков отзыва согласно нашей конфигурации
    :: базовый CRL
    certutil -setreg CACRLPeriodUnits 1
    certutil -setreg CACRLPeriod "weeks"
    
    :: Delta CRL
    certutil -setreg CACRLDeltaPeriodUnits 1
    certutil -setreg CACRLDeltaPeriod "days"
    
    :: Включаем полный аудит событий на ЦС**
    certutil -setreg CAAuditFilter 127
    
    :: Включаем наследование расширения Certificate Policies в издаваемых сертификатах 
    certutil -setreg PolicyEnableRequestExtensionList +"2.5.29.32"
    
    :: Включаем поддержку расширения OcspRevNoCheck, если планируется установка
    :: сетевого ответчика (Online Responder или OCSP сервера)
    certutil -v -setreg policyeditflags +EDITF_ENABLEOCSPREVNOCHECK
    
    :: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
    :: Windows Server 2016 по умолчанию использует SHA256.
    Certutil -setreg cacspCNGHashAlgorithm SHA256
    
    :: Перезапускаем службу ЦС для применения изменений.
    net stop certsvc && net start certsvc
    
    :: Публикуем списки отзыва.
    certutil -CRL

    Заметим, что в путях CRLDistribution Points, изменены флаги публикации (добавлена публикация Delta CRL) и добавлена переменная %9 в имя файла для поддержки уникального имени для дельты.

    Здесь мы больше не создаём папку в корне системного диска, а используем сетевую папку PKI на сервере IIS, куда напрямую копируем файл сертификата и публикуем списки отзыва.

    Прочие настройки

    После того как издающий ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

    • Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена
    • Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям.
    • Откройте сетевую папку PKI (на сервере IIS) и убедитесь, что там есть два файла сертификата (корневого и издающего ЦС) и три списка отзыва (один для корневого, два для издающего ЦС). Убедитесь, что поля в сертификатах и списках отзыва соответствуют ожидаемым значениям.

    Когда основные параметры проверены, необходимо убедиться в правильной связи иерархии ЦС и доступности всех внешних файлов для клиентов. Для этого на сервере ЦС (а лучше, на рабочей станции, где установлены средства удалённого администрирования ЦС) необходимо запустить оснастку Enterprise PKI Health (pkiview.msc). Оснастка автоматически построит текущую иерархию и проверит доступность всех путей для скачивания сертификатов ЦС и списков отзыва. Никаких ошибок быть не должно. Если есть ошибка, необходимо её точно идентифицировать и устранить. В случае успешной настройки оснастка будет выглядеть следующим образом для корневого ЦС:

    И для издющего ЦС:

    Если вся итоговая конфигурация соответствует ожидаемым значениям и оснастка Enterprise PKI Health не показывает ошибок, это может судить о том, что PKI установлена верно.

    Рекомендации

    После того, как все ЦС установлены, сконфигурированы и их работоспособность проверена, можно приступать к их эксплуатации. В этом разделе я дам несколько полезных рекомендаций, которых следует придерживаться, чтобы предостеречь себя от возможных потенциальных проблем во время эксплуатации PKI.

    Шаблоны сертификатов

    Наряду с установкой издающего ЦС, в Active Directory устанавливается набор уже готовых шаблонов сертификатов. Их можно просмотреть в оснастке Certificate Templates MMC (certtmpl.msc). Рекомендации по шаблонам сертификатов:

    Использование готовых шаблонов сертификатов

    Я рекомендую использовать их копии, даже если вы не планируете вносить в них изменения. Для создания копии шаблона выберите в списке подходящий шаблон, в контекстном меню выберите Duplicate Template и создайте его копию. Целесообразно в имя шаблона включить название компании, чтобы отличить предустановленный шаблон от вами созданного. Например, Contoso Web Server, Contoso Smart Card Logon. Это позволит сравнить настройки исходного и вами созданного шаблона в случае неработоспособности шаблона.

    Версия шаблона

    Начиная с Windows Server 2012, интерфейс создания шаблона несколько изменился. В самом начале появляется окно с выбором версии ОС на ЦС и предполагаемом клиенте:

    Если у вас используются современные версии ОС (например, Windows 7 и выше), может появиться желание выставить настройки на максимум. Если вы не уверены, что ваше приложение совместимо с CNG (Cryptography Next Generation), следует использовать настройки, которые приведены на картинке. Если вы выставляете ОС сервера и клиента выше, чем Windows Server 2003/Windows XP, шаблон будет использовать криптографию несовместимую с этими приложениями. Например, большинство приложений, написанных на .NET, семейство продуктов System Center, службы федераций (AD FS) и т.д. не смогут использовать ключи таких сертификатов (но проверять смогут).

    Успешно такие сертификаты смогут использовать приложения, которые используют не .NET, а нативные функции CryptoAPI. К таким приложениям можно отнести, например, IIS, Remote Desktop Services.


    Поля Subject и Subject Alternative Names

    Существует два метода заполнения поля Subject и расширения Subject Alternative Names: автоматический и ручной. Это настраивается в настройках шаблона сертификата, во вкладке Subject Name.

    Если выбран второй пункт (как на картинке), ЦС игнорирует имя субъекта из запроса сертификата и заполняет эти поля из свойств учётной записи пользователя или устройства, которое запрашивает сертификат. В ряде случаев это не подходит (например, сертификаты для внутренних веб-сайтов) и имя субъекта заполняется из значения в запросе сертификата. Тогда переключатель необходимо выставить в верхнее положение. Дополнительно к этому, на вкладке Issuance Requirements обязательно надо выставить галочку «CA certificate manager approval».

    Это необходимо затем, что имя для сертификата никак не проверяется. Если этот момент не контролировать, пользователь может запросить сертификаты на любое имя и скомпрометировать весь лес Active Directory. Вряд ли вы позволите рядовому пользователю получить сертификат на имя администратора. После требования одобрения запроса менеджером сертификатов на ЦС, каждый запрос с явным указанием субъекта сертификата будет попадать на ЦС в папку Pending Requests и не будет подписан, пока оператор ЦС не изучит его содержимое и не примет решение о выпуске. Т.е. каждый такой запрос необходимо вручную проверять на содержимое и убедиться, что в запросе указаны верные и допустимые имена. В противном случае запрос должен быть отклонён.

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

    Шаблоны сертификатов в Active Directory хранятся в разделе configuration naming context, который реплицируется между всеми контроллерами домена в лесу. Поэтому для назначения прав на шаблоны сертификатов можно использовать только глобальные и универсальные группы. Избегайте назначения прав отдельным пользователям и устройствам.

    Обновление сертификатов ЦС

    Периодически необходимо обновлять сертификаты ЦС. Рассмотрим несколько аспектов, связанных с обновлением сертификатов ЦС.

    Периодичность обновления сертификата ЦС

    Это делается в следующих случаях:

    • Срок жизни сертификата ЦС истекает;
    • Ключ ЦС скомпрометирован;
    • Необходимо изменить длину ключа или алгоритм подписи;
    • Слишком большой список отзыва (больше нескольких мегабайт).

    Первый вопрос, если всё идёт штатно, за какое время до истечения срока действия сертификата ЦС его нужно обновлять?

    Сертификат издающего ЦС должен обновляться за максимальный срок действия издаваемых сертификатов. В нашем случае срок действия сертификата издающего ЦС 15 лет, а максимальный срок действия издаваемых сертификатов 5 лет (см. конфигурационную таблицу). Это означает, что сертификат издающего ЦС необходимо обновить через 10 лет. Если это время затянуть, то мы не сможем обеспечить необходимый срок действия для самого долгосрочного шаблона.

    Порядок обновления ЦС

    В нашей двухуровневой иерархии сертификаты корневого и издающего ЦС имеют одинаковый срок действия. Поэтому, когда вы принимаете решение об обновлении сертификата любого ЦС, необходимо обновлять их вместе. Первым обновляется сертификат корневого ЦС, затем сертификат издающего ЦС.

    Генерация ключей при обновлении сертификатов ЦС

    При обновлении сертификатов ЦС вам предлагается две опции: использовать существующую ключевую пару или сгенерировать новую:

    В диалоговом окне обновления ключевой пары приведены рекомендации Microsoft по выбору ключевой пары. Однако, практика показывает, что эти рекомендации устарели. Следует всегда генерировать новую ключевую пару. При использовании нескольких сертификатов ЦС клиентский модуль построения цепочки сертификатов иногда может ошибиться и выбрать неправильный сертификат. В базе знаний Microsoft отмечены такие проблемы. Примеры статей:

    • Certificate validation fails when a certificate has multiple trusted certification paths to root CAs.
    • «0x80092013, CRYPT_E_REVOCATION_OFFLINEA» error message when you try to verify a certificate that has multiple chains in Windows Server 2008 or in Windows Vista.

    При генерации новой ключевой пары для каждого сертификата будет гарантирован только один путь к корневому сертификату и модуль построения цепочек сертификатов уже не ошибётся.

    Резервное копирование

    Вопросы резервного копирования и восстановления после отказа являются отдельной темой. Здесь я лишь отмечу основные моменты, которые следует учесть при планировании стратегии резервного копирования.

    Microsoft Active Directory Certificate Services предоставляет инструменты для резервного копирования компонентов ЦС:

    • Оснастка Certification Authority MMC (certsrv.msc);
    • Утилита certutil.exe с параметром -backup.

    С ними можно сделать резервную копию для ключевой пары ЦС и базы данных. Однако эти инструменты не позволяют делать резервную копию настроек ЦС. Эти операции необходимо выполнять вручную. Все настройки ЦС находятся в реестре по следующему пути:

    HKLMSystemCurrentControlSetServicesCertSvc

    При резервном копировании всегда экспортируйте данную ветку реестра. При восстановлении ЦС сохранённый REG файл импортируется обратно в реестр после установки роли ЦС.

    Полный список элементов ЦС, который подлежит обязательному резервному копированию выглядит так:

    • Ключи и сертификаты ЦС;
    • База данных ЦС;
    • Настройки ЦС из реестра;
    • Предустановочный конфигурационный файл;
    • Установочные и конфигурационные скрипты.

    Этот список не зависит от принятой в вашей компании стратегии резервного копирования, он всегда должен быть включён в список резервных копий.

    Об авторе

    Вадим Поданс — специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его сайте.

    Содержание

    1. How to import third-party certification authority (CA) certificates into the Enterprise NTAuth store
    2. More information
    3. Method 1 — Import a certificate by using the PKI Health Tool
    4. Method 2 — Import a certificate by using Certutil.exe
    5. Microsoft recommended driver block rules
    6. Add partner certification authority in Intune using SCEP
    7. Overview
    8. Set up third-party CA integration
    9. Validate third-party certification authority
    10. Authorize communication between CA and Intune
    11. Create an application in Azure Active Directory
    12. Configure and deploy a SCEP certificate profile
    13. Removing certificates
    14. Third-party certification authority partners
    15. Microsoft windows third party component ca 2014
    16. About

    How to import third-party certification authority (CA) certificates into the Enterprise NTAuth store

    There are two methods you can use to import the certificates of third-party CAs into the Enterprise NTAuth store. This process is required if you’re using a third-party CA to issue smart card logon or domain controller certificates. By publishing the CA certificate to the Enterprise NTAuth store, the Administrator indicates that the CA is trusted to issue certificates of these types. Windows CAs automatically publish their CA certificates to this store.

    Original product version: В Windows Server 2016, Windows Server 2012 R2
    Original KB number: В 295663

    More information

    The NTAuth store is an Active Directory directory service object that is located in the Configuration container of the forest. The Lightweight Directory Access Protocol (LDAP) distinguished name is similar to the following example:

    CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=MyDomain,DC=com

    Certificates that are published to the NTAuth store are written to the cACertificate multiple-valued attribute. There are two supported methods to append a certificate to this attribute.

    Method 1 — Import a certificate by using the PKI Health Tool

    PKI Health Tool (PKIView) is an MMC snap-in component. It displays the status of one or more Microsoft Windows CAs that comprise a PKI. It’s available as part of the Windows Server 2003 Resource Kit Tools.

    PKIView gathers information about the CA certificates and certificate revocation lists (CRLs) from each CA in the enterprise. Then it validates the certificates and CRLs to ensure that they’re working correctly. If they aren’t working correctly, or they’re about to fail, PKIView provides a detailed warning or some error information.

    PKIView displays the status of Windows Server 2003 CAs that are installed in an Active Directory forest. You can use PKIView to discover all PKI components, including subordinate and root CAs that are associated with an enterprise CA. The tool can also manage important PKI containers, such as root CA trust and NTAuth stores, that are also contained in the configuration partition of an Active Directory forest. This article discusses this latter functionality. For more information about PKIView, see the Microsoft Windows Server 2003 Resource Kit Tools documentation.

    You can use PKIView to manage both Windows 2000 CAs and Windows Server 2003 CAs. To install the Windows Server 2003 Resource Kit Tools, your computer must be running Windows XP or later.

    To import a CA certificate into the Enterprise NTAuth store, follow these steps:

    Export the certificate of the CA to a .cer file. The following file formats are supported:

    • DER encoded binary X.509 (.cer)
    • Base-64 encoded X.509 (.cer)

    Install the Windows Server 2003 Resource Kit Tools. The tools package requires Windows XP or later.

    Start Microsoft Management Console (Mmc.exe), and then add the PKI Health snap-in:

    1. On the Console menu, select Add/Remove Snap-in.
    2. Select the Standalone tab, and then select the Add button.
    3. In the list of snap-ins, select Enterprise PKI.
    4. Select Add, and then select Close.
    5. Select OK.

    Right-click Enterprise PKI, and then select Manage AD Containers.

    Select the NTAuthCertificates tab, and then select Add.

    On the File menu, select Open.

    Locate and then select the CA certificate, and then select OK to complete the import.

    Method 2 — Import a certificate by using Certutil.exe

    Certutil.exe is a command-line utility for managing a Windows CA. In Windows Server 2003, you can use Certutil.exe to publish certificates to Active Directory. Certutil.exe is installed with Windows Server 2003. It is also available as part of the Microsoft Windows Server 2003 Administration Tools Pack.

    To import a CA certificate into the Enterprise NTAuth store, follow these steps:

    Export the certificate of the CA to a .cer file. The following file formats are supported:

    • DER encoded binary X.509 (.cer)
    • Base-64 encoded X.509 (.cer)

    At a command prompt, type the following command, and then press ENTER:

    The contents of the NTAuth store are cached in the following registry location:
    HKEY_LOCAL_MACHINESOFTWAREMicrosoftEnterpriseCertificatesNTAuthCertificates

    This registry key should be automatically updated to reflect the certificates that are published to the NTAuth store in the Active Directory configuration container. This behavior occurs when Group Policy settings are updated and when the client-side extension that’s responsible for autoenrollment executes. In certain scenarios, such as Active Directory replication latency or when the Do not enroll certificates automatically policy setting is enabled, the registry isn’t updated. In such scenarios, run the following command manually to insert the certificate into the registry location:

    Microsoft recommended driver block rules

    Applies to:

    • WindowsВ 10
    • WindowsВ Server 2016 and above

    Microsoft has strict requirements for code running in kernel. Consequently, malicious actors are turning to exploit vulnerabilities in legitimate and signed kernel drivers to run malware in kernel. One of the many strengths of the Windows platform is our strong collaboration with independent hardware vendors (IHVs) and OEMs. Microsoft works closely with our IHVs and security community to ensure the highest level of driver security for our customers and when vulnerabilities in drivers do arise, that they are patched and rolled out to the ecosystem in an expedited manner. Microsoft then adds the vulnerable versions of the drivers to our ecosystem block policy which is applied to the following sets of devices:

    • Hypervisor-protected code integrity (HVCI) enabled devices
    • Windows 10 in S mode (S mode) devices

    Microsoft recommends enabling HVCI or S mode to protect your devices against security threats. If this is not possible, Microsoft recommends blocking the following list of drivers by merging this policy with your existing Windows Defender Application Control policy. Blocking kernel drivers without sufficient testing can result in devices or software to malfunction, and in rare cases, blue screen. It is recommended to first validate this policy in audit mode and review the audit block events.

    This application list will be updated with the latest vendor information as application vulnerabilities are resolved and new issues are discovered. It is recommended that this policy be first validated in audit mode before rolling the rules into enforcement mode.

    Add partner certification authority in Intune using SCEP

    Use third-party certification authorities (CA) with Intune. Third-party CAs can provision mobile devices with new or renewed certificates by using the Simple Certificate Enrollment Protocol (SCEP), and can support Windows, iOS/iPadOS, Android, and macOS devices.

    There are two parts to using this feature: open-source API, and the Intune administrator tasks.

    Part 1 — Use an open-source API
    Microsoft created an API to integrate with Intune. Though the API you can validate certificates, send success or failure notifications, and use SSL, specifically SSL socket factory, to communicate with Intune.

    The API is available on the Intune SCEP API public GitHub repository for you to download, and use in your solutions. Use this API with third-party SCEP servers to run custom challenge validation against Intune before SCEP provisions a certificate to a device.

    Integrate with Intune SCEP management solution provides more details on using the API, its methods, and testing the solution you build.

    Part 2 — Create the application and profile
    Using an Azure Active Directory (Azure AD) application, you can delegate rights to Intune to handle SCEP requests coming from devices. The Azure AD application includes application ID and authentication key values that are used within the API solution the developer creates. Administrators then create and deploy SCEP certificates profiles using Intune and can view reports on the deployment status on the devices.

    This article provides an overview of this feature from an Administrator-perspective, including creating the Azure AD application.

    Overview

    The following steps provide an overview of using SCEP for certificates in Intune:

    1. In Intune, an administrator creates a SCEP certificate profile, and then targets the profile to users or devices.
    2. The device checks in to Intune.
    3. Intune creates a unique SCEP challenge. It also adds additional integrity-check information, such as what the expected subject and SAN should be.
    4. Intune encrypts and signs both the challenge and integrity-check information, and then sends this information to the device with the SCEP request.
    5. The device generates a certificate signing request (CSR) and public/private key pair on the device based on the SCEP certificate profile that’s pushed from Intune.
    6. The CSR and encrypted/signed challenge are sent to the third-party SCEP server endpoint.
    7. The SCEP server sends the CSR and the challenge to Intune. Intune then validates the signature, decrypts the payload, and compares the CSR to the integrity-check information.
    8. Intune sends back a response to the SCEP server, and states whether the challenge validation is successful or not.
    9. If the challenge is successfully verified, then the SCEP server issues the certificate to the device.

    The following diagram shows a detailed flow of third-party SCEP integration with Intune:

    Set up third-party CA integration

    Validate third-party certification authority

    Before integrating third-party certification authorities with Intune, confirm that the CA you’re using supports Intune. Third-party CA partners (in this article) includes a list. You can also check your certification authority’s guidance for more information. The CA may include setup instructions specific to their implementation.

    To support Android Enterprise Device Owner devices, the CA must support use of an HTTPS URL when you configure the HTTP Server URL for the SCEP certificate profile.

    Authorize communication between CA and Intune

    To allow a third-party SCEP server to run custom challenge validation with Intune, create an app in Azure AD. This app gives delegated rights to Intune to validate SCEP requests.

    Be sure you have the required permissions to register an Azure AD app. See Required permissions, in the Azure AD documentation.

    Create an application in Azure Active Directory

    In the Azure portal, go to Azure Active Directory > App Registrations, and then select New registration.

    On the Register an application page, specify the following details:

    • In the Name section, enter a meaningful application name.
    • For the Supported account types section, select Accounts in any organizational directory.
    • For Redirect URI, leave the default of Web, and then specify the sign-on URL for the third-party SCEP server.

    Select Register to create the application and to open the Overview page for the new app.

    On the app Overview page, copy the Application (client) ID value and record it for later use. You’ll need this value later.

    In the navigation pane for the app, go to Certificates & secrets under Manage. Select the New client secret button. Enter a value in Description, select any option for Expires, and then and choose Add to generate a value for the client secret.

    Before you leave this page, copy the value for the client secret and record it for later use with your third-party CA implementation. This value is not shown again. Be sure to review the guidance for your third-party CA on how they want the Application ID, Authentication Key, and Tenant ID configured.

    Record your Tenant ID. The Tenant ID is the domain text after the @ sign in your account. For example, if your account is admin@name.onmicrosoft.com, then your tenant ID is name.onmicrosoft.com.

    In the navigation pane for the app, go to API permissions under Manage, and then select Add a permission.

    On the Request API permissions page, select Intune, and then select Application permissions. Select the checkbox for scep_challenge_provider (SCEP challenge validation).

    Select Add permissions to save this configuration.

    Remain on the API permissions page, and select Grant admin consent for Microsoft, and then select Yes.

    The app registration process in Azure AD is complete.

    Configure and deploy a SCEP certificate profile

    As the administrator, create a SCEP certificate profile to target to users or devices. Then, assign the profile.

    Removing certificates

    When you unenroll or wipe the device, the certificates are removed. The certificates aren’t revoked.

    Third-party certification authority partners

    The following third-party certification authorities support Intune:

    If you’re a third-party CA interested in integrating your product with Intune, review the API guidance:

    Microsoft windows third party component ca 2014

    A Simple PE File Signature information Extracting Tool.

    This program is used to get signature information from PE files which signed by a/some embedded code signature certificate(s) on Windows. Supporting multi-signed file info and certificates chain. Runned on Windows Vista, Windows 7, or later OS platform.

    This code uses CryptoAPIs to parse the signature and certificate data from specified file, supporting many file types, such as .exe, .cat(catalog file), .dll, .sys, etc.

    这个程序用来从由1个或多个嵌入式代码签名证书所签名的PE文件中获取签名信息。支持多签名文件信息和证书链的提取。运行在Windows Vista,Windows 7,及更新的操作系统平台。

    这份代码使用 CryptoAPIs 来解析指定文件中的签名和证书数据,支持多种文件类型,包括exe,cat(catalog文件),dll,sys等格式。

    Developer can compile this program with Microsoft Visual Studio 2008 or later version Visual Studio. The target binary file will be built at Debug or Release folder, depending on which compiling method developers select.

    开发者可以通过Microsoft Visual Studio 2008或更新版本的Visual Studio来编译这个程序。目标二进制文件会在Debug或Release目录生成,这取决于开发者选择何种编译方式。

    This code does not use WinVerifyTrust to verify and retrieve signature and certificate information, but CryptoAPIs instead.

    It might also be noted that this program supports analyzing multi-signed PE files, even though on the OS platforms which does not support multi-signature detecting, such as Windows 7, Windows Vista, etc. Multi-signed PE file means that this file has been signed by more than one embedded code signature certificate.

    If you transfer the path to a multi-signatured file into PESignAnalyzer process, it will show the target information as below. Every [The X Sign Info] means a chunk of completed information of a signature block.

    这份代码没有使用 WinVerifyTrust 来验证和获取签名证书信息,而是用 CryptoAPIs 代替。

    需要注意的是,这个程序支持解析多签名的PE文件,即使是在诸如Windows 7,Windows Vista这种不支持多签名检测的操作系统平台上。多签名的PE文件意味着这个文件已经被多个嵌入式代码签名证书所签名了。

    如果你将一个多签名文件的路径作为参数传递给PESignAnalyzer的二进制文件,它会展示如下所示的信息。 每一个 [The X Sign Info] 意味着一个签名的完整信息。

    If you have any questions or problems, you can contact with me: leeqwind123@outlook.com

    About

    This program can retrieve signature information from PE files which signed by one or more certificates on Windows. Supporting multi-signed (nested) infomation and certificate-chain.

    Hi all,

    Today lets go through a step by step on how to Deploy a Standalone Root CA in Server 2012 R2. This will be a Part 1 of the ADCS deployment…

    1st. what is Certification Authority (CA) ?

    A CA is a well-designed and highly trusted service in an enterprise, which provides users and computers with certificates, maintains the CRLs, and optionally responds to OCSP requests. You can install a CA in your environment by deploying the AD CS role on Windows Server 2012. When you install the first CA, it establishes the PKI in the network, and it provides the highest point in the entire structure. You can have one or more certification authorities in one network, but only one CA can be at the highest point on the CA hierarchy.

    The main purposes of the CA are to issue certificates, revoke certificates, and publish AIA and CRL information. By doing this, the CA ensures that users, services, and computers are issued certificates that can be validated.

    A CA performs multiple functions or roles in a PKI. In a large PKI, separation of CA roles among multiple servers is common. A CA provides several management tasks, including:

    • Verifying the identity of the certificate requestor.

    • Issuing certificates to requesting users, computers, and services.

    • Managing certificate revocation.

    When you deploy a first CA (root CA) in your network, it issues a certificate for itself. After that, other CAs receive certificates from the first CA. You can also choose to issue a certificate for your CA by using one of public CAs.

    For more info on Windows Server 2012 R2 CA, please refer to : http://technet.microsoft.com/en-us/library/hh831574.aspx

    Before I start, let get down to the Server for this Demo, for this CA deployment, I will be using only 2 Server which is my Domain Controller (DC01.comsys.local and my member Server which is SVR01.comsys.local). the standalone Root CA will be install in SVR01.comsys.local.

    Orait, lets get started :

    1 – On the SVR01.comsys.local server, click Add roles and features…

    1

    2 – On the Before you begin box, click Next to proceed…

    2

    3 – On the Select installation type box, verify that you select Role-Based or feature-based installation and click Next…

    3

    4 – On the Select destination server box, click Next

    4

    5 – On the Select server roles box, select Active Directory Certificate Services. ** When the Add Roles and Features Wizard displays, click Add Features, and then click Next…

    5

    6

    6 – On the Select features box, click Next

    7

    7 – On the Active Directory Certificate Services box, click Next

    8

    8 – On the Select role services box, verify that Certification Authority is selected, and then click Next to proceed…

    9

    9 – On the Confirm installation selections box, click Install

    10

    10-  On the Installation progress page, after installation completes successfully, click the text Configure Active Directory Certificate Services on the destination server…

    11

    12

    11 – In the AD CS Configuration Wizard box, on the Credentials box, click Next

    13

    12 – On the Role Services box, select Certification Authority, and then click Next

    14

    13 – On the Setup Type box, select Standalone CA, and then click Next…

    15

    14 – On the CA Type box, verify that root CA is selected, and then click Next…

    16

    15 – On the Private Key box, verify that Create a new private key is selected, and then click Next…

    17

    16 – On the Cryptography for CA box, keep the default selections for Cryptographic Service Provider (CSP) and Hash Algorithm, but set the Key length to 4096, and then click Next

    18

    17 – On the CA Name box, in the Common name for this CA box, verify that Comsys-SVR01-CA is listed, and then click Next…

    19

    18 – On the Validity Period box, I choose 1 year only instead of 5 years CA expiration and click Next…

    20

    19 – On the CA Database box, click Next

    21

    20 – On the Confirmation box, click Configure

    22

    21 – On the Results box, click Close (verify that Configuration succeeded)…

    23

    22 – Next, you need to configure a new certificate revocation location, for this demo I will keep my CA in DC01 server…

    On the Server Manager, click Tools, and then click Certification Authority…

    24

    23 – In the certsrv – [Certification Authority (Local)] console, right-click Comsys-SVR01-CA, and then click Properties…

    25

    24 – In the Comsys-SVR01-CA dialog box, click the Extensions tab then on select extension drop-down list, click CRL Distribution Point (CDP) and then click the Add button…

    26

    25 – In the Location text box, type http://svr01.comsys.local/CertData/, in the Variable drop-down list box, click <CaName>, and then click Insert

    27

    26 – In the Variable drop-down list box, click <CRLNameSuffix>, and then click Insert

    28

    27 – In the Variable drop-down list box, click <DeltaCRLAllowed>, and then click Insert, then at the end of URL, type .crl, and then click OK

    29

    28 – Next, tick the following options, and then click Apply:

    – Include in CRLs. Clients use this to find Delta CRL locations

    – Include in the CDP extensions of issued certificates

    30

    29 – In the Certification Authority pop-up box, click No

    31

    30 – In the Select extension drop-down list box, click Authority Information Access (AIA), and then click Add

    32

    31 – In the Location text box, type http://svr01.comsys.local/CertData/, in Variable drop-down boxclick <ServerDNSName>, and then click Insert

    33

    32 – In the Location text box, type an underscore (_), in the Variable drop-down list box, click <CaName>, and then click Insert. Put your cursor at the end of URL…

    34

    33 – In the Variable drop-down list box, click <CertificateName>, and then click Insert

    35

    34 – In the Location text box, put your cursor at the end of URL, type .crt, and then click OK

    36

    35 – Select the Include in the AIA extension of issued certificates box, and then click OK

    37

    36 – Click Yes to restart Certification Authority service…

    38

    37 – In the Certification Authority console, expand Comsys-SVR01-CA, right-click Revoked Certificates, point to All Tasks, and then click Publish…

    39

    38 – In the Publish CRL box, click OK

    40

    39 – Right-click Comsys-SVR01-CA, and then click Properties

    41

    40 – In the Comsys-SVR01-CA Properties box, click View Certificate

    42

    41 – In the Certificate box, click the Details tab and then click Copy to File…

    43

    42 – In the Certificate Export Wizard, on the Welcome box, click Next

    44

    43 – On the Export File Format box, select DER encoded binary X.509 (.CER), and then click Next…

    45

    44 – On the File to Export box, click Browse and then in the File name text box, type \dc01C$, and then press Enter…

    46

    47

    45 – In the File name text box, type RootCA, click Save, and then click Next

    48

    49

    46 – Click Finish, and then click OK

    50

    51

    47 – Next, browse to C:WindowsSystem32CertSrvCertEnroll, copy both files…

    52

    48 – and then paste to \dc01c$…

    53

    54

    Orait, we done for now, we have successfully deploy a root standalone CA in SVR01 server.

    In my part 2, I will still continue with CA but next round lets try deploy Enterprise Subordinate CA…

    Wait for my part 2…….

    Установка и настройка Active Directory Certificate Services
    В этой статье я подробно расскажу о процессе установки и настройки Active Directory Certificate Services.

    Служба сертификации Active Directory создает центр сертификации, предназначенный для выдачи сертификатов пользователям. Служба может быть настроена и работать через веб-интерфейс.

    В примере я разбираю Active Directory Certificate Services на операционной системе Windows Server 2012.

    Первым делом нам нужно установить службу сертификации Active Directory.

    Для этого нужно запустить диспетчер сервера.

    Запуск диспетчера сервера

    Далее жмем «Добавить роли и компоненты». Кнопка далее.

    Диспетчер сервера

    Выбираем пункт установка ролей или компонентов, а затем выбираем наш сервер.

    Установка ролей и компонентов

    В следующем окне выбираем пункт службы сертификатов Active Directory.

    В окне выбора компонентов жмем далее.

    В окне служба ролей выбираем пункт центр сертификации.

    службы сертификатов Active Directory

    Запускаем процесс установки.

    После этого по аналогии устанавливаем веб-службу регистрации сертификатов.

    Веб-служба регистрации сертификатов

    Установка завершена. Перейдем к настройке.

    Настройка службы сертификатов Active Directory

    Заходим в настройки.

    Настройки службы сертификации

    Выбираем службу центр сертификации.

    Выбираем службу центр сертификации

    Вариант установки – центр сертификации предприятия.

    центр сертификации предприятия

    Тип центра сертификации – корневой. Это необходимо для того, что бы в дальнейшем мы могли самостоятельно выдавать и подписывать сертификаты.

    Тип центра сертификации

    В следующем окне нужно выбрать пункт создать новый закрытый ключ.

    создать новый закрытый ключ

    Затем необходимо указать параметры шифрования. Вы можете указать свои параметры, или параметры как у меня на рисунке ниже.

    параметры шифрования

    В следующем окне указывается имя центра шифрования.

    имя центра шифрования

    Затем указывается срок действия центра сертификации. По умолчанию он равен 5 годам. Так и оставим.

    срок действия центра сертификации

    После нажатия кнопки далее вам нужно будет указать физическое место на жестком диске для хранения базы данных.

    Место расположения базы данных

    Подтверждаем настройку.

    Успешное завершение настройки

    Перейдем к настройке web-службы регистрации сертификатов.

    Настройка web-службы регистрации сертификатов

    В окне указать центр сертификации для веб-службы регистрации сертификатов выбираем пункт «Имя ЦС».

    Настройка web-службы регистрации сертификатов

    Тип проверки подлинности – имя пользователя и пароль.

    Тип проверки подлинности

    Учетная запись службы CES – использовать встроенное удостоверение пула приложений.

    Учетная запись службы CES

    В окне выбора сертификата проверки подлинности сервера выберите существующий сертификат, затем нажмите кнопку настроить.

    Выбор сертификата

    Настройка выполнена.

    Настройка выполнена.

    Настройка веб-служб политик регистрации сертификатов

    Выберите тип проверки подлинности – имя и пароль пользователя.

    тип проверки подлинности – имя и пароль пользователя

    Включите режим обновления на останове ключей. Этот режим позволяет автоматически обновлять сертификаты ключей для компьютеров, которые не подключены к внутренней сети.

    Включите режим обновления на останове ключей

    Перезагрузите сервер.

    Настройка службы выполнена

    Установка и настройка удостоверяющего центра

    Запустите консоль управления Microsoft (пуск, выполнить, mmc).

    Консоль mmc

    Далее нажмите файл, а затем добавить или удалить оснастку.

    Добавить или удалить оснастку

    В левой части нужно выбрать пункт «Сертификаты» и нажать кнопку добавить.

    Учетной записи компьютера

    В появившемся окне выбрать пункт учетной записи компьютера.

    В следующем окне ничего не меняем и нажимаем кнопку готово. Оснастка добавлена.

    Оснастка добавлена

    В левой части окна можно увидеть папки, в которых хранятся сертификаты (11 штук). Они сортированы по типам сертификатов. Если нажать на папку «Личное» то можно посмотреть сертификаты в этой папке.

    Перечень сертификатов

    Запросим новый ключ, для этого нужно нажать на сертификате и выбрать меню «все задачи», а затем «запросить сертификат с новым ключом».

    Запрос сертификата с новым ключом

    Появится окно перед началом работы. Жмем далее.

    перед началом работы

    Видим окно запрос сертификатов и нажимаем «заявка».

    Заявка на выпуск сертификата

    Запускается процесс установки сертификата. После успешной установки появиться следующая надпись «Состояние: Успешно».

    Теперь нам нужно связать сертификат с веб-сервером. Для этого нужно запустить диспетчер служб IIS.

    диспетчер служб IIS

    В левой части окна нажать сайты, default web site, изменить привязки.

    изменить привязки

    В появившемся окне нажмите добавить и введите данные как на изображении ниже.

    Настройка веб-интерфейса

    Сохраните изменения и закройте окно.

    Обзор сайта

    Для проверки работоспособности Центра сертификации запустите браузер Internet Explorer и в строке навигации наберите адрес «https://192.168.0.1/certsrv/» (ip-адрес может отличаться от того, который указали вы).

    Web-интерфейс центра сертификации

    Управление шаблонами сертификата

    Шаблоны сертификатов

    Работа с шаблонами сертификата требует установки оснастки «Шаблоны сертификатов». Откроем нашу консоль, которую мы создавали ранее и добавим оснастку «Шаблоны сертификатов».

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

    Откроем шаблоны в главном окне консоли. Создадим новый шаблон.

    Сначала нужно выбрать любой шаблон сертификата и нажать скопировать его.

    Скопировать шаблон

    Настроим шаблон. Выберите совместимость шаблона сертификата.

    Совместимость шаблона сертификата

    Задайте общие свойства шаблона.

    Общие свойства шаблона

    В поле «отображаемое имя» , в строке «имя шаблона» будет тоже самое только без пробелов.

    Параметры достоверности по умолчанию и периода обновления для сертификатов, выдаваемых службами сертификатов Active Directory (AD CS), предназначены удовлетворить большинство требований безопасности. Однако для сертификатов, используемых определенными группами пользователей, может потребоваться указать другие параметры достоверности и обновления, такие как более короткие срок действия или периоды обновления.

    За это два параметра отвечают для поля «период действия» и «период обновления».

    Параметр «опубликовать сертификат в Active Directory» определяет, будут ли сведения о шаблоне сертификата доступными по всему предприятию.

    Параметр «не использовать автоматическую перезаявку, если такой сертификат уже существует в Active Directory». С помощью этого параметра автоматическая подача заявки на сертификат не подаст запрос повторной заявки, если в доменных службах Active Directory (AD DS) существует дубликат сертификата. Это дает возможность обновлять сертификаты, но предотвращает выдачу нескольких дубликатов сертификатов.

    Обработка запроса. Цель имеет 4 возможных параметра:

    1. Вход с подписью и смарт-картой. Разрешает первоначальный вход в систему с помощью смарт-карты и цифровую подпись данных. Нельзя использовать для шифрования данных.
    2. Подпись. Содержит шифровальные ключи только для подписи данных.
    3. Подпись и шифрование. Охватывает все основные применения шифровального ключа сертификата, включая шифрование данных, дешифрование данных, первоначальный вход в систему и цифровую подпись данных.
    4. Шифрование. Содержит шифровальные ключи для шифрования и дешифрования.

    Обработка запроса

    Параметр «включить симметричные алгоритмы, разрешенные субъектом» позволяет администратору выбрать алгоритм стандарта AES для шифрования закрытых ключей, когда они передаются в ЦС для архивации ключа.

    Если установлен этот параметр, клиент будет использовать симметричное шифрование AES-256 (наряду с сертификатом обмена ЦС для асимметричного шифрования), чтобы отправить закрытый ключ в ЦС для архивации.

    Параметр «авторизация дополнительных учетных записей служб для доступа к закрытому ключу» позволяет задать настраиваемый список управления доступом (ACL) к закрытым ключам сертификатов компьютеров на основе любых шаблонов сертификатов компьютера версии 3 за исключением корневого ЦС, подчиненного ЦС и перекрестных шаблонов ЦС.

    Настраиваемый список управления доступом необходим в случае, если учетная запись службы, которой требуется доступ к закрытому ключу, не включена в разрешения по умолчанию.

    Вкладка шифрование. Определяется максимальный размер ключа. Я оставлю его без изменений.

    Вкладка шифрование

    Безопасность можно настроить по вашему усмотрению.

    Вкладка безопасность

    Шаблон сертификата готов.

    Шаблон сертификата

    На этом статья подходит к концу. Мы установили и настроили Active Directory Certificate Services.

    Hello,

    I need import a third party root CA certificate from our partner because we need access applications which are hosted on our partner’s servers with certificates.

    There is a private network link between my company and our partner. We have our own ADCS PKI infrastructure which is integrated with our Windows AD domain — that is our root CA
    has been published to our Windows AD domain.

    I want that our users in the AD domain can access our partner’s applications without certificate security warning.

    I think that our partner’s root CA will be imported into our ADCS PKI infrastructure such that our partner’s root CA will be available on our domain PCs — the root CA should be
    available in either Trusted Root Certification Authorities
    or Third-party Root Certification Authorities
    in the Certificates
    plug-in console.

    I have used the following command to publish our own root CA to our Windows AD domain:

    certutil –f –dspublish “My Company Root Certificate.crt” CA

    But this command add entries to a lot of AD domain containers.

    For the third party root CA, I just want it available on all domain PCs in either
    Trusted Root Certification Authorities
    or Third-party Root Certification Authorities
    in the Certificates
    plug-in console. For example, Thawte Server CA is available in both
    Trusted Root Certification Authorities
    and Third-party Root Certification Authorities
    in the Certificates
    plug-in console.

    How this can be done?

    Thanks in advance.

    SJJ123

    Microsoft Windows 3rd party Component — 0.032% Detection Rate *

    Did you just run into a download or a file on your computer that has been digitally signed by Microsoft Windows 3rd party Component? If so, please read on.

    You will probably notice Microsoft Windows 3rd party Component when running the file. The publisher name is displayed as the «Verified publisher» in the UAC dialog as the screencap shows:

    Screenshot where Microsoft Windows 3rd party Component appears as the verified publisher in the UAC dialog

    You can view additional details from the Microsoft Windows 3rd party Component certificate with the following procedure:

    1. Open up Windows Explorer and locate the Microsoft Windows 3rd party Component file
    2. Right-click on the file and select Properties
    3. Click the Digital Signatures tab
    4. Click the View Certificate button

    Here’s a screenshot of a file that has been digitally signed by Microsoft Windows 3rd party Component:

    Screenshot of the Microsoft Windows 3rd party Component certificate

    As you can see in the screenshot above, Windows reports that «This digital signature is OK». This implies that the file has been published by Microsoft Windows 3rd party Component and that no one has tampered with the file.

    If you click the View Certificate button shown in the screenshot above, you can examine all the details of the certificate, such as when it was issued, who issued the certificate, how long it is valid, and so on. You can also view the address for Microsoft Windows 3rd party Component, such as the street name, city and country.

    Microsoft Windows Third Party Component CA 2012 has issued the Microsoft Windows 3rd party Component certificates. You can also examine the details of the issuer by clicking the View Certificate button shown in the screencap above.

    The following are the Microsoft Windows 3rd party Component files I have gathered, thanks to the FreeFixer users.

    The FreeFixer tool treats files from Microsoft Windows 3rd party Component as safe, which means that the Microsoft Windows 3rd party Component files will appear with a green background and that there’s no removal checkbox for the file. However, as you can see in the scan results below, a few of the anti-virus scanners detects the Microsoft Windows 3rd party Component file(s). I’m pretty sure those detections are false positives and that the files are safe. It’s unlikely that Microsoft Windows 3rd party Component would ship a malware file.

    Detection Ratio File Name
    1/54 FlashUtil_ActiveX.exe
    0/47 FlashUtil_ActiveX.exe
    0/62 winsqlite3.dll
    0/45 FlashUtil_ActiveX.exe
    0/55 FlashUtil_ActiveX.exe
    0/46 FlashUtil_ActiveX.dll
    0/49 FlashUtil_ActiveX.exe
    0/57 FlashPlayerCPLApp.cpl
    0/48 FlashUtil_ActiveX.exe
    0/48 FlashUtil_ActiveX.exe
    0/56 FlashUtil_ActiveX.exe

    Scanner and Detection Names

    Here is the detection names for the Microsoft Windows 3rd party Component files. I have grouped the detection names by each scanner engine. Thanks to VirusTotal for the scan results.

    As mentioned above, I think these detections are incorrect since it is very unlikely that Microsoft Windows 3rd party Component would ship a malware file.

    Scanner Detection Names
    AegisLab AdWare.MSIL.DomaIQ

    * How the Detection Percentage is Calculated

    The detection percentage is based on that I have collected 3092 scan reports for the Microsoft Windows 3rd party Component files. 1 of these scan reports came up with some sort of detection. If you like, you can review the full details of the scan results by examining the files listed above.

    Analysis Details

    The analysis has been done on certificates with the following serial numbers:

    • 3300000013463999b5c7e12baf000000000013
    • 61032f5e000000000006
    • 330000002b1160aea776772bf000000000002b
    • 330000000b8b9486a892605c5700000000000b

    Установка и настройка подчиненного центра сертификации Microsoft CA на MS Windows Server 2012 R2

    При установке подчиненного центра сертификации будет считать, что домен
    уже имеется, DNS-сервер и доменная служба Active Directory установлены.
    Порядок установки будет следующим:

    1. Установить подчиненный Центр сертификации уровня ЦС предприятия (со
      службой сертификации и службой регистрации в центре сертификации через
      Интернет) MS Windows Server 2012 R2, задать имя центра сертификации,
      подразделение, организацию, город и страну для сертификата, отправить
      запрос на сертификат в корневой центр сертификации.
    2. Установить сертификат корневого центра сертификации и актуальный
      список отозванных сертификатов.
    3. Настроить службу на автоматический выпуск сертификатов.
    4. Включить аудит работы службы, сделать настройки безопасности.
    5. Добавить ссылки на точку распространения отозванных сертификатов и
      корневого сертификата центра сертификации, которые будут добавляться в
      каждый выпущенный сертификат.
    6. Выпустить внеочередной список отозванных сертификатов.

    Установка службы сертификации из состава MS Windows

    Установка службы сертификации производится с использованием Мастера в следующей последовательности:

    1. Открыть окно Диспетчер серверов.
    2. В окне выбрать Добавить роли и компоненты.
    3. В окне Мастера добавления ролей и компонентов
      оставить по умолчанию тип установки Установка ролей или компонентов.
    4. В окне Выбор целевого сервера оставить все без изменения.
    5. Далее выбрать роль сервера Службы сертификатов Active Directory. В Появившемся
      окне оставить все по умолчанию и нажать кнопку Добавитькомпоненты.

    6. Поставить флажок Служба регистрации в центре сертификации через Интернет.
    7. Нажмите Далее.
    8. После проверки выбранных параметров установки нажмите Установить.
    9. За процессом установки можно наблюдать в окне Результаты.

    После установки службы сертификации необходимо ее настроить. Для этого
    нажать Настроить службы сертификации Active Directory на конечном сервере.

    В окне учетные данные нажать Далее.

    В окне выбора службы роли для настройки отметить флажками Центр сертификации и
    Служба регистрации в центре сертификации через Интернет. Нажать кнопку Далее.

    Далее следует выбрать ЦС предприятия.

    Затем Подчиненный ЦС.

    При создании нового ключа ЦС выбрать опцию Создать новый закрытый ключ.

    Далее следует выбрать криптопровайдер RSA#Microsoft Software Key Storage Provider и
    установить опцию Разрешить взаимодействие с администратором, если центр сертификации
    обращается к закрытому ключу
    .

    Далее ввести сведения о ЦС. Имя ЦС может быть введено
    как кириллицей, так и латиницей. При этом если имя вводится кириллицей,
    то его длина не должна превышать 50 символов.
    Если Имя вводится латиницей, то его длина не должна превышать 250 символов.
    Имя ЦС по умолчанию состоит из имени сервера и приставки CA.

    Ввести сведения о Вашей организации в поле Суффикс различающегося имени, разделив значения
    запятыми (после запятой пробел не ставить), по следующему примеру:


    OU
    = название отдела


    O
    = название организации


    L
    = город местонахождения


    C
    = RU

    На сообщение о расширенной кодировке имен выбираем Да:

    Сохранить запрос на сертификат в файл:

    По окончанию появится окно с успешной установкой:

    Файл запроса на сертификат будет сохранен в корне диска C:\.

    Установка сертификата корневого центра сертификации и актуального списка отозванных сертификатов

    Вначале следует загрузить веб-сайт корневого центра сертификации.
    Для этого запустить браузер, ввести в строку поиска адрес Вашего корневого центра
    сертификации, например, по имени сервера:
    https://«имя вашего корневого сервера»/certsrv.
    Для изготовления сертификата выберите действие Запрос сертификата:

    Выбрать Расширенный запрос сертификата, затем
    Выдать запрос, используя base-64 шифрованный файл…:

    Открыть файл с запросом на сертификат в Блокноте, выделить все
    содержимое в файле (комбинация клавиш Ctrl+A) и скопировать в буфер
    обмена (комбинация клавиш Ctrl+C):

    Вставить содержимое буфера обмена (комбинация клавиш Ctrl+V) в окно
    выдачи запроса на сертификат на веб-сайте корневого центра сертификации
    и нажмите кнопку Выдать>:

    В результате обработки запроса корневым центром сертификации будет
    выдан сертификат, который нужно сохранить на подчиненном центре
    сертификации, нажав на строку Загрузить сертификат:

    Для запуска подчиненного центра сертификации необходимо встроить
    цепочку доверия
    к корневому центру сертификации, установив корневой
    сертификат и актуальный список отозванных сертификатов. Для загрузки нужно
    перейти на начальную страницу веб-сайта корневого центра сертификации,
    нажав на ссылку Домой в верхнем правом углу сайта:

    Нажать на строку Загрузка сертификата ЦС, цепочки сертификатов или CRL:

    Скачать и сохранить на подчиненном центре сертификации сертификат ЦС и
    актуальный список отозванных сертификатов, нажав по ссылкамЗагрузка сертификата ЦС
    и Загрузка последнего базового CRL:

    Установить корневой сертификат на сервер. Для этого кликнуть правой
    кнопкой мыши на корневой сертификат, в появившемся контекстном меню
    выбрать Установить сертификат. В мастере импорта
    сертификатов выбрать хранилище – Локальный компьютер:


    Выбрать хранилище вручную, установив переключатель на Поместить все сертификаты в следующее хранилище и
    отметить в списке Доверенные корневые центры сертификации/Реестр:

    При установке списка отозванных сертификатов выполнить аналогичные
    действия, при этом в окне Выбор хранилища сертификата
    установить флажок Показать физические хранилища, в
    списке выделить Промежуточные центры сертификации/Локальный компьютер.

    Запустить Центр сертификации Пуск\Приложения\Центр сертификации:

    Подчиненный центр сертификации еще не работает, т.к. сертификат для
    него не установлен. Установка сертификата проводится при первом старте
    службы. Нажать кнопку старта службы:

    На запрос об установке сертификата нажать кнопку Да и
    указать место, куда был сохранен выданный сертификат.

    Если все действия были выполнены правильно, служба центра сертификации успешно запуститься.

    Настройка подчиненного Центра сертификации

    Чтобы просмотреть настройки Центра сертификации, нужно вызвать
    контекстное меню и выбрать Свойства:

    Настроить центр сертификации на выпуск сертификатов в автоматическом
    режиме. Для этого перейти в закладку Модуль политики,
    нажать кнопку Свойства. В открывшемся окне выбрать
    режим Следовать параметрам, установленным в шаблоне….:


    Перейти в закладку Модуль выхода. Нажать кнопку Свойства:

    Установить (если не установлен) флажок Разрешить публикацию сертификатов в файловой системе:

    Перейти в закладку Аудит. Включить протоколирование
    некоторых событий безопасности, например, архивации и восстановления
    базы данных, изменения настроек ЦС и параметров безопасности и т.д.:

    Перейти в закладку Безопасность. Разрешить
    Администратору запрашивать сертификаты. Установить флажок в графе Разрешить
    для строки Запросить сертификаты:

    Перейти в закладку Расширения. Выполнить настройку
    публикации списка отозванных сертификатов. Для этого в меню Выберите расширение
    выбрать Точка распространения списка отзыва (CDP) Удалить
    точки распространения, кроме C:\Windows….. Добавить
    путь, например, https://servername/Public/servername.crl,
    где servername – имя сервера, где будет настроено публичное хранилище:


    Включить настройки Включать в CDP-расширение выданных сертификатов и
    Включать в расширения IDP выданных CRL
    . Перезапустить Центр сертификации:

    В дополнение к CDP, необходимо сконфигурировать дополнение включающее
    информацию о локализации сертификата ЦС AIA. Для этого в поле Выберите
    расширение
    перейти к Authority Information Access (AIA). Удалить доступы к
    сведениям о центрах сертификации, кроме C:\Windows…..
    Добавить путь, например, https://servername/Public/servername.cer, где
    servername – имя сервера, где будет настроено публичное хранилище.
    Включить настройки Включать в AIA- расширение выданных сертификатов.
    Перезапустить Центр сертификации:


    Поскольку значения дополнений CDP и AIA изменены, то для учета изменений
    необходимо выпустить и опубликовать CRL. Для публикации CRL необходимо в
    дереве консоли Центра сертификации нажать правой кнопкой мыши на узел
    Отозванные сертификаты. В появившемся меню выбрать
    Все задачи — Публикация:

    По умолчанию списки отозванных сертификатов размещены в папке

    C:\Windows\System32\Certsrv\CertEnroll

    Яндекс.Метрика

    Search code, repositories, users, issues, pull requests…

    Provide feedback

    Saved searches

    Use saved searches to filter your results more quickly

    Sign up

  • Microsoft windows server 2012 r2 active directory
  • Microsoft windows toolkit for windows 10
  • Microsoft windows server user cal
  • Microsoft windows security spp 8198
  • Microsoft windows resource kit tools