Массовое добавление сертификатов в групповые политики Active Direcory / Хабр

Введение

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

Сертификат открытого ключа связывает значение открытого ключа с информацией, которая идентифицирует участника (такого как персона, организация, account или сайт), использующего соответствующий закрытый ключ (данный участник считается “субъектом” сертификата).

Сертификат применяется “пользователем сертификата” или “доверяющей группой”, которой необходимо задействовать открытый ключ из сертификата. Степень доверия пользователя сертификата осуществленному в сертификате связыванию зависит от нескольких факторов.

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

Сертификат Х.509 v3 может содержать поля, декларирующие, что для данного сертификата применялись одна или более политик сертификата. Соответственно, политика сертификата есть “поименованное множество правил, которые определяют применимость сертификата для конкретного сообщества и/или класса приложений с общими требованиями безопасности”. Политика сертификата может применяться пользователем сертификата при решении вопроса о том, может ли доверять сертификату и содержащейся в нем информации для конкретного приложения.

Детальное описание регламента, которому следует СА при выпуске и управлении сертификатами, содержится в регламенте сертификационной практики ( Certification Practice Statement – CPS ), публикуемом СА.

Рассмотрим взаимосвязь между политиками сертификата и CPS.

Определим элементы, которые могут потребоваться при создании политики сертификата или CPS.

Мы ограничимся обсуждением понятий политики сертификата (как определено в Х.509) и CPS. В частности, опишем типы информации, которые могут быть включены в определение политики сертификата или CPSs.

Asn.1 спецификация для ocsp ответа

OCSP -ответ состоит, как минимум, из поля responseStatus, указывающего полученный статус запроса. Если значение responseStatus является одним из кодов ошибки, responseBytes не установлены.

Значение responseBytes состоит из OBJECT IDENTIFIER и синтаксиса ответа, определяющего, что OID представляется как OCTET STRING.

Для основного OCSP отвечающего responceType будет id-pkix-ocsp-basic.

OCSP отвечающие должны иметь возможность создавать ответы с типом id-pkix-ocsp-basic. Соответственно OCSP клиенты должны иметь возможность получать и обрабатывать ответы с типом id-pkix-ocsp-basic.

Значение ответа должно иметь DER-представление BasicOCSPResponse.

Значение подписи должно вычисляться для хэша DER-представления ResponseData.

ResponseData ::= SEQUENCE {
  version [0] EXPLICIT Version DEFAULT v1,
  responderID ResponderID,
  producedAt  GeneralizedTime,
  responses   SEQUENCE OF SingleResponse,
  responseExtensions [1] EXPLICIT Extensions
      OPTIONAL 
}
ResponderID ::= CHOICE {
  byName [1] Name,
  byKey  [2] KeyHash 
}
KeyHash ::= OCTET STRING 
  -- SHA-1 хэш открытого ключа Responder'а 
  -- (включая поля тега и длины)
SingleResponse ::= SEQUENCE {
  certID     CertID,
  certStatus CertStatus,
  thisUpdate GeneralizedTime,
  nextUpdate [0]  EXPLICIT GeneralizedTime
      OPTIONAL,
  singleExtensions [1] EXPLICIT Extensions
      OPTIONAL 
}
CertStatus ::= CHOICE {
  good    [0]IMPLICIT NULL,
  revoked [1]IMPLICIT RevokedInfo,
  unknown [2]IMPLICIT UnknownInfo 
}
RevokedInfo ::= SEQUENCE {
  revocationTime GeneralizedTime,
  revocationReason [0] EXPLICIT CRLReason
      OPTIONAL 
}
UnknownInfo ::= NULL 
-- данное поле может быть изменено

Архивное хранение

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

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

OCSP -серверы, которые предоставляют поддержку таких исторических ссылок, должны включать в ответы расширение данных archive cutoff. Если оно включено, то данное значение должно быть предоставлено как OCSPsingleExtensions расширение, идентифицируемое id-pkix-ocsp-archive-cutoff и имеющее синтаксис GeneralizedTime.

В качестве иллюстрации можно привести такой пример: для сервера, функционирующего с семилетним сохранением внутренней политики, если статус некоторого сертификата был создан в момент времени t1, значение для ArchiveCutoff в ответе будет ( t1 – 7 лет).

Взаимосвязь между политикой сертификата и регламентом сертификационной практики

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

CPS является детальным описанием СА своей практики, которое должно быть принято во внимание подписчиками и пользователями сертификата. Хотя уровень детализации для разных CPSs может быть различным, обычно они бывают более развернутыми, чем определения политики сертификата.

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

Хотя такая детализация может быть необходима и делает регламент заслуживающим доверия при отсутствии аккредитации или каких-то других метрик качества, детальный CPS не может служить подходящим базисом для интероперабельности САs, функционирующих в различных организациях. Политики сертификата скорее являются средством выражения общей основы интероперабельности.

СА с единственным CPS могут поддерживать несколько политик сертификата (используемых для различных прикладных целей и/или в различных пользовательских сообществах). Также несколько различных САs с неидентичными CPSs могут поддерживать одну и ту же политику сертификата.

Определение политики сертификата описывает общие характеристики данной политики сертификата и указывает типы приложений, в которых она может использоваться. Различные департаменты или агентства, которые функционируют в качестве САs с разными CPSs, могут поддерживать данную политику сертификата. В то же время такие САs могут поддерживать и другие политики сертификата.

Основное различие между политикой сертификата и CPS заключается в следующем:

1. Большинство организаций, которые выполняют роль публичных или межорганизационных САs, документируют свои регламенты. CPS является одним из организационных способов защиты себя и своей позиции при деловых отношениях с подписчиками и другими участниками.
2. С другой стороны, не существует особых причин, чтобы политика сертификата применялась только в одной организации. Если конкретная политика сертификата широко распространена, имеются основания для автоматического принятия сертификата во многих системах, включая системы, не требующие участия человека, и системы, которые управляются людьми, но независимо решают вопрос действительности представленных сертификатов.

Добавление сертификата средствами gpo на windows server 2008r2 в active directory. | реальные заметки ubuntu & mikrotik

Замечания о синтаксисе запроса

Первая причина использования хэша открытого ключа СА в дополнение к хэшу имени СА, идентифицирующему выпускающего, состоит в том, что, возможно, два САs используют одно и то же имя ( Name ) (отсутствие уникальности имени рекомендуется, но не гарантируется).

Поддержка любого указанного здесь расширения не является обязательной. Флаг критичности не должен быть установлен ни для кого из них. Далее мы рассмотрим несколько полезных расширений. Могут быть также определены дополнительные расширения. Нераспознанные расширения должны игнорироваться (если только они не критичны).

Запрашивающий может подписать OCSP -запрос. В этом случае подпись вычисляется поверх tbsRequest -структуры. Если запрос подписан, то запрашивающий должен указать свое имя в поле requestorName.

Запрос

НТТР, лежащий в основе OCSP -запросов, может использовать либо GET, либо POST метод для submit-запросов. Для возможности НТТР-кэширования небольшие запросы (меньше 255 байтов) могут пересылаться с использованием GET.

Если НТТР-кэширование не требуется или размер запроса превышает 255 байтов, запрос должен пересылаться с использованием POST. Если требуется защита, то OCSP -транзакции, применяющие НТТР, могут быть защищены с помощью TLS/SSL или другого протокола более низкого уровня.

OCSP -запрос, использующий метод GET, конструируется следующим образом:

где {url} может быть получено из значения AuthorityInfoAccess или локальной конфигурации OCSP -клиента.

OCSP -запрос, использующий метод POST, конструируется следующим образом: заголовок Content-Type имеет значение application/ocsp-request, а тело сообщения является бинарным значением DER-представления OCSPRequest.

Защита закрытого ключа

Необходимо рассмотреть требования для защиты закрытого ключа для выпускающего СА, репозиториев, субъектов САs, RAs и субъектов конечных участников. Для каждого из этих типов участников нужно ответить на следующие вопросы:

1. Какие стандарты, если они есть, требуются для модулей, используемых для создания ключей? Если так, то каким должен быть уровень модуля?
2. Находятся ли закрытые ключи под управлением нескольких человек?
3. Является ли закрытый ключ распределенным? Если да, то кто является распределенными агентами, которые формируют распределенные ключи, и каково безопасное управление распределенных систем?
4. Выполняется ли back up для закрытого ключа. Если да, то кто является back up агентом, который формирует back up ключ, и каково безопасное управление back up систем?
5. Выполняется ли архивация закрытого ключа? Если да, то кто является агентом архивации, какая форма архивации ключа выполняется и каково безопасное управление системой архивации?
6. Кто вводит закрытый ключ в криптографический модуль? В какой форме? Как закрытый ключ хранится в модуле?
7. Кто может активизировать (использовать) закрытый ключ? Какие действия должны быть выполнены для активации закрытого ключа? После того как ключ активирован, он активирован на неопределенный срок, активирован для одного раза или активирован на определенный период времени?
8. Кто может деактивировать закрытый ключ и как, автоматически или по истечении времени?
9. Кто может уничтожить закрытый ключ?

Идентификация и аутентификация

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

Данный компонент имеет следующие подкомпоненты:

1. Начальная регистрация.
2. Процедура создания нового ключа – описывает процедуры идентификации и аутентификации для процедуры создания нового ключа для каждого типа субъекта (СА, RA и конечного участника).
3. Создание нового ключа после отмены – описывает процедуры идентификации и аутентификации при создании нового ключа для каждого типа субъекта (СА, RA и конечного участника) после того, как сертификат субъекта был отменен.
4. Запрос отмены – описывает процедуры идентификации и аутентификации для запроса отмены для каждого типа субъекта (СА, RA и конечного пользователя).

Массовое добавление сертификатов в групповые политики active direcory

path = "Root"
Set WshShell = WScript.CreateObject( "WScript.Shell" ) 
Set objNetwork = CreateObject( "WScript.Network" )
set fso = CreateObject( "Scripting.FileSystemObject" )
Set fLog = fso.OpenTextFile( "!log_root_certs.txt", 8, True )
fLog.write vbCrLf & "=Начало=" & Now( ) & vbCrLf
fLog.write "Имя компа: " & objNetwork.ComputerName & vbCrLf
fLog.write "Имя пользователя: " & objNetwork.UserName & vbCrLf
fLog.write "Были установлены следующие сертификаты:" & vbCrLf  & vbCrLf
i = 0

for each f in FSO.GetFolder( WshShell.CurrentDirectory & path ).Files 'тут указано имя папки, в которой ищем.
 if right(f.name, 4) = ".cer" then 
   WshShell.Run "certmgr -add -c " & chr(34) & f & chr(34) & " -s -r localMachine root", 7, true
   fLog.write f.name & vbCrLf 
   i = i   1
 end if
next 

fLog.write vbCrLf  & "Установлено сертификатов: " & i & vbCrLf  & vbCrLf 
fLog.close

path = "Root"
Set WshShell = WScript.CreateObject( "WScript.Shell" ) 
Set objNetwork = CreateObject( "WScript.Network" )
set fso = CreateObject( "Scripting.FileSystemObject" )
Set fLog = fso.OpenTextFile( "!log_root_certs.txt", 8, True )
fLog.write vbCrLf & "=Начало=" & Now( ) & vbCrLf
fLog.write "Имя компа: " & objNetwork.ComputerName & vbCrLf
fLog.write "Имя пользователя: " & objNetwork.UserName & vbCrLf
fLog.write "Были установлены следующие сертификаты:" & vbCrLf  & vbCrLf
i = 0

for each f in FSO.GetFolder( WshShell.CurrentDirectory & path ).Files 'тут указано имя папки, в которой ищем.
 if right(f.name, 4) = ".cer" then 
   WshShell.Run "certmgr -add -c " & chr(34) & f & chr(34) & " certs.sst", 7, true
   fLog.write f.name & vbCrLf 
   i = i   1
 end if
next 

fLog.write vbCrLf  & "Установлено сертификатов: " & i & vbCrLf  & vbCrLf 
fLog.close

Множество постановлений

Множество постановлений определяет регламент практики сертификации.

Например, CPS может выражаться в виде сочетания следующих элементов:

1. Список политик сертификата, поддерживаемых CPS.
2. Каждой политики сертификата в (1) существует набор постановлений, которые уточняют политику сертификата деталями, обусловленными данной политикой ; такие постановления предназначены для установления того, как конкретный CPS реализует требования конкретной политики сертификата.
3. Множество постановлений, которые содержат утверждения, относящиеся к регламенту сертификации СА независимо от политики сертификата.

Утверждения, приведенные в (2) и (3), могут уточнить условия применяемости определения политики сертификата, но не должны конфликтовать с другими условиями определения политики сертификата.

Регламент сертификационной практики должен состоять примерно из следующих компонентов:

Далее компоненты могут быть поделены на подкомпоненты.

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

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

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

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

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

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

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

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

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

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

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

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

Обсуждение проблем безопасности

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

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

Использование заранее вычисленных ответов допускает replay-атаки, в которых старый (хороший) ответ повторяется до даты своего истечения, но после того, как сертификат был отменен. Развертывание OCSP должно быть тщательно просчитано для получения преимуществ от заранее вычисленных ответов, чтобы не допустить вероятность replay-атак в противовес большой цене, связанной с вычислениями.

Запросы не содержат Responder, к которому они обращаются. Это позволяет атакующему повторить запрос к любому количеству OCSP Responder.

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

Отвечающие уполномоченные органы

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

Делегирование подписывания OCSP должно быть выполнено путем включения id-kp-OCSPSigning в расширение extendedKeyUsage сертификата, подписывающего OCSP -ответ. Данный сертификат должен быть выпущен непосредственно СА.

Проверка отмены сертификата Responder

Так как Responder предоставляет информацию о статусе для одного или более САs, клиенты OCSP должны знать, как проверить, не отменен ли сертификат отвечающего уполномоченного органа. САs могут выбрать один из трех способов решения проблемы:

• СА может определить, что клиент OCSP может доверять отвечающему в течение времени жизни сертификата отвечающего. СА делает это посредством включения расширения id-pkix-ocsp-nocheck. Это должно быть некритичное расширение. САs, выпускающие такие сертификаты, должны осознавать, что компрометация ключа Responder’а так же опасна, как и компрометация ключа СА, используемого для подписывания CRLs. СА могут выпускать данный тип сертификата с очень коротким сроком действия и часто обновлять его.
• СА может указать, как проверять отмену сертификата Responder. Это можно сделать с помощью точек распределения CRL, если проверка должна быть выполнена с использованием CRL.
• СА может не указывать какой-либо метод проверки отмены для сертификата Responder’а, в этом случае локальная политика безопасности клиента OCSP определяет, следует проверять сертификат на отмену или нет.

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

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

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

Install-WindowsFeature -Name Web-Server, Web-WebServer -IncludeManagementTools

Согласно нашей конфигурационной таблице (см. часть 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.

Политика сертификата

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

Стандарт Х.509 определяет политику сертификата как “именованное множество правил, которые определяют применимость сертификата для конкретного сообщества и/или класса приложений с общими требованиями безопасности”. Сертификат Х.

509 v3 может содержать индикацию политики сертификата, которая может применяться пользователем сертификата при принятии решения о том, можно ли задействовать сертификат для той или иной цели.

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

Процесс регистрации должен следовать стандартам ISO/IEC и ITU. Участник, который регистрирует Object Identifier, также публикует текстовую спецификацию политики сертификата.

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

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

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

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

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

Примеры политики сертификата

В качестве примера предположим, что некая организация определила две политики сертификата – одну для использования в общих целях ( General-Purpose ), другую для проведения финансовых транзакций ( Commercial-Grade ).

Будем считать, что политикаGeneral-Purpose предназначена для защиты передаваемой информации (например, e-mail) или для аутентифицированных соединений от браузеров к серверам.

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

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

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

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

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

Enterprise PKI Health

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

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

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

Расширение certificatepolicies

Расширение CertificatePolicies имеет два варианта – один с полем, помеченным как некритичное, другой с полем, помеченным как критичное. Назначение поля в этих двух случаях различается.

Некритичное поле CertificatePolicies перечисляет политики сертификата, которые СА объявляет применимыми. Однако использование сертификата не ограничивается целями, указанными в применимых политиках.

Некритичное поле CertificatePolicies предназначено для использования приложениями следующим образом. Каждое приложение заранее сконфигурировано так, что оно “знает”, какая политика ему требуется.

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

Если поле CertificatePolicies помечено как критичное, оно предназначено для той же цели, которая описана выше, но также имеет дополнительную роль. Она указывает, что использование сертификата ограничено одной из указанных политик, например СА декларирует, что сертификат может применяться только в соответствии с положениями одной из перечисленных политик сертификата. Это поле предназначено для защиты СА от ущерба при несоответствующем использовании сертификата.

Расширение policyconstraints

Расширение PolicyConstraints поддерживает две дополнительные функции. Первая состоит в возможности для СА требовать, чтобы явные индикации политики сертификата были представлены во всех следующих сертификатах в сертификационном пути.

Сертификаты в начале сертификационного пути могут рассматриваться пользователем сертификата как часть доверенного домена, например, САs являются доверенным для всех целей, следовательно, нет необходимости указывать конкретную политику сертификата в расширении CertificatePolicies.

Такие сертификаты не содержат явного указания политики сертификата. Однако если СА в доверенном домене сертифицирует внешний домен, он может указать требование явной политики сертификата
в следующих сертификатах в сертификационном пути.

Другая дополнительная функция поля PolicyConstraints для СА состоит в возможности запретить отображение политик для следующих САs в сертификационном пути.

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

Расширение policymappings

Расширение PolicyMapping может использоваться только в сертификатах СА. Данное поле позволяет СА указать, что некоторые политики в его собственном домене могут считаться эквивалентными некоторым другим политикам в домене субъекта СА.

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

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

Регламент практики сертификации

Термин регламент практики сертификации ( CPS ) может быть определен следующим образом: детальное описание практики, при которой СА выпускает сертификаты. Данное определение можно дополнить следующими комментариями.

Регламент практик сертификации может быть оформлен как декларация СА о деталях системы и регламентах функционирования и поддержки выпуска сертификатов. Это также может быть часть контракта между СА и его подписчиками. CPS включает несколько документов, содержащих законы, частные контракты и/или декларации.

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

Регламент сертификационной практики должен указывать на стандарты, в соответствии с которыми СА осуществляет свою деятельность, а также на потенциальную технологическую совместимость сертификатов, выпущенных СА.

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

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

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

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

HKLMSystemCurrentControlSetServicesCertSvc

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

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

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

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

OCSPRequest ::= SEQUENCE {
  tbsRequest   TBSRequest,
  optionalSignature [0] EXPLICIT Signature 
      OPTIONAL 
}
TBSRequest ::= SEQUENCE {
  version [0] EXPLICIT Version DEFAULT v1,
  requestorName [1] EXPLICIT GeneralName 
      OPTIONAL,
  requestList SEQUENCE OF Request,
  requestExtensions [2] EXPLICIT Extensions
      OPTIONAL 
}
Signature ::= SEQUENCE {
  signatureAlgorithm AlgorithmIdentifier,
  signature BIT STRING,
  certs [0] EXPLICIT SEQUENCE OF Certificate
      OPTIONAL
}
Version ::= INTEGER  {  v1(0) }
Request ::= SEQUENCE {
  reqCert   CertID,
  singleRequestExtensions [0] EXPLICIT
      Extensions OPTIONAL 
}
CertID ::= SEQUENCE {
  hashAlgorithm   AlgorithmIdentifier,
  issuerNameHash   OCTET STRING, 
  -- хэш DN выпускающего
  issuerKeyHash   OCTET STRING, 
  -- хэш открытого ключа 
  -- выпускающего
  serialNumber   CertificateSerialNumber
}

IssuerNameHash является хэшем уникального имени выпускающего. Хэш должен вычисляться поверх DER-представления поля имени выпускающего в проверяемом сертификате. IssuerKeyHash является хэшем открытого ключа выпускающего.

Хэш должен быть вычислен поверх значения (включая тег и длину) поля открытого ключа субъекта в сертификате выпускающего. Хэш-алгоритм, используемый для вычисления обоих хэшей, указывается в hashAlgorithm. SerialNumber является последовательным номером сертификата, для которого запрашивается статус.

Содержимое сертификата

Для того чтобы передавать клиентам OCSP точку доступа к информации, САs должны включать расширение AuthorityInfoAccess в сертификаты, которые могут быть проверены с использованием OCSP.

САs, которые поддерживают OCSP -сервис, либо размещающие его локально, либо предоставляющие его внешним клиентам с помощью Responder, должны обеспечивать включение значения URI accessLocation и значения OID id-ad-ocsp для accessMethod в последовательность AccessDescription выпускаемых сертификатов.

Значение поля accessLocation в сертификате субъекта определяет транспорт (например, НТТР), используемый для доступа к OCSP Responder, и может содержать другую относящуюся к транспорту информацию (например, URI).

Создание и инсталляция пары ключей

Создание и инсталляция пары ключей должна рассматриваться для САs, RAs и конечных участников. Для каждого из этих типов участников необходимо получить ответы на следующие вопросы:

1. Кто создает пару открытый-закрытый ключи участника?
2. Каким образом закрытый ключ безопасно доставляется участнику?
3. Как открытый ключ участника безопасно доставляется выпускающему сертификат?
4. Если участник является СА (выпускающий или субъект), то как открытый ключ участника безопасно доставляется пользователям?
5. Каковы размеры ключей?
6. Кто создает параметры открытого ключа?
7. Качество параметров проверяется при создании ключа?
8. Создание ключа выполняется аппаратно или программно?
9. Для каких целей может использоваться ключ или для каких целей должно быть ограничено применение ключа?

Ссылки на crl

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

CRL может указываться с помощью URL (по которому CRL доступен), номера (номер CRL) или времени (время, когда соответствующий CRL был создан). Эти расширения специфицируются как singleExtensions. Идентификатор для данного расширения есть id-pkix-ocsp-crl, значением должно быть CrlID.

Для crlUrl IA5String указывает URL, по которому доступен CRL. Для crlNum INTEGER определяет значение расширения номера CRL соответствующего CRL. Для crlTime GeneralizedTime определяет время, когда был выпущен соответствующий CRL.

Типы принимаемых ответов

Клиент OCSP может захотеть указать типы ответов, которые он распознает. Для того чтобы сделать это, он должен использовать расширение с OID id-pkix-ocsp-response и значением AccepttableResponses.

Данное расширение включается в одно из requestExtensions в ответах. OIDs, включенные в AccepttableResponses, являются OIDs различных типов ответов, которые данный клиент может принимать (например, id-pkix-ocsp-basic ).

Как отмечалось выше, OCSP отвечающий должен уметь создавать ответы типа id-pkix-ocsp-basic. Соответственно, OCSP клиенты должны уметь получать и обрабатывать ответы типа id-pkix-ocsp-basic.

Требования выполнения

Данный компонент используется для спецификации требований, накладываемых на действия СА, субъектов САs, RАs или конечных участников в зависимости от различных выполняемых действий.

Данный компонент состоит из следующих подкомпонентов:

1. Применение сертификата – используется для установления требований, относящихся к регистрации субъекта и запроса на выпуск сертификата.
2. Выпуск сертификата – используется для установления требований, относящихся к выпуску сертификата, и уведомления претендента об этом выпуске.
3. Получение сертификата – используется для установления требований, относящихся к получению сертификата и к последующей его публикации.
4. Приостановка и отмена сертификата.
5. Процедуры аудита безопасности.
6. Архивация записей.
7. Изменение ключа.
8. Компрометация и восстановление.
   • Используемые процедуры восстановления, если вычислительные ресурсы, ПО или данные испорчены наверняка или предположительно. Эти процедуры описывают, как переустановить безопасное окружение, в котором отменены сертификаты или ключ участника, как предоставить новый открытый ключ участника пользователям и как субъекты сертифицируются повторно.
   • Процедуры восстановления, которые используются, если открытый ключ участника отменен. Эти процедуры описывают, как переустановить безопасное окружение, как предоставить новый открытый ключ участника пользователям и как субъекты сертифицируются повторно.
   • Процедуры восстановления, использующиеся в том случае, если открытый ключ скомпрометирован. Эти процедуры описывают, как переустановить безопасное окружение, как предоставить новый открытый ключ участника пользователям и как субъекты сертифицируются повторно.
   • Процедуры, СА, используемые для обеспечения безопасности при восстановлении безопасного окружения либо на исходном сайте, либо на удаленном сайте. Например, процедуры защиты от кражи секретных материалов.
9. Завершение функционирования СА.

В каждом подкомпоненте может потребоваться отдельное рассмотрение для выпускающего СА, репозитория, субъекта САs, RAs и конечных участников.

Требования принятия подписанного ответа

Для того чтобы считать подписанный ответ действительным, клиенты OCSP должны убедиться, что:

1. Сертификат, указанный в полученном ответе, соответствует тому, который был определен в запросе.
2. Подпись в ответе действительна.
3. Идентификация подписавшего соответствует ожидаемому получателю запроса.
4. Подписавший в настоящий момент авторизован подписывать ответы.
5. Время, когда статус был указан как корректный ( thisUpdate ), считается неустаревшим.
6. Время, когда или до которого доступна более новая информация о статусе сертификата ( nextUpdate ), при этом оно должно быть больше текущего времени. Данная информация не является обязательной.

Управление безопасностью жизненного цикла

Данный подкомпонент адресован контролю за разработкой системы и контролю управления безопасностью.

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

Контроль управления безопасностью включает выполнение средств и процедур, гарантирующих, что функциональные системы и сети остаются безопасно сконфигурированными. Эти средства и процедуры включают проверку целостности ПО и аппаратуры для гарантии их безопасного функционирования.

Данный компонент также может быть адресован оценке безопасности жизненного цикла, основанного на методологии разработки доверенного ПО (TSDM) уровня IV и V и независимого аудита безопасности жизненного цикла.

Управление безопасностью компьютера

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

Для компьютерных систем может потребоваться оценка безопасности компьютера. Оценка может быть основана, например, на различных используемых критериях (Common Criteria – СС). Данный подкомпонент может быть также адресован требованиям для анализа оценки продукта, тестирования, профилирования, сертификации продукта и/или аккредитации продукта в соответствии с выполняемой деятельностью.

Установка компонента цс

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

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

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

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

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» в корне системного диска и копируем его на корневой ЦС и на корневом ЦС выполняем следующие команды:

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

Наряду с установкой издающего ЦС, в Active Directory устанавливается набор уже готовых шаблонов сертификатов. Их можно просмотреть в оснастке

Certificate Templates MMC

(certtmpl.msc). Рекомендации по шаблонам сертификатов:

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

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

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

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

Если у вас используются современные версии ОС (например, 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.

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

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

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

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

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