Установка центра сертификации на предприятии. Часть 3 / Хабр

Описание политик

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

Первый заключается в том, что ряд ИТ-процессов невозможно отследить на программном уровне. Они проверяются на соответствие принятым правилам аудитом, который проводится людьми. Чаще всего в качестве аудиторов выступают сторонние организации, имеющие компетенцию в рассматриваемых вопросах.

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

Второй ответ вытекает из первого: описание политик выдачи сертификатов в конечном итоге станет документацией на всю PKI и будет иметь своё фирменное название – Certificate Practice Statement или CPS (к сожалению, не нашёл подходящего термина на русском языке, поэтому буду использовать англоязычную аббревиатуру).

Для унификации описания политик выдачи существует рекомендованный (но не обязательный) шаблон, описанный в RFC 3647. По сути, этот документ является фреймворком по написанию политик и освещает всевозможные аспекты работы PKI. Совершенно не обязательно описывать все имеющиеся разделы в документе. Можно документировать только то, что применимо к вашей ситуации, или добавлять что-то своё.

В общем случае CPS будет состоять из двух частей:

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

Издающий цс

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

Корневой цс

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

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

Об авторе

Вадим Поданс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Службы сертификатов 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]. Здесь работает принцип «лучшее – враг хорошему», поэтому имена должны быть достаточно лаконичными и информативными.

Планирование политик выдачи сертификатов

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

Планирование сроков действия 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 и периодичности следует руководствоваться следующими рекомендациями:

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

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

Построение диаграммы pki

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

На диаграмме представлены следующие компоненты и их логические связи:

Физическая топология будет несколько отличаться и иметь следующий вид:

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

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

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

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

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

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

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

Идентификаторы политик должны быть представлены в формате ITU-T и ISO. В своё время я написал небольшую вводную статью про объектные идентификаторы: Что в OID’е тебе моём? В ней есть информация о том, как получить в IANA (Internet Assigned Numbers Authority) свою ветку идентификаторов.

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

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

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

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

Enterprise PKI Health

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

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

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

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

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

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

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

HKLMSystemCurrentControlSetServicesCertSvc

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Установка корневого цс

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

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

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

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

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

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

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

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

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

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

Планирование списков отзыва (crl)

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

1. Точки публикации и распространения списков отзыва;
2. Состав и срок действия списков отзыва.

Точки публикации и распространения списков отзыва

Для публикации списков отзыва используются два типа точек распространения CRL: точка публикации (куда физический файл будет записываться) и точка распространения (получения) файла.

Итоговая конфигурация

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

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

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

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

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

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

Корневой ЦС

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

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

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

Издающий ЦС

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

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