Microsoft windows third party component ca 2012 - Доктор Windows

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:

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

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

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

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 установлены.
Порядок установки будет следующим:

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

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

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

Открыть окно Диспетчер серверов.
В окне выбрать Добавить роли и компоненты.

В окне Мастера добавления ролей и компонентов
оставить по умолчанию тип установки Установка ролей или компонентов.
В окне Выбор целевого сервера оставить все без изменения.

Далее выбрать роль сервера Службы сертификатов Active Directory. В Появившемся
окне оставить все по умолчанию и нажать кнопку Добавитькомпоненты.

Поставить флажок Служба регистрации в центре сертификации через Интернет.

Нажмите Далее.

После проверки выбранных параметров установки нажмите Установить.

За процессом установки можно наблюдать в окне Результаты.

После установки службы сертификации необходимо ее настроить. Для этого
нажать Настроить службы сертификации 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.

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

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

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

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

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

ОК.

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

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

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

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

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

Закройте редактор групповой политики и в 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, которые будут выполнять следующие функции:

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

Развёртывание 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'

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

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

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

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

Название параметра	Значение параметра
Сервер ЦС
Класс ЦС	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

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

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

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

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

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

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

Поэтому мы сконфигурируем ЦС так, что список шаблонов к выдаче будет пустым. Это возможно сделать только через 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 установлена верно.

Об авторе

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

Источник

Содержание

How to import third-party certification authority (CA) certificates into the Enterprise NTAuth store
More information
Method 1 — Import a certificate by using the PKI Health Tool
Method 2 — Import a certificate by using Certutil.exe
Microsoft recommended driver block rules
Add partner certification authority in Intune using SCEP
Overview
Set up third-party CA integration
Validate third-party certification authority
Authorize communication between CA and Intune
Create an application in Azure Active Directory
Configure and deploy a SCEP certificate profile
Removing certificates
Third-party certification authority partners
Microsoft windows third party component ca 2014
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:

On the Console menu, select Add/Remove Snap-in.
Select the Standalone tab, and then select the Add button.
In the list of snap-ins, select Enterprise PKI.
Select Add, and then select Close.
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:

In Intune, an administrator creates a SCEP certificate profile, and then targets the profile to users or devices.
The device checks in to Intune.
Intune creates a unique SCEP challenge. It also adds additional integrity-check information, such as what the expected subject and SAN should be.
Intune encrypts and signs both the challenge and integrity-check information, and then sends this information to the device with the SCEP request.
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.
The CSR and encrypted/signed challenge are sent to the third-party SCEP server endpoint.
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.
Intune sends back a response to the SCEP server, and states whether the challenge validation is successful or not.
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…

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

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

4 – On the Select destination server box, click Next…

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…

6 – On the Select features box, click Next…

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

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

9 – On the Confirm installation selections box, click Install…

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

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

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

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

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

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

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…

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…

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

19 – On the CA Database box, click Next…

20 – On the Confirmation box, click Configure…

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

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…

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

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…

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…

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

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…

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

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

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

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

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…

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

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

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

36 – Click Yes to restart Certification Authority service…

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

38 – In the Publish CRL box, click OK…

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

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

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

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

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

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

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

46 – Click Finish, and then click OK…

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

48 – and then paste to \dc01c$…

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 создает центр сертификации, предназначенный для выдачи сертификатов пользователям. Служба может быть настроена и работать через веб-интерфейс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обработка запроса. Цель имеет 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 *

Scanner and Detection Names

* How the Detection Percentage is Calculated

Analysis Details

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

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

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

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

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

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

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

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

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

Windows Server 2003

Windows Server 2008 R2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Об авторе

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

More information

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

Method 2 — Import a certificate by using Certutil.exe

Microsoft recommended driver block rules

Add partner certification authority in Intune using SCEP

Overview

Set up third-party CA integration

Validate third-party certification authority

Authorize communication between CA and Intune

Create an application in Azure Active Directory

Configure and deploy a SCEP certificate profile

Removing certificates

Third-party certification authority partners

Microsoft windows third party component ca 2014

About

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

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

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

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