WIKi

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

<p><em>Дата: 4 сентября 2016 г. | Категория: Microsoft</em></p>

<h2>Оглавление</h2>

<ul>

  <li><a href="#issue">Проблема</a></li>

  <li><a href="#workaround">Временное решение</a></li>

  <li><a href="#cause">Причина недоступности CRL</a></li>

  <li><a href="#fix">Как исправить</a></li>

  <li><a href="#conclusion">Заключение</a></li>

</ul>

<hr>

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

<h2 id="issue">Проблема</h2>

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

<blockquote>

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

</blockquote>

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

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

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

<blockquote>

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

</blockquote>

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

<blockquote>

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

</blockquote>

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

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

<p><em>Неудачные запросы на сертификаты из-за CRYPT_E_REVOCATION_OFFLINE</em></p>

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

<p><strong>Точка распространения CRL на подчинённом CA</strong></p>

<h2 id="workaround">Временное решение</h2>

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

<pre><code>certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE</code></pre>

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

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

<h2 id="cause">Причина недоступности CRL</h2>

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

<pre><code>http://crl.home.stealthpuppy.com/CertEnroll/stealthpuppy Issuing CA.crl

http://crl.home.stealthpuppy.com/CertEnroll/stealthpuppy Offline Root CA.crl</code></pre>

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

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

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

<pre><code>certutil -URL "http://crl.home.stealthpuppy.com/CertEnroll/stealthpuppy Issuing CA.crl"</code></pre>

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

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

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

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

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

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

<p><em>Просмотр свойств CRL корневого CA</em></p>

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

<h2 id="fix">Как исправить</h2>

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

<ol>

  <li>Запустите автономный корневой CA, войдите в систему и откройте консоль <strong>Certification Authority</strong>.</li>

  <li>Сначала убедитесь, что интервал публикации CRL увеличен, чтобы в ближайшее время не столкнуться с той же проблемой. Откройте свойства узла <strong>Revoked Certificates</strong>, чтобы просмотреть и задать интервал публикации. Интервал по умолчанию — 1 неделя, что, очевидно, слишком часто для автономного корневого CA.</li>

  <li>Вместо этого установите значение, подходящее для вашей среды. Помните, что вам нужно будет загрузить корневой CA и опубликовать новый CRL до окончания этого интервала, иначе вы столкнётесь с точно такой же проблемой.</li>

</ol>

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

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

<p><em>Публикация нового CRL с корневого CA</em></p>

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

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

<p><em>Просмотр проверенного CRL с помощью certutil.exe</em></p>

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

<pre><code>certutil –setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE</code></pre>

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

<h2 id="conclusion">Заключение</h2>

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

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

<hr>

<p><strong>Автор:</strong> Aaron Parker (stealthpuppy)<br>

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

<p><em>Оригинал статьи: <a href="https://stealthpuppy.com/resolving-issues-starting-ca-offline-crl/">https://stealthpuppy.com/resolving-issues-starting-ca-offline-crl/</a></em></p>