Невозможно проверить функцию отзыва т к сервер отзыва сертификатов недоступен 80092013

[1]Доступ к сведениям центра сертификации
     Метод доступа=Протокол определения состояния сертификата через сеть (1.3.6.1.5.5.7.48.1)
     Дополнительное имя:
          URL=http://tax4.tensor.ru/ocsp-tensorca-2021_gost2012/ocsp.srf

[1]Точка распределения списка отзыва (CRL)
     Имя точки распространения:
          Полное имя:
               URL=http://tax4.tensor.ru/tensorca-2021_gost2012/certenroll/tensorca-2021_gost2012.crl

#define CRYPT_E_REVOCATION_OFFLINE       _HRESULT_TYPEDEF_(0x80092013L)
Комментарий 
MessageId: CRYPT_E_REVOCATION_OFFLINE
MessageText: The revocation function was unable to check revocation because the revocation server was offline.

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

Расширенная диагностика проблем с подписанием

Предполагается, что

• КриптоПро на рабочем месте в порядке — лицензия установлена, сертификаты просматриваются, контейнеры тестируются;
• Ошибка, если она есть, не входит в список типовых
• Очистка кэша браузера проведена;
• И все равно подписание не работает: есть ошибки про статус сертификата/списки отзывов и/или сертификат недоступен для выбора в услуге, где требуется подписание документов.

1. Проверить работоспособность подписания в браузере. 

На иллюстрации ниже : напротив нужного сертификата вместо кнопки «Подписать» указание на самые распространенные проблемы. К сожалению, страница браузера не может точнее указать — что именно сделать, поэтому требуется ручное вмешательство. 

Результат теста может понадобится для дальнейшего общения с техподдержкой.

Картинка с сайта: www.rlisystems.ru

Дополнительно: страница для проверки работы подписания от КриптоПро, иногда полезно сравнить результаты: https://www.cryptopro.ru/sites/default/files/products/cades/demopage/cades_bes_file.html

2. Применить утилиту certutil

• Сохранить сертификат, который должен использоваться для подписания, в cer файл через «Просмотр сертификатов» в КриптоПро, например в c:\temp\cert.cer
• Открыть командную строку «Пуск → Выполнить → cmd»;
• В командной строке выполнить команду certutil -verify , указав путь до сертификата, например, certutil -verify c:\temp\cert.cer  
• В выводе команды поискать слово ОШИБКА, проблема на этой строке или соседних. Если ошибок нет или непонятно что с ними делать — см следующий пункт.
• Диагностику можно вывести в текстовый файл:  certutil -verify  c:\temp\cert.cer > c:\temp\test_result.txt  и прислать в нашу техподдержку для анализа.

3. Проверить списки отзывов 

Проблемы со списком отзывов обычно выявляются в предыдущем пункте. Ошибка может звучать так:
ОШИБКА: проверка состояния отзыва сертификата вернула Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен . 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)CertUtil: Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен .

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

Картинка с сайта: www.rlisystems.ru

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

Картинка с сайта: www.rlisystems.ru

Если это не так — проверить на другом рабочем месте. Если список отзыва действительно устарел — сообщайте в техподдержку.

4. Решение проблем с корневыми сертификатами

Этот пункт нужен, если в п.2 выявлены проблемы с корневыми  или поддержка порекомендовала его сделать.

Устанавливать корневые сертификаты рекомендуется только установщиком с сайта. При ручной установке иногда возникает труднодиагностируемая ситуация, когда вроде бы все правильно выглядит, но подписание не работает. Certutil -verify обычно выявляет эту проблему.

Процедура переустановки:

• Удалить все сертификаты, изданные GIS CA, во всех разделах — «Доверенные корневые центры сертификации», «Промежуточные центры сертификации», в реестре текущего пользователя и компьютера (если есть права). Убедиться, что их нет не только в «доверенных корневых», но и в «промежуточных» и  личных.
• Скачать и заново прогнать установщик корневых https://www.rlisystems.ru/Download/x86/roliscertsetup.exe
• Очистить кэш браузера
• В командной строке выполнить certutil -urlcache crl delete

Пробовать подписать.

5. Решение проблем с КриптоПро

Этот пункт нужен, если все остальное уже проверено.

Обычно достаточно провести проверку подписания (п.1 на этой странице) но, к сожалению, были случаи, когда тестовое подписание проходило, а настоящее — нет, и это решалось восстановлением работоспособности КриптоПро.

Запустить КриптоПро с правами администратора. Есть вот эта кнопка активна — нажать.

Картинка с сайта: www.rlisystems.ru

В некоторых случаях помогает только  процедура переустановки или восстановления Она быстрая и несложная, но требует прав Администратора:

1. Панель управления — Программы и компоненты — найти КриптоПро CSP, выделить эту строку и в верхней части окна нажать «Восстановить».
   В этом случае не понадобится заново вводить лицензию. Перезагрузка — если попросит.
   В разных версиях Windows 10/11 названия пунктов могут отличаться, смысл тот же — запустить режим восстановления КриптоПро.
2. Если не помогло: удалить КриптоПро CSP, перезагрузить ПК, установить КриптоПро CSP, еще раз перезагрузить ПК. Потребуется повторный ввод лицензии.

Ситуация следующая. Имеются два центра сертификации (Certification Authority, CA) — Offline Root CA (корневой) и Enterprise Subordinate CA (подчиненный). Схема стандартная, подчиненный CA занимается выпуском сертификатов, корневой стоит в выключенном состоянии и включается только для обновления своего сертификата, сертификата подчиненного CA и списка отзыва (Certificate Revocation List, CRL).

И вот, после очередного обновления сертификата подчиненного CA он отказался включаться и выдал ошибку 0x80092013 (CRYPT_E_REVOCATION_OFFLINE). В сообщении об ошибке сказано, что функция отзыва не может проверить список отзыва, поскольку сервер отзыва недоступен. Эта ошибка возникает в следующих ситуациях:

• Недоступен список отзыва (CRL);
• Не опубликовано местоположение CRL;
• Истек срок действия CRL.

Картинка с сайта: windowsnotes.ru

Порывшись в системном журнале, нашел ошибку с Event ID 48. Из сообщения видно, что для сертификата 5 не удается проверить цепочку доверия.

Картинка с сайта: windowsnotes.ru

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

certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

Картинка с сайта: windowsnotes.ru

Теперь запускаем CA, кликаем правой клавишей на сервере и выбираем пункт меню «Properties».

Картинка с сайта: windowsnotes.ru

Открывается окно свойств CA. На вкладке «General» находим список сертификатов, выбираем нужный и жмем «View Certificate».

В свойствах сертификата находим строчку «CRL Distribution Points» с адресами, по которым должен находится список отзыва. Адресов два — файловая шара на корневом CA и веб-сайт на подчиненном CA. И как и следовало ожидать, ни по одному из адресов CRL не доступен.

Для нормальной работы нам нужно найти актуальный CRL. Идем на корневой CA, открываем оснастку «Certification Authority» — «Properties», переходим на вкладку «Extensions» и выбираем из списка расширение «CRL Distribution Point (CDP)». В нем находится список мест, в которых публикуется список отзыва. Что интересно, в списке есть и подчиненный CA, но по какой то причине CRL на него не попал.

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

Затем включаем обратно проверку:

certutil –setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

и рестартуем сервис:

Restart-Service certsvc -force

Сервис стартует успешно, значит все сделано правильно.

Картинка с сайта: windowsnotes.ru

When you deploy a standalone root CA (certainly offline, if you follow Microsoft’s best practices), as well as multiple subordinate CAs, your infrastructure may suddenly stop working one day.

This is because when you take your standalone root CA offline, you must manually publish and update that CA’s revocation list in your Active Directory infrastructure.
If you forget to do this, all your subordinate CAs under this standalone root CA will stop working when your root CA’s revocation list expires.

1. Encountered problem
2. Expired root CA revocation list
3. Change the validity period of your root CA’s certificate revocation list
4. Update the certificate revocation list in your Active Directory
5. Start your secondary CA

1. Encountered problem

On one of your secondary CAs, you notice that it’s not started.
So, you try to start it manually.

Картинка с сайта: us.informatiweb-pro.net

Your secondary CA refuses to start and this error appears :

Plain Text

The revocation function was unable to check the revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE).

This error tells you that your subordinate CA could not check for revocation of its certificate because your standalone root CA is not reachable.
Which is normal since you keep it offline for security reasons.

If your subordinate CA is trying to re-download your standalone root CA’s revocation list, it’s because the previously published copy in your Active Directory infrastructure has expired.

Картинка с сайта: us.informatiweb-pro.net

2. Expired root CA revocation list

To see this revocation list, you can use the «Active Directory Sites and Services» console of your domain controller.
In this console, click on «View -> Show Services Node» to display the «Services» node of this console.
Then, go to : Services -> Public Key Services -> CDP -> [root CA server name].

As you can see, your root CA’s certificate revocation list is there.

Картинка с сайта: us.informatiweb-pro.net

In our case, this revocation list was published manually in the Active Directory on 04/16/2022.

Картинка с сайта: us.informatiweb-pro.net

Which corresponds to the file below that we had published in the AD previously.

Картинка с сайта: us.informatiweb-pro.net

As you can see, this one was created on 04/16/2022 and this one is due to be updated on April 24th.
In other words, it expires on that day.

Because this certificate revocation list of your root CA has expired, you receive an error regarding revocation checking on your subordinate CA.

Картинка с сайта: us.informatiweb-pro.net

3. Change the validity period of your root CA’s certificate revocation list

To prevent this revocation error from appearing in the future, you can change the validity period of your root CA’s certificate revocation list.
To do this, on this root authority, right-click «Properties» on the «Revoked Certificates» folder.

Картинка с сайта: us.informatiweb-pro.net

As you can see, in our case, we left the default «1 week».
Which is obviously too low, because it means you’ll have to start your standalone root CA every week (minus 1 day) to manually publish the new CRL to your Active Directory infrastructure.

Картинка с сайта: us.informatiweb-pro.net

To solve the problem, it’s advisable to extend this publication interval to 6 months or 1 year (for example).
Thus, you will need to start this standalone root CA and manually republish its revocation list only once or twice a year.

Click «Apply» to save this change.

Картинка с сайта: us.informatiweb-pro.net

Then, if you go to the «View CRLs» tab, you will see that a new full CRL has already been generated by your standalone root CA since the old one was expired.
However, this is only valid for one week (by default).

Картинка с сайта: us.informatiweb-pro.net

You can get more information about this revocation list by clicking the «View CRL» button.

Картинка с сайта: us.informatiweb-pro.net

To use the new publishing interval, you will need to manually publish (once) the new CRL.
To do this, right-click «All Tasks -> Publish» on «Revoked Certificates».

Картинка с сайта: us.informatiweb-pro.net

On a standalone root CA, you can only generate a certificate revocation list (CRL).
So, just click OK.

Картинка с сайта: us.informatiweb-pro.net

Then, right-click «Properties» on «Revoked Certificates».

Картинка с сайта: us.informatiweb-pro.net

In the «View CRLs» tab, you will see that the CRL has been updated.

Картинка с сайта: us.informatiweb-pro.net

If you click on the «View CRL» button, you will see that it’s valid for 1 year.

Картинка с сайта: us.informatiweb-pro.net

As usual, you will find this new revocation list in the «C:\Windows\System32\CertSrv\CertEnroll» folder of your standalone root certification authority.

Картинка с сайта: us.informatiweb-pro.net

If you double click on it, you will see that it’s the same revocation list.

Картинка с сайта: us.informatiweb-pro.net

4. Update the certificate revocation list in your Active Directory

Now that you’ve generated a new CRL from your standalone root CA console, you need to update the one in your Active Directory infrastructure.
To do this, transfer the corresponding «.crl» file to one of your domain controllers (using an USB key, for example).

Картинка с сайта: us.informatiweb-pro.net

Then, use the command below to publish this certificate revocation list to your Active Directory infrastructure.

Batch

certutil -dspublish "C:\Root CA data\InformatiWeb Root CA.crl"

Картинка с сайта: us.informatiweb-pro.net

Return to the «Active Directory Sites and Services» console and go to the folder : Services -> Public Key Services -> CDP -> [root CA server name].
As you can see, the «cRLDistributionPoint» type object is still present.

Картинка с сайта: us.informatiweb-pro.net

But if you double click on it, you will see that the modified date has been updated.
This means that the revocation list present in the Active Directory has been replaced by the new one.

Картинка с сайта: us.informatiweb-pro.net

5. Start your secondary CA

Now that your standalone root CA’s revocation list has been updated in your Active Directory infrastructure, you can start your secondary CA.

Картинка с сайта: us.informatiweb-pro.net

Wait while it starts.

Картинка с сайта: us.informatiweb-pro.net

As expected, your subordinate CA started without issue.

Картинка с сайта: us.informatiweb-pro.net