НОУ ИНТУИТ | Лекция | Инфраструктура Открытого Ключа (часть 7)

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

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

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

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

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

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

Например, 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 определяет, следует проверять сертификат на отмену или нет.

Планирование аппаратных требований

Службы сертификатов AD CS в целом нетребовательны к аппаратным ресурсам (на фоне других серверных служб). Основная нагрузка ложится на центральный процессор для выполнения криптографических операций (хэширование, шифрование и подпись). Кроме того, есть определённая нагрузка на диски для работы базы данных сертификатов (AD CS использует JET Database Engine). Это в теории.

На практике аппаратных ресурсов даже бюджетных линеек серверов будет более чем достаточно для функционирования служб сертификатов, поскольку реальные потребности весьма малы на фоне требований ОС к аппаратным ресурсам. В эпоху Windows Server 2003 была написана статья Evaluating CA Capacity, Performance, and Scalability (ссылка на архивную копию, т.к. оригинал удалён с сайта TechNet), освещающую общие моменты, которые нужно учитывать при планировании аппаратных ресурсов.

В 2021 году, Windows PKI Team провела тесты производительности с использованием более современного оборудования (образца 2007 года) под управлением Windows Server 2008. С результатами можно ознакомиться в их блоге: Windows CA Performance Numbers.

Данные в этих статьях, говорят о том, что сервер AD CS на аппаратном сервере выпуска 2007 года позволяет выпускать порядка 150 сертификатов в секунду. Реальная же потребность в скорости выдачи сертификатов на порядки ниже. Поэтому для ЦС общего назначения советую ориентироваться на рекомендуемые аппаратные требования к самой ОС.

Здесь следует отметить, что в конфигурации для корневого ЦС будет отсутствовать (или должен быть отключен) сетевой интерфейс (поскольку он не будет подключен к сети) и присутствовать хотя бы один интерфейс для съёмных носителей.

Планирование имён цс

Имя ЦС – это имя, которое будет отображено в поле

Subject

конкретного ЦС. Не путать с именем хоста, на котором работает служба сертификатов. Полное имя ЦС будет состоять из двух компонентов, самого имени (атрибут CN или Common Name) и опционального суффикса в формате X.500. По умолчанию ADCS назначает имя в следующем формате:

Для Standalone CA: <ComputerName>-CA

Для Enterprise CA: <DomainShortName>-<ComputerName>-CA, <X500DomainSuffix>

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

Предположим, что вы подбираете имя для корневого ЦС компании Contoso Pharmaceuticals Ltd., которая находите в городе Рига, Латвия и управление обеспечивается отделом информационных технологий. В этом случае имя ЦС может иметь следующий вид:

CN=Contoso Pharm Root Certification Authority, OU=Division Of IT (DoIT), O=Contoso Pharmaceuticals Ltd., L=Riga, C=LV

Следует помнить, что атрибут Country поддерживает только двухбуквенный индекс страны. Например, LV, GB, RU, US и т.д. В качестве дополнительных примеров, можете обратиться к сертификатам ЦС коммерческих провайдеров, как VeriSign/Symantec, DigiCert и т.д.

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

• Чрезмерно длинных имён в атрибуте CN (не более 50 символов). При длине атрибута CN свыше 51 символа, оно будет укорочено с пристыковкой хэша отброшенного фрагмента имени в конец имени. Это называется процессом «санитизации» имени, который описан в §3.1.1.4.1.1 протокола [MS-WCCE]. Т.е. может случиться так, что при слишком длинном имени слово оборвётся на середине и будет иметь неприглядный вид.
• Использовать буквы, которые не входят в состав латинского алфавита, т.е. никакой криллицы или диактрических букв (например, ā, ž, Ü, ẞ). ADCS поддерживает только однобайтовые кодировки для атрибута CN и для ограниченного набора символов. Неподдерживаемые символы будут преобразованы в другую кодировку и станут нечитаемыми. Полный список запрещённых символов представлен в §3.1.1.4.1.1.2 протокола [MS-WCCE]. Здесь работает принцип «лучшее – враг хорошему», поэтому имена должны быть достаточно лаконичными и информативными.

Планирование сроков действия crl

Это всё было о составе списков отзыва для каждого ЦС. Теперь следует определить сроки:

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

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

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

Microsoft CA по умолчанию уже закладывает некоторый резерв по времени на непредвиденные случаи и когда распространение списков отзыва по всем точкам публикации занимает некоторое время (например, вызваны латентностью репликации). Этот резерв в английской терминологии называется CRL overlap.

Это достигается использованием двух полей в списке отзыва: Next CRL Publish и Next Update. Поле Next CRL Publish указывает на время, когда ЦС опубликует обновлённый список отзыва (автоматически). Next Update указывает на время, когда срок действия текущего списка истечёт.

Поле Next Update будет всегда выставлен на несколько позднее время, чем Next CRL Publish. Другими словами, ЦС опубликует обновлённый список отзыва до истечения срока предыдущего. Алгоритм вычисления автоматических значений для этих полей нетривиален и описан в следующей статье:

How ThisUpdate, NextUpdate and NextCRLPublish are calculated (v2). Если значения по умолчанию вас не устраивают по тем или иным причинам, их можно отредактировать. Необходимо учитывать, что запас по времени имеет нижние и верхние границы.

Например, верхняя граница не может превышать срока действия самого CRL. Так, если срок действия CRL составляет 1 день, то запас может составлять максимум 1 день, и тогда ЦС будет публиковать списки отзыва ежедневно, но срок действия будет составлять 2 дня. Тем самым достигается запас времени на восстановление ЦС в случае непредвиденных обстоятельств.

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

При планировании сроков действия CRL и периодичности следует руководствоваться следующими рекомендациями:

Расширение certificatepolicies

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

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

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

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

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

Расширение policyconstraints

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

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

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

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

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

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

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 является последовательным номером сертификата, для которого запрашивается статус.

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

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

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

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

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

Установка сертификата при помощи групповых политик.

gpupdate

Состав списков отзыва

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

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

базовый (Base CRL) и дифференциальные (Delta CRL). Базовый список включает полный список отзыва. Дифференциальный список включает в себя только список отозванных сертификатов, которые были отозваны с момента последней публикации базового CRL. Это позволяет вам публиковать базовый список реже и на более длительный срок, а для ускорения времени реакции клиентов на отозванные сертификаты в промежутке выпускать несколько короткоживущих дифференциальных CRL.

Подбор параметров зависит от несколько факторов. Например, планируемый объём издаваемых сертификатов и планируемый объём отзыва. Рассмотрим типовые сценарии.

Корневой ЦС

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

Справка: как посчитать планируемый размер файла CRL исходя из объёмов отзыва? Типичный пустой CRL занимает примерно 600-800 байт. Каждая запись об отозванном сертификате занимает 88 байт. Исходя из этих значений можно высчитать размер CRL в зависимости от количества отозванных сертификатов.

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

Издающий ЦС

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

Как следствие, список отзыва может достигать серьёзных размеров. Например, если заложить 10% риск отзыва, то на миллион изданных сертификатов приходится порядка 100к отозванных. 100к записей по 88 байт будет составлять немногим меньше 10мб. Очень часто обновлять файл на 10мб не очень практично, целесообразней его публиковать реже, а в интервале между публикациями основного CRL распространять несколько облегчённых дифференциальных Delta CRL. Т.е. если для корневого ЦС достаточно только базового списка отзыва, то для ЦС, выпускающих сертификаты конечным потребителям, следует применять и дельты.