The certificate status could not be determined because the revocation check failed
В Интернете много статей, которые рассказывают о том, как бороться с ошибкой "The certificate status could not be determined because the revocation check failed", но к сожалению, мне не удалось найти ту, которая описывала бы мою проблему, так что я решил написать эту короткую заметку.
Начнем с того, что сообщения в графической консоли поводу ошибки в сертификате совсем не означает, что сертификат нельзя назначить на нужные сервисы. Exchange Management Shell не выполняет подобных проверок и через EMS вы легко можете достичь желаемого:
- Get-ExchangeCertificate
- Копируем Thumbprint
- Enable-ExchangeCertificate -Thumbpring <отпечаток, полученный выше> -Services SMTP,IIS,IMAP
Далее, почему такая ошибка может быть
Дело все в том, что в Exchange Management Console есть процедура проверки сертификатов и одним из шагов данной проверки является проверка на "отозванность", т.е. серверу нужно скачать Certificate Revocation List (CRL), выпущенный центром сертификации, выдавшим данный сертификат, и убедиться, что в этом листе нет текущего сертификата.
Откуда будем качать CRL?
В каждом сертификате есть специальное поле CRL Distribution Points, где обозначено откуда можно скачать CRL:
Для доступа в Интернет по HTTP, Exchange использует настройки прокси сервера, указанные в системе, посмотреть можно через
netsh winhttp show proxy
Подробнее про WinHttp и как это настроить читайте здесь - https://support.microsoft.com/kb/979694
Соответственно на прокси должен быть разрешен выход в Интернет для данного сервера.
Как проверить сертификат?
Для начала попробуем открыть ссылку, указанную в CRL Distribution Point, прямо в браузере - должен загрузиться соответствующий файл (у меня открылся)
Далее следует выполнить очистку CRL и OCSP кэшей:
Certutil -urlcache ocsp delete
certutil -urlcache crl delete
После этого можно проверить сертификата через утилиту Certutil:
- Экспортируйте сертификат в файл (без закрытого ключа)
- Выполните команду
Certutil -url <certificate file name>
- Нажмите кнопку Retrieve
- В результате статус для Base CRL и Delta CRL должен быть Verified
Видим, что есть ещё и CRL+ - это собственно Delta CRL, который мы конфигурировали на СА. Чтобы понять почему в данном случае не проходит проверка Delta CRL я ещё раз открыл консоль управления Exchange с включенным Network Monitor`ом и вот что получилось:
Выходит, что IIS отвечает File Not Found, хотя при этом файл в каталоге есть.
После не продолжительных поисков стало понятно, что по умолчанию IIS блокирует ссылки в которых есть знак "+". Для того, чтобы разрешить IIS принимать запросы, у которых в адресе указан знак “+”, откроем командную строку (cmd) от имени администратора на сервере с установленным центром сертификации и выполняем команду:
%windir%\system32\inetsrv\appcmd set config /section:requestfiltering /allowdoubleescaping:true
После чего следует перезапустить службу Microsoft.Exchange.ServiceHost и открыть консоль заново.
В моем случае это решило проблему. Если у вас проблема сохраняется - мы можем обсудить это в комментариях к статье.
Alexey Bogomolov,
Microsoft Engineer,
Customer Service and Support
- Anonymous
January 01, 2003
Спасибо, Alexey!
Про "+" я не знал. - Anonymous
July 08, 2014
Спасибо - Anonymous
February 24, 2015
Thank you, your post was helpful in finding a solution. In my case, our firewall was blocking the URL for the CRL because of category "web hosting". I found this by trying to open the URL found in the CRL Distribution Point for the certificate that I learned from your post. - Anonymous
December 28, 2015
Спасибо. Очень помогло.