Ignore error 0x80092013 certificate revocation list offline

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

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

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

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

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

certutil –setreg caCRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

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

Открывается окно свойств 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 caCRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

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

Restart-Service certsvc -force

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

Источник

Содержание

Ignore error 0x80092013 certificate revocation list offline
Сервер отзыва сертификатов недоступен
Ошибка 0x80092013 при запуске службы Certification Authority
Ошибка сертификатов после установки SFB 2015

Добрый день уважаемые читатели, сегодня хочу рассказать как решается вот такая ошибка Службы сертификации Active Directory не запущены: Не удается загрузить или проверить текущий сертификат ЦС. IssueCrmCA «Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен. 0x80092013 (-2146885613)». Из-за этой ошибки не открывался сам центр выдачи сертификатов, и как следствие не работал Web выпуск, давайте рассмотрим, как это устраняется и исправим это дело.

Сервер отзыва сертификатов недоступен

И так давайте опишу ситуацию, есть у нас в компании для своих внутренних нужд Цент сертификации, развертывал я его на Windows Server 2008 r2 и мы с вами его уже даже лечили от ошибки Не найдены шаблоны сертификатов. Вы не имеете прав запрашивать сертификат на этом ЦС. В один из дней пишет мой коллега и говорит, что у него не стартует служба, так как он был загружен, он попросил посмотреть, что там. И так заходим на сервер с Windows Server 2008 r2 и в пункте администрирование открываем оснастку Центр Сертификации. Он во первых долго открывался, так как пытался рестартовать службу, после чего появилась оснастка с квадратиком на значке, означающем, что он выключен. Вы области описания было вот такое сообщение.

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

Если зайти в просмотр событий в журнал Приложения, то сможете найти сообщение с кодом события 48, который вам выдаст туже ошибку.

Как видите все они ругаются на недоступность сертификата в цепочке сертификатов, CRL, или как его еще называют списка отозванных. Открываем пуст и вводим mmc, для открытия оснастки. (Я уже рассказывал как создать мега мощную и удобную консоль mmc, почитайте будет очень полезно)

Нажимаем CTRL+M для добавления оснастки.

Вам нужно добавить две оснастки

PKI предприятия
Учетной записи компьютера

Выбираем локальный компьютер, так как мы сейчас на центре сертификации.

Как видите в PKI предприятии мы видим, красный предупреждающий значок. Но в начале давайте откроем сам сертификат издающего, центра сертификации. Для этого открываем пункт Личное и сам серт. Во вкладке Состав находим строку Точки распространения списка отзыва и смотрим адрес, в моем случае это http://crl.aetp.ru/crl/RootCrmCA.crl. Пробуем открыть этот адрес. У меня он не открывался, так как с этой виртуальной машины убрали внешний ip адрес, который и отвечал за этот адрес. http://crl.aetp.ru/crl/ располагался как сайт IIS, а сама папка crl лежала у меня в корне диска C данного центра сертификации.

В итоге у вас два варианта

Восстановить внешний ip адрес или развернуть данный адрес на другом сервере
Либо локально в файле Hosts прописать, что crl.aetp.ru это локальный ip данного сервера, что я и сделал.

Пробуем пропинговать внешнее имя, щас все ок, запускаем CA. Видим, что ошибка опять выскочила ошибка Не удается загрузить или проверить текущий сертификат ЦС. IssueCrmCA Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен. 0x80092013 (-2146885613) пропала, но появилась уже другая, что у вас просрочен CDP crl, и действительно его срок кончился.

Идем на root CA открываем оснастку Центра сертификации и в пункте Отозванные сертификаты щелкаем правым кликом > Все задачи > Публикация. Чтобы у вас сформировался новый список отозванных, появится он в папке C:WindowsSystem32certsrvCertEnroll. Его от туда нужно скопировать в папку где у вас лежат на издающем Центре сертификации crl файлы. После этого

Все видим в консоли подхватился новый crl список отозванных.

Все видим и PKI предприятие показывает, что вся цепочка жива.

Вот так вот просто решить ошибку Службы сертификации Active Directory не запущены: Не удается загрузить или проверить текущий сертификат ЦС. IssueCrmCA Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен. 0x80092013 (-2146885613). А вообще я подумываю написать цикл статей, о том как работает и устанавливается Центр сертификации в Windows Server 2008 r2 и 2012 r2, но все зависит от свободного времени.

Источник

Ошибка 0x80092013 при запуске службы Certification Authority

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

certutil –setreg caCRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

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

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

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

certutil –setreg caCRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

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

Restart-Service certsvc -force

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

Источник

Ошибка сертификатов после установки SFB 2015

Все новые темы

Автор

Странник05
Активный участник

Зарегистрирован: 23.06.2005
Пользователь #: 27,078
Сообщения: 764

Голоса: 1

Добавлено: Вт 06 Окт, 2015 11:38 Заголовок сообщения: Ошибка сертификатов после установки SFB 2015

Вернуться к началу

Зарегистрируйтесь и реклама исчезнет!

chastener
подпись на выбор, в личку sklifу

Зарегистрирован: 29.06.2011
Пользователь #: 132,104
Сообщения: 10907

Голоса: 46

Добавлено: Вт 06 Окт, 2015 19:01 Заголовок сообщения:

Вернуться к началу

VitohA
Активный участник

Зарегистрирован: 17.08.2009
Пользователь #: 80,819
Сообщения: 1037
Откуда: Воронеж

Голоса: 10

Добавлено: Вт 06 Окт, 2015 20:47 Заголовок сообщения:
_________________ Учусь админить

Вернуться к началу

root_man
Активный участник

Зарегистрирован: 25.12.2008
Пользователь #: 74,849
Сообщения: 793

Голоса: 6

Добавлено: Ср 07 Окт, 2015 11:12 Заголовок сообщения:

Вернуться к началу

Странник05
Активный участник

Зарегистрирован: 23.06.2005
Пользователь #: 27,078
Сообщения: 764

Голоса: 1

Добавлено: Ср 07 Окт, 2015 11:47 Заголовок сообщения:

Вернуться к началу

root_man
Активный участник

Зарегистрирован: 25.12.2008
Пользователь #: 74,849
Сообщения: 793

Голоса: 6

Добавлено: Ср 07 Окт, 2015 12:17 Заголовок сообщения:

Вернуться к началу

Странник05
Активный участник

Зарегистрирован: 23.06.2005
Пользователь #: 27,078
Сообщения: 764

Голоса: 1

Добавлено: Ср 07 Окт, 2015 12:35 Заголовок сообщения:

Вернуться к началу

Странник05
Активный участник

Зарегистрирован: 23.06.2005
Пользователь #: 27,078
Сообщения: 764

Источник

Adblock
detector

Источник

Windows Vista Business Windows Vista Enterprise Windows Vista Home Basic Windows Vista Home Premium Windows Vista Starter Windows Vista Ultimate Windows Server 2008 Datacenter Windows Server 2008 Datacenter without Hyper-V Windows Server 2008 Enterprise Windows Server 2008 Enterprise without Hyper-V Windows Server 2008 for Itanium-Based Systems Windows Server 2008 Foundation Windows Server 2008 Standard Windows Server 2008 Standard without Hyper-V More…Less

Symptoms

Consider the following scenario:

You request a certificate from a computer that is running Windows Server 2008 or Windows Vista.
You build multiple certificate chains for the certificate.
One certificate chain has a revoked certificate.
Note The other certificate chains are good.
You try to verify the certificate.

In this scenario, certificate validation fails and you receive the following error message:

0x80092013, CRYPT_E_REVOCATION_OFFLINE, The revocation function was unable to check revocation because the revocation server was offline

Cause

This issue occurs because some status bits are carried over incorrectly to the validation of other chains if the chain that has a revoked certificate is validated first.

Resolution

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a «Hotfix download available» section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft website:

http://support.microsoft.com/contactus/?ws=supportNote The «Hotfix download available» form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Prerequisites

To apply this hotfix, you must be running one of the following operating systems:

Windows Vista Service Pack 1 (SP1)
Windows Vista Service Pack 2 (SP2)
Windows Server 2008
Windows Server 2008 Service Pack 2 (SP2)

For more information about how to obtain a Windows Vista service pack, click the following article number to view the article in the Microsoft Knowledge Base:

935791 How to obtain the latest Windows Vista service pack

For more information about how to obtain a Windows Server 2008 service pack, click the following article number to view the article in the Microsoft Knowledge Base:

968849 How to obtain the latest service pack for Windows Server 2008

Registry information

To use the hotfix in this package, you do not have to make any changes to the registry.

Restart requirement

You must restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace a previously released hotfix.

File information

The global version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.

Windows Vista and Windows Server 2008 file information notes

Important Windows Vista hotfixes and Windows Server 2008 hotfixes are included in the same packages. However, only «Windows Vista» is listed on the Hotfix Request page. To request the hotfix package that applies to one or both operating systems, select the hotfix that is listed under «Windows Vista» on the page. Always refer to the «Applies To» section in articles to determine the actual operating system that each hotfix applies to.

The files that apply to a specific product, SR_Level (RTM, SPn), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table.

Version	Product	SR_Level	Service branch
6.0.600 2. 22xxx	Windows Vista and Windows Server 2008	SP2	LDR

Service Pack 1 is integrated into the release version of Windows Server 2008. Therefore, RTM milestone files apply only to Windows Vista. RTM milestone files have a 6.0.0000.xxxxx version number.
The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the «Additional file information for Windows Server 2008 and for Windows Vista» section. MUM files and MANIFEST files, and the associated security catalog (.cat) files, are extremely important to maintain the state of the updated components. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.

For all supported x86-based versions of Windows Server 2008 and of Windows Vista

File name	File version	File size	Date	Time
Crypt32.dll	6.0.6002.22739	978,944	06-Nov-2011	00:03

For all supported x64-based versions of Windows Server 2008 and of Windows Vista

File name	File version	File size	Date	Time
Crypt32.dll	6.0.6002.22739	1,260,544	07-Nov-2011	09:13

For all supported IA-64–based versions of Windows Server 2008

File name	File version	File size	Date	Time
Crypt32.dll	6.0.6002.22739	2,374,144	06-Nov-2011	17:49

Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the «Applies to» section.

More Information

For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:

824684 Description of the standard terminology that is used to describe Microsoft software updates

For more information about a similar issue, click the following article number to view the article in the Microsoft Knowledge Base:

2615174 «0x80092013, CRYPT_E_REVOCATION_OFFLINEA» error message when you try to verify a certificate that has multiple chains in Windows Server 2008 R2 or in Windows 7

Additional file information

Additional file information for Windows Vista and for Windows Server 2008

Additional files for all supported x86-based versions of Windows Vista and of Windows Server 2008

File name	X86_57ba57d1b24608bdc8cd9d109dd4df31_31bf3856ad364e35_6.0.6002.22739_none_dca4e57bc461ad59.manifest
File version	Not applicable
File size	699
Date (UTC)	07-Nov-2011
Time (UTC)	12:24
File name	X86_microsoft-windows-crypt32-dll_31bf3856ad364e35_6.0.6002.22739_none_5dc8747af427da09.manifest
File version	Not applicable
File size	7,228
Date (UTC)	06-Nov-2011
Time (UTC)	00:26

Additional files for all supported x64-based versions of Windows Vista and of Windows Server 2008

File name	Amd64_30a1d822b55b97be9cc7233f2a29f433_31bf3856ad364e35_6.0.6002.22739_none_abbdde180fe452d6.manifest
File version	Not applicable
File size	1,046
Date (UTC)	07-Nov-2011
Time (UTC)	12:24
File name	Amd64_microsoft-windows-crypt32-dll_31bf3856ad364e35_6.0.6002.22739_none_b9e70ffeac854b3f.manifest
File version	Not applicable
File size	7,258
Date (UTC)	07-Nov-2011
	09:36

Time (UTC)

Additional files for all supported IA-64–based versions of Windows Server 2008

File name	Ia64_de074ca5c22f223d9f178e1cc6bcb00f_31bf3856ad364e35_6.0.6002.22739_none_44a8eafc385578c3.manifest
File version	Not applicable
File size	1,044
Date (UTC)	07-Nov-2011
Time (UTC)	12:24
File name	Ia64_microsoft-windows-crypt32-dll_31bf3856ad364e35_6.0.6002.22739_none_5dca1870f425e305.manifest
File version	Not applicable
File size	7,243
Date (UTC)	06-Nov-2011
Time (UTC)	18:03

Need more help?

Источник

Here is our infrastructure:

Offline root — Server 2012 Standard
Intermediate CA that issues certificates — Server 2012 Standard
PKI server (CDP and AIA over http url) — Server 2012 Standard

Here is the URL configuration for CDP and AIA:

CDP: http://pki.domain.org/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
AIA: http://pki.domain.org/<ServerDNSName>_<CaName><CertificateName>.crt

CRL has 180 day validity period and is generally renewed every 5 months from the offline root CA

I am trying to set up Hyper-V replication over HTTPS so I published a certificate and everything seems fine up to the point where I hit the apply button in the Hyper-V console and it comes up with the error in the following image (thumbprint removed just
cuz).

Not sure if this is relevant but I am running Hyper-V Server 2012 but also recreated this issue on Server 2012 R2 Datacenter. I have run the tests described in the following paragraph on both servers and both had the same results.

I might add that If I choose a cert from a previously set up 2008 R2 Standard CA Root/issuing server (remnants from previous admin) that is used for Client and Server Authentication, I do not receive this error although I am not familiar with how that previous
setup was accomplished except that it is a standalone.

I have gone back and forth with different certutil commands (such as urlfetch, user urlfetch, and url retrieval tool) and the results are always successful and always says that leaf certificate revocation check passed. I have even run this as SYSTEM and
NETWORKSERVICE accounts and always seem to have successful results. I do not want to use the workaround of bypassing the CRL check for fear that there is a greater underlying problem. I have recently created a new CRL from the offline root and copied to the
CDP and AIA directory so the CRL should not be expired (nor were expiration errors reported). I will admit that I’m novice at certificate authority management so please excuse my ignorance. Please let me know if there is any more information needed or correct
me if I misspoke in any part. Thank you in advance for your time!

Edited by

Monday, February 17, 2014 8:51 PM

Источник

ReAlex	#1 Оставлено : 7 февраля 2023 г. 11:36:38(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 07.02.2023(UTC) Сообщений: 15	Добрый день. Столкнулся с проблемой при работе с ФГИС Зерно, они помочь не смогли или не захотели. Изначально имеем (на момент возникновения проблемы) Windows 10 21H2.1, КриптоПро 4, версия плагина — предпоследняя. Firefox 91. Полноценная работа в системах: СБИС Меркурий Честный Знак ФГИС Зерно — только начинаем осваивать. Успешно подписали один пробный документ в Зерне, через несколько минут пробуем подписать второй — получаем ошибку Цитата: Невозможно использовать сертификат для электронной подписи документов: Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен. (0x80092013) В процессе общения с техподдержкой обновили КриптоПро до последней сертифицированной версии и плагин до последней версии. Ну, обновили и обновили. Ничего плохого. Проблема не ушла. В трех других сервисах, требующих ЭЦП, работа продолжается без проблем. Куда копать?

nickm	#2 Оставлено : 7 февраля 2023 г. 11:43:58(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 31.05.2016(UTC) Сообщений: 797 Сказал(а) «Спасибо»: 237 раз Поблагодарили: 129 раз в 119 постах	Автор: ReAlex через несколько минут пробуем подписать второй — получаем ошибку Цитата: Невозможно использовать сертификат для электронной подписи документов: Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен. (0x80092013) А в самом сертификате подобных свойств не имеется ли? Например: Код: `[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`

ReAlex	#3 Оставлено : 7 февраля 2023 г. 12:07:53(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 07.02.2023(UTC) Сообщений: 15	Имеется. Скачал по указанному адресу список отзывов, установил его, ничего не изменилось. Это мы еще с техподдержкой Зерна сделали.

nickm	#4 Оставлено : 7 февраля 2023 г. 12:32:35(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 31.05.2016(UTC) Сообщений: 797 Сказал(а) «Спасибо»: 237 раз Поблагодарили: 129 раз в 119 постах	Автор: ReAlex Имеется Если имеется ссылка на «OCSP», то доступ по указанном пути должен осуществляться: https://ru.errorcode.pro/CRYPT_E_REVOCATION_OFFLINE Код: `#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.` Проверьте, открывается ли у Вас ссылка до «OCSP»?

ReAlex	#5 Оставлено : 7 февраля 2023 г. 13:16:41(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 07.02.2023(UTC) Сообщений: 15	В браузере открывается. Файлик скачивается. Остается выяснить, кому, кроме браузера, надо дать доступ к этому ресурсу. Службе SSTP? Какому-то модулю КриптоПро?

nickm	#6 Оставлено : 7 февраля 2023 г. 13:19:04(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 31.05.2016(UTC) Сообщений: 797 Сказал(а) «Спасибо»: 237 раз Поблагодарили: 129 раз в 119 постах	Автор: ReAlex В браузере открывается. Файлик скачивается. Остается выяснить, кому, кроме браузера, надо дать доступ к этому ресурсу У Вас имеется прокси/ VPN?

ReAlex	#7 Оставлено : 7 февраля 2023 г. 13:20:32(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 07.02.2023(UTC) Сообщений: 15	Ну и остается вопрос, почему у ФГИС Зерно на этом месте возникает затык, а у СБИС, Меркурия и Честного Знака все нормально.

ReAlex	#8 Оставлено : 7 февраля 2023 г. 13:21:23(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 07.02.2023(UTC) Сообщений: 15	Автор: nickm Автор: ReAlex В браузере открывается. Файлик скачивается. Остается выяснить, кому, кроме браузера, надо дать доступ к этому ресурсу У Вас имеется прокси/ VPN? Да, браузер настроен на классический веб-прокси.

nickm	#9 Оставлено : 7 февраля 2023 г. 13:44:12(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 31.05.2016(UTC) Сообщений: 797 Сказал(а) «Спасибо»: 237 раз Поблагодарили: 129 раз в 119 постах	Автор: ReAlex Ну и остается вопрос, почему у ФГИС Зерно на этом месте возникает затык, а у СБИС, Меркурия и Честного Знака все нормально. Сказать трудно, т.к. Вы не привели какой либо значимой информации и всё, что на данный момент стало известно — это лишь после того, как эту информацию вытянули из Вас. Возможно, Ваш прокси администрируется и на нём имеются необходимые разрешающие правила, а каких-то наоборот не имеется. Раз Вы работаете в организации, то такие вопросы, скорее, уместно задавать администраторам сервисов, в том числе и прокси.

ReAlex	#10 Оставлено : 7 февраля 2023 г. 13:47:52(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 07.02.2023(UTC) Сообщений: 15	Автор: nickm Автор: ReAlex Ну и остается вопрос, почему у ФГИС Зерно на этом месте возникает затык, а у СБИС, Меркурия и Честного Знака все нормально. Сказать трудно, т.к. Вы не привели какой либо значимой информации и всё, что на данный момент стало известно — это лишь после того, как эту информацию вытянули из Вас. Возможно, Ваш прокси администрируется и на нём имеются необходимые разрешающие правила, а каких-то наоборот не имеется. Раз Вы работаете в организации, то такие вопросы, скорее, уместно задавать администраторам сервисов, в том числе и прокси. Все правильно. Но администратору надо знать, какой именно службе или программе не хватает доступа к ресурсу OCSP.

Пользователи, просматривающие эту тему

Guest

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

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

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

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

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

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

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

Источник

After several installations and Skype for Business 2015 (S4B) Server upgrades, a colleague of mine pushed my attention to a large ammount of event id 4097 warnings on the Administrative Events view related to Windows Fabric. The rate if this flood could be 3-5 events every 5-15 minutes:
– “cert chain trust status is in error: 0x1000040”
– “ignore error 0x80092013:certificate revocation list offline”
You can check all those events on the specific Windows Fabric log shown on the below picture.

Question: Why and where do this event come from?

S4B installs Windows Fabric 3.0 and added, between others, additonal securitys setting in the fabric intracluster communications. You can find this settings on several configuration files:
%PROGRAMDATA%Windows FabricFabricHostSettings.xml
%PROGRAMDATA%Windows Fabric<FEserverFQDN>FabricClusterManifest.current.xml
%PROGRAMDATA%Windows Fabric<FEserverFQDN>FabricFabric.DataInfrastructureManifest.xml”
%PROGRAMDATA%Windows Fabric<FEserverFQDN>FabricFabric.Config.<version>Settings.xml”

The relevant settings related to the events can be found on the ‘Security’ section:

The IgnoreCrlOfflineError is self-explanatory: If Windows Fabric encounters this error, ignore it and continue operations. For the CrlCheckingFlag values we need to look a little ‘deeper’. The Windows Fabric configuration files are generated by the Front-End server (RTCSRV / RtcHost module) at service startup based on this template file:
<S4B installation folder>ServerCoreClusterManifest.Xml.Template

On this file you will find a little more about the flags value:
      <!–
        CrlCheckingFlag setting follows the rest of the Lync Server components (sipstack, web) which set the following flags:
               CERT_CHAIN_CACHE_ONLY_URL_RETRIEVAL=0x00000004 | // do not go on the wire for cert retrieval
               CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY=0x80000000 | // do not go on the wire for cert revocation check
               CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT=0x40000000
                                                              0xC0000004=3221225476 (unsigned int)
      –>
      <Parameter Name=”CrlCheckingFlag” Value=”%CRLCHECKINGFLAG%” />

More information regardind the flags can be found on MSDN CertGetCertificateChain function.
Basically, S4B services (including the Fabric) are configured to check certificates revocation (CRL) using local cache only, as the comments on the template says: do not go on the network to retrieve and check the CRL.

So… how does it check for a certificate revocation?
Running a trace on the Fabric process, we can see that it never tries to connect to a CRL distribution server but, a little before the events are logged, it reads the registry keys related to certificates.

Since there are no cached or local CRL available, it will report an CRL offline error, ignore it, but still write it on the event log.

Do the other Skype for Business services report this error? No, it’s hidden. They cause the same issue but, to see it, you need to enable CAPI2 logging:

Question: What can we do about this ?

I can see at least 3 options:

Option A (The ‘no worries’ one) – Ignore it!
Difficult level: noob
Advantages: Nothing to be done. It’s a normal S4B operation and nothing is affected
Disadvantages: Your administrative events view will be full of these events which makes difficult to find important warning

Option B (The ‘clean’ one) – provide the CRL to the local server
Difficult level: professional services
Advantages: You will not just stop seeing the Fabric events, but it will also optimize all the other S4B services
Disadvantages: Requires knowledge and script programming, since you want to schedule a task to get the CRL and put it on the machine certificate local store.

This option also proves how the CRL caching / ignoreofflineCRL works.
Instructions:
1. Find the certificate name used by Windows Fabric. You can get this from the Fabric configuration files (spoiler alert: it’s the same used by Lync internal services)
2. Find on the certificate the Distribution paths where to get the CRL

3. Download the CRL and install it on the Trust Root CA or Intermediate CA store depending if the certificate was issue by a Root or a Subordinate CA

As soon as you upload the CRL to the local computer certificate store, you will see that the Fabric process will read the CRL from the store.

… and no more 4097 events !

As you noticed, the CRL are updated regularly (daily or weekly) so they have an expiration and need to be retrieved. This means that doing this manually is a error-prune, time-comsuming task, which you can solve with a scheduled script (not included on this blog… yet!)

Option C (The ‘tweak’ one) – manipulate the CrlCheckingFlag
Difficult level: moderate: just need to know what you are doing
Advantages: It’s easiest way to stop seeing the Fabric events
Disadvantages: It’s a S4B undocumented parameter customization (altough I don’t believe MS will not refuse support if they found out). It can also be overwritten by an update.

This ‘quick fix’ option is about manipulating the file
‘<S4B installation folder>ServerCoreClusterManifest.Xml.Template’

Intructions:
1. Change the parameter of the ClusterManifests.Xml.Template
<Parameter Name=”CrlCheckingFlag” Value=”0″ />
2. Stop the RTCSRV and FabricHostSvc services
3. Start the RTCSRV service – it will create new Fabric configuration files based on the template file and also start the FabricHostSvc

Actually, according to this blog, this parameter value is required if you issue certificates withouth any CRL Distribution Point information…. or your S4B pool will not start at all (!)
– Newly installed Skype for Business Front-End Pool refuses to start

Final notes:

If you want to know more about Windows Fabric and S4B we have a great and detailed explanation on this blog

Источник