Как перевыпустить корневой сертификат центра сертификации

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

Особенности эксплуатации CA на роутерах Mikrotik: резервное копирование, экспорт и импорт сертификатов

• Автор: Уваров А.С.
• 07.07.2021

Mikrotik предоставляет пользователям достаточно широкие возможности, одна из них — создание на роутере собственного центра сертификации (CA), который позволяет управлять собственной инфраструктурой открытых ключей (PKI). Благодаря этому вы можете выпускать, подписывать и отзывать сертификаты, а также поддерживать доверительные отношения без использования дополнительных технических и программных средств. Это удобно, но эксплуатация CA на базе Mikrotik имеет свои особенности и подводные камни, которые нужно четко представлять и учитывать при выборе такого решения.

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

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

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

При этом любой пользователь или узел, располагающий корневым сертификатом, может в любой момент времени убедиться в подлинности предъявленного ему сертификата другого пользователя или узла, а так как доверие к CA не подвергается сомнению, то автоматически возникают доверительные отношения с предъявителем действующего сертификата. Также корневой сертификат содержит адрес CRL — списка отозванных сертификатов, что позволяет дополнительно убедиться, что предъявленный сертификат не был отозван.

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

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

• А — authority — корневой сертификат при помощи которого мы можем подписывать другие сертификаты
• T — trusted — сертификат с которым установлены доверительные отношения
• L — crl — корневой сертификат содержит адрес списка отозванных сертификатов (CRL)
• I — issued — сертификат, выпущенный центром сертификации расположенном на данном устройстве
• K — private-key — сертификат имеет связанный с ним закрытый ключ
• E — expired — сертификат с истекшим сроком действия
• R — revoked — отозванный сертификат

Таким образом корневой сертификат CA должен иметь флаги KAT или KLAT в зависимости от того, использует ли центр сертификации списки отзыва CRL. Выпущенный данным CA сертификат будет иметь флаг KI, а будучи импортированным на другом узле в присутствии сертификата CA будет иметь флаги KT, а сам корневой сертификат чужого CA — просто T или LT.

Закладка System — Certificates — CRL содержит загруженные списки отзыва для всех сертификатов, имеющих флаг L, кроме корневого сертификата собственного CA. Для работы со списками отзыва следует выполнить некоторые настройки, они расположены в System — Certificates — Settings. Флаг Use CRL включает использование списков отзыва, флаг CRL Download разрешает загрузку списков для сертификатов, содержащих адрес CRL. Если установить первый, но не устанавливать второй, то списки CRL будут работать только для собственного CA.

Еще одна важная опция — место хранения CRL — CRL Store, по умолчанию там стоит вариант хранения в оперативной памяти — ram. Но здесь есть первые подводные камни, объем RAM занимаемый списком рассчитывается по формуле:

Таким образом даже самый небольшой список будет занимать от 4 МБ оперативной памяти, что может быть критично для младших моделей с небольшим объемом оперативной памяти, в этом случае значение CRL Store следует изменить на system.

Следующий важный вопрос: а что будет, если роутер с ролью CA выйдет из строя? В таком случае вы полностью потеряете контроль над своей PKI и вам потребуется создать новый CA и перевыпустить все сертификаты. Избежать этого можно только одним образом — созданием резервной копии устройства в бинарном формате. Для этого перейдите в Files и нажмите кнопку Backup, укажите имя файла и обязательно задайте пароль (в противном случае закрытые ключи выгружены в резервную копию не будут).

Либо выполните в терминале:

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

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

После чего в разделе Files у вас появится файл с указанным именем и расширением .rsc. Но данный файл не содержит ключей и сертификатов и не годится для восстановления CA. Скажем сразу — никаким иным способом, кроме как бинарным бекапом, перенести CA на другой роутер нельзя. Фактически центр сертификации получается в своем роде «одноразовым», его можно перенести только на точно такое же устройство, в случае апгрейда вам придется создать инфраструктуру PKI заново.

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

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

А пока экспортируем нужные нам ключи и сертификаты. Перейдем в System — Certificates, найдем там корневой сертификат CA и щелкнув на него правой кнопкой мыши выберем Export. Формат не имеет принципиального значения, при выборе PEM вы получите два файла — сертификат и закрытый ключ, при выборе PKCS12 — единственный файл .p12.

Обязательно укажите пароль в поле Export Passphrase, в противном случае закрытые ключи выгружены не будут.

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

При переходе на другое устройство вам потребуется загрузить сертификаты и ключевые пары, либо файлы p12 в Files. После чего импортировать их в System — Certificates. Последовательность импорта такова: сначала сертификат, потом закрытый ключ, в случае файла p12 все импортируется за одно действие.

Глядя на статус импортированного корневого сертификата — KLAT — можно подумать, что все хорошо, но увы. Выпущенный этим же CA серверный сертификат импортируется не как KI, а как KT, это означает, что он будет работать, но отозвать мы его никогда не сможем, это же относится и к клиентским сертификатам, почему мы выше и сказали, что экспортировать их бессмысленно.

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

А мы тем временем перейдем к спискам отзыва, так как это самое больное место в этой схеме. При создании корневой ключевой пары CA, в момент подписи запрашивается адрес опубликования CRL — СА CRL Host, именно по этому адресу Mikrotik поднимет веб-сервер и опубликует список отозванных сертификатов.

Здесь снова есть подводные камни. Файл списка CRL при каждом изменении меняет свое название на номер итерации, так при первом создании он будет http://192.168.111.1/crl/1.crl, а после следующего отзыва превратиться в http://192.168.111.1/crl/2.crl. Адрес списка CRL содержится в корневом сертификате CA, поэтому, если вы используете несколько узлов, разрешающих доступ по сертификатам выпущенным Mikrotik, то после каждого отзыва вы должны заново экспортировать корневой сертификат СА и распространить его на все узлы вашей области доверия PKI, как минимум на те, которые принимают сертификаты для аутентификации или авторизации.

При переносе ключевой пары CA на другой хост RouterOS прочитает из корневого сертификата адрес CRL и попытается его скачать. Но так как старый роутер заменен новым, с тем же адресом, скачивать ему будет нечего. К сожалению, Mikrotik не позволяет импортировать файл списка CRL, поэтому даже имея его на руках вы не сможете загрузить его в устройство.

Но ведь мы можем выдавать новые сертификаты и можем их отозвать? Можем. Но новый список CRL при этом не формируется, центр сертификации будет продолжать пытаться загрузить список CRL указанный в корневом сертификате, которого в новом роутере не существует.

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

Фактически старый CA перестал существовать, но мы можем продолжать поддерживать работоспособность текущей инфраструктуры PKI, хотя и с ограничениями, и планомерно планировать переход на сертификаты нового CA. Такой сценарий гораздо предпочтительнее, чем полный отказ инфраструктуры.

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

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

Обновление сертификата на подчиненном центре сертификации

Периодически, по истечении срока действия сертификата дочернего центра сертификации (Subordinate или Issuing CA), необходимо выполнять его обновление на корневом центре сертификации (Root CA). Ниже будет описан общий порядок из нескольких простых шагов, которые требуется выполнить, чтобы продлить сертификат дочернего центра сертификации. Дочерний центр сертификации может быть как просто подчиненным ЦС, так и выдающим. В общем случае, порядок обновления сертификата корпоративного (Enterprise) или изолированного (Standalone) совпадает, отличия только в способе передачи файла запроса. В одном случае он может проходить автоматичсеки, в другом — необходимо его передавать вручную.

Обновление сертификата, на Enterprise Root CA

1 Выполнить вход на выдающий Центр сертификации и открыть MMC оснастку Certificate Authority
2 Нажать правой кнопкой мыши на имени ЦС -> All Tasks > Renew CA Certificate

3 Согласиться с остановкой службы центра сертификации (Certificate Services)

4 Отказаться от генерации новой пару ключей открытого и закрытого (Public/Private)

5 Убедиться, что Полное доменное имя (FQDN) соответствует имени Центра сертификации, и выбрать корневой центр сертификации (Root CA), который должен выписать сертификат.
6 Нажать Ok.
7 Войти на корневой центр сертификации и открыть MMC оснастку Certificate Authority
8 Перейти ожидающие запросы (pending request) и разрешить (issue) продление сертификата
9 Перейти в выданные сертификаты (issued certificates)
10 Дважды щелкнуть мышкой на выданном сертификате, перейти на закладку Details и нажать Copy to File

11 В запустившемся мастере экспорта, экспортировать сертификат как Cer файл и скопировать его на выдающий ЦС (Issuing CA)
12 На выдающем ЦС (Issuing CA) нажать правой кнопкйо мыши > All Tasks > Install CA Certificate

13 Согласиться с остановкой службы центра сертификации (Certificate Services)
14 В открывшемся окне изменить фильтр расширение файла на CER, выбрать файл сертификата и нажать Ок
Сертификат выдающего ЦС обновлен

Обновление сертификата, на Standalone Root CA

1 Выполнить вход на выдающий Центр сертификации и открыть MMC оснастку Certificate Authority
2 Нажать правой кнопкой мыши на имени ЦС -> All Tasks > Renew CA Certificate

3 Согласиться с остановкой службы центра сертификации (Certificate Services)

4 Отказаться от генерации новой пару ключей открытого и закрытого (Public/Private)
5 В открывшемся окне нажать Отмена (Cancel)
6 В корне на диске C появится req файл, который необходимо скопировать на корневом центре сертификации (Root CA)
7 Войти на корневой центр сертификации и открыть MMC оснастку Certificate Authority
8 Нажать правой кнопкой мыши на имени ЦС -> All Tasks > Submit New Request

9 Выбрать req файл запроса, который был скопирован с дочернего ЦС и нажать ОК
10 Перейти ожидающие запросы (pending request) и разрешить (issue) продление сертификата

11 Перейти в выданные сертификаты (issued certificates)
12 Дважды щелкнуть мышкой на выданном сертификате, перейти на закладку Details и нажать Copy to File

13 В запустившемся мастере экспорта, экспортировать сертификат как Cer файл и скопировать его на выдающий ЦС (Issuing CA)
14 На выдающем ЦС (Issuing CA) нажать правой кнопкйо мыши > All Tasks > Install CA Certificate

15 Согласиться с остановкой службы центра сертификации (Certificate Services)
16 В открывшемся окне изменить фильтр расширение файла на CER, выбрать файл сертификата и нажать Ок
Сертификат выдающего ЦС обновлен

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

Перевыпуск просроченного сертификата на OpenVPN -сервере

После анализа выяснялось, что срок действия сертификата центра сертификации (ca.crt) OpenVPN сервера истек.

Для устранения этой ошибки перевыпускаем самоподписанный сертификат центра сертификации

Старый файл сертификата ca.key можно удалить, новый (ca-new.crt) переименовать в ca.crt

Далее, перевыпускаем сертификат сервера

и перезапускаем OpenVPN

Теперь, что бы пользователи смогли подключаться к OpenVPN-серверу надо что б они на ПК заменили старый сертификат центра сертификации ca.crt на новый

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

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

Похожие записи

Интеграция iTop ITSM & CMDB и FreeIPA

iTop (IT Operational Portal) — это веб-продукт с открытым исходным кодом, предназначенный для автоматизации ИТ-подразделений предприятий и сервис провайдеров. iTop разработан на основе лучших практик ITIL/ITSM и в то же время является достаточно гибким, чтобы адаптироваться к процессам вашей организации. В предыдущей статье была рассмотрена установка iTop ITSM & CMDB в Rocky Linux. Для интеграции…

Установка почтового сервера iRedMail на CentOS 7. Часть 1. Базовая установка

iRedMail – полноценный почтовый сервер под Linux, который включает в себя следующие компоненты:– почтовый сервер postfix;– imap и pop3 сервер dovecot;– web-интерфейс почтового клиента roundcube;– web-интерфейс почтового клиента sogo;– greylist (система автоматической блокировки спама);– Amavisd-new (фреймворк по фильтрации содержимого, использующий приложения-помощники для фильтрации вирусов и фильтрации спама антивирус и антиспам: ClamAV и SpamAssassin);– веб-сервер NGINX;–…

Добавляем функцию поиска по сайту рядом с меню в мобильной версии сайта для WordPress темы Ultra

Заходим в админку – Внешний вид – Настроить Выбираем пункт “Дополнительные стили” Добавляем следующие строки: /* для мобильных устройств (максимальная ширина здается в настройках темы) */ @media (max-width: 1024px) < /* отображаем иконку поиска */ nav#site-navigation.main-navigation .menu-search < display: block; left: -38px; >/* скрываем иконку поиска при нажатии на конпку “Меню” */ nav#site-navigation.main-navigation.toggled .menu-search <…

Монтируем новый диск в CentOS

Смотрим информацию о дисках в системе Создаем раздел Если файловая система ext3, то после того как создали 1 раздел на весь диск, надо создать на этом разделе файловую систему. Создаем каталог куда монтировать и монтируем Автомонтирование Редактируем файл fstab и дописываем Не забываем про перенос строки в конце файла

Счетчик просмотров записи в Word Press: плагин Pageviews

По умолчанию плагин Pageviews показывает количество просмотров записи в ее конце. Изменяем внешний вид и расположение, на примере этого сайта Редактируем файл functions.php, добавив в самом низу следующие строки: add_action( ‘after_setup_theme’, function() < add_theme_support( ‘pageviews’ ); >); Это отключает вывод счетчика в конце записи Чтобы добавить вывод счетчика в нужном месте, открываем файл content-single.php (в…

Мониторинг статуса демона Linux в Zabbix

Включаем опцию “Удаленные команды” в Zabbix и перезапускаем Zabbix Agent Создаем новый элемент данных, для этого в web-интерфейсе переходим: Настройки – Узлы сети – выбираем нужный узел – Элементы данных и создаем новый элемент данных Далее создаем триггер В данной статье мониторинг статуса Apache был использован лишь в качестве примера. Данный способ мониторинга подходит в тех…

Установка корневого центра сертификации Microsoft CA на MS Windows Server 2008 R2

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

Однако текущее положение в этой области не позволяет решать вопросы безопасного интернета без существенных финансовых затрат на приобретение SSL- сертификатов. При этом бесплатные сертификаты сервиса Let’s Encrypt покрывают лишь узкий спектр корпоративных потребностей в сертификатах. Например, не покрываются сертификаты для шифрования документов, почты, цифровых подписей, аутентификация клиентов. Для использования публичных сертификатов, выданных коммерческими CA вам необходимо иметь публичный домен. Получить сертификат для веб-сервера на имя domain.local от Let’s Encrypt технически невозможно. Именно поэтому актуальность частных корпоративных центров сертификации остаётся на очень высоком уровне.

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

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

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

Типовая схема двухуровневой схемы центра сертификации (ЦС):

Установка корневого центра сертификации Microsoft CA на MS Windows Server 2008 R2

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

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

Создание файла политик CAPolicy.inf корневого ЦС

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

Содержимое файла CAPolicy.inf будет следующим:

[Version] Signature=”$Windows NT$”

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

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

1. Открыть окно Панели управления, выполнив команды Пуск , Панель управления .
2. В окне Панели управления открыть пункт Администрирование и выбрать Диспетчер сервера .
3. Выбрать пункт Роли . В правой части окна нажать Добавить роли и выделить пункт Службы сертификации Active Directory . В следующем окне мастера выбрать пункты Центр Сертификации — и Служба регистрации в центре сертификации через Интернет .

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

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

Настройка корневого Центра сертификации

Запускаем центр сертификации: Пуск\Все программы\Администрирование\Центр сертификации.

Просмотреть настройки Центра сертификации — вызвать контекстное меню и выбрать Свойства .

В окне можно просмотреть выпущенный самоподписанный сертификат корневого Центра сертификации и проверить, какая информация легла в сертификат из файла политик CAPolicy.inf и при установке Центра сертификации.

Настроить Модуль политики на выдачу сертификатов в автоматическом режиме. Установить переключатель в строку Следовать параметрам…

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

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

Настройка публикации списка отозванных сертификатов

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

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

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

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

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

Оставить по умолчанию тип публикуемого CRL – Новый базовый CRL. Нажать кнопку ОК .

Для просмотра и изменения параметров публикации CRL в окне контекстного меню выберем Свойства .

Посмотреть выпущенные списки отозванных сертификатов можно в закладке Просмотр списков отзыва сертификатов (CRL).

Списки отозванных сертификатов размещены в папке C:\Windows\System32\Certsrv\CertEnroll , куда по умолчанию публикуются списки.