Решение проблем с запуском центра сертификации из-за недоступного CRL¶

Дата: 4 сентября 2016 г. | Категория: Microsoft

Недавно я написал несколько статей о настройке корневого центра сертификации (Root CA) и подчинённого центра сертификации (Subordinate CA) в качестве базовой шпаргалки по развёртыванию корпоративной PKI. Один из элементов конфигурации, который менее понятен и часто становится причиной серьёзных проблем с центрами сертификации, — это список отозванных сертификатов (CRL, Certificate Revocation List). Недоступный CRL может вывести из строя вашу PKI и другие службы, которые от неё зависят.

Проблема¶

Вы можете обнаружить, что ваш центр сертификации (в данном случае — подчинённый CA) не запускается, возможно, после перезагрузки сервера. При попытке запустить CA появляется следующее сообщение:

Функция проверки отзыва не смогла проверить отзыв, поскольку сервер отзыва был недоступен. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)

Что выглядит следующим образом:

Невозможно запустить CA из-за недоступного CRL CRYPT_E_REVOCATION_OFFLINE

В журнале приложений подчинённого CA можно увидеть событие с ID 100 от источника CertificationAuthority:

Active Directory Certificate Services не запустился: Не удалось загрузить или проверить текущий сертификат CA. stealthpuppy Issuing CA. Функция проверки отзыва не смогла проверить отзыв, поскольку сервер отзыва был недоступен. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE).

А также событие с ID 48 от того же источника, CertificationAuthority:

Не удалось проверить статус отзыва для сертификата в цепочке для сертификата CA 0 для stealthpuppy Issuing CA, поскольку сервер в настоящее время недоступен. Функция проверки отзыва не смогла проверить отзыв, поскольку сервер отзыва был недоступен. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE).

Сертификат 0 — это сертификат подчинённого CA, выданный автономным корневым CA.

Кроме того (после запуска CA с использованием временного решения) можно увидеть множество неудачных запросов на сертификаты с той же ошибкой Offline CRL:

Неудачные запросы на сертификаты из-за CRYPT_E_REVOCATION_OFFLINE

В данном случае я знал, что мой CRL был доступен — он размещён на том же сервере, что и подчинённый CA, и я настроил как автономный корневой CA, так и подчинённый CA на использование одной и той же точки распространения CRL.

Точка распространения CRL на подчинённом CA

Временное решение¶

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

certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

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

Установка флага CRLF_REVCHECK_IGNORE_OFFLINE с помощью certutil.exe

Причина недоступности CRL¶

Мой CRL был доступен, так как он размещён в Active Directory (для компьютеров, присоединённых к домену) и через HTTP по адресу crl.home.stealthpuppy.com — псевдониму подчинённого CA. Я проверил, что могу получить CRL, вставив HTTP-путь в браузер, и мне было предложено загрузить файл.

http://crl.home.stealthpuppy.com/CertEnroll/stealthpuppy Issuing CA.crl
http://crl.home.stealthpuppy.com/CertEnroll/stealthpuppy Offline Root CA.crl

Поскольку я недавно потратил время на настройку корпоративной PKI в своей лаборатории и для одного проекта, я хорошо познакомился с консольной утилитой certutil.exe. Этот инструмент доступен во всех версиях Windows и должен быть первым инструментом для устранения неполадок и управления сертификатами и центрами сертификации в Windows.

Certutil может выполнять множество функций, одна из которых — проверка CRL. Я знаю путь к файлу CRL, потому что могу просмотреть CRL в файловой системе (в C:\Windows\System32\certsrv\CertEnroll), и я ранее настроил CRL для обоих CA.

Для проверки CRL используйте переключатель -URL с HTTP- (или LDAP-) путём к CRL:

certutil -URL "http://crl.home.stealthpuppy.com/CertEnroll/stealthpuppy Issuing CA.crl"

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

Использование certutil.exe для тестирования CRL

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

Выберите сертификат для подчинённого CA, который был ранее экспортирован в файловую систему (в C:\Windows\System32\certsrv\CertEnroll) — нажмите Select, откройте сертификат и снова нажмите Retrieve. На этот раз мы увидим новую строку, показывающую, что базовый CRL для сертификата подчинённого CA истёк.

Истёкший базовый CRL на подчинённом CA

CRL для сертификата подчинённого CA поступает от корневого CA, поэтому нам нужно проверить именно этот CRL. Откройте файл CRL (C:\windows\system32\certsrv\CertEnroll\stealthpuppy Offline Root CA.crl) — дважды щёлкните или щёлкните правой кнопкой мыши и выберите Open. Здесь мы можем увидеть информацию о CRL, включая время следующей публикации (Next CRL Publish).

Просмотр свойств CRL корневого CA

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

Как исправить¶

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

1. Запустите автономный корневой CA, войдите в систему и откройте консоль Certification Authority.
2. Сначала убедитесь, что интервал публикации CRL увеличен, чтобы в ближайшее время не столкнуться с той же проблемой. Откройте свойства узла Revoked Certificates, чтобы просмотреть и задать интервал публикации. Интервал по умолчанию — 1 неделя, что, очевидно, слишком часто для автономного корневого CA.
3. Вместо этого установите значение, подходящее для вашей среды. Помните, что вам нужно будет загрузить корневой CA и опубликовать новый CRL до окончания этого интервала, иначе вы столкнётесь с точно такой же проблемой.

Настройка интервала публикации CRL на корневом CA

Теперь опубликуйте новый CRL: щёлкните правой кнопкой мыши по узлу Revoked Certificates и выберите All Tasks → Publish.

Публикация нового CRL с корневого CA

Скопируйте обновлённый CRL (по умолчанию из C:\Windows\System32\certsrv\CertEnroll) с корневого CA в точку распространения CRL и перезапишите существующий файл CRL (снова C:\Windows\System32\certsrv\CertEnroll на моём подчинённом CA).

Теперь, если мы снова используем certutil.exe для проверки CRL, всё будет в порядке:

Просмотр проверенного CRL с помощью certutil.exe

Чтобы убедиться, что служба центра сертификации подчинённого CA запустится, повторно включите проверку CRL:

certutil –setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

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

Заключение¶

Я сталкивался с этой проблемой недоступного CRL несколько раз и по-настоящему не понимал, в чём именно проблема, пока не уделил время надлежащему устранению неполадок. Я не так часто работаю с корпоративной PKI, и легко недооценить сложность правильной настройки служб сертификации AD.

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

---

Автор: Aaron Parker (stealthpuppy)
О себе: Специалист по end-user computing с 30-летним опытом в предпродажной подготовке, проектировании, внедрении и поддержке сред end-user computing (виртуальные рабочие столы, современное управление устройствами и корпоративная мобильность). Aaron также около 20 лет участвует в IT-сообществе, выступая с докладами, ведя блог и поддерживая open-source проекты. В настоящее время — Senior Staff Engineer в Office of the CTO @ Nerdio.

Оригинал статьи: https://stealthpuppy.com/resolving-issues-starting-ca-offline-crl/