Ошибка проверки конечного сертификата на отзыв

vlntn	#1 Оставлено : 16 января 2012 г. 18:33:15(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 22.11.2011(UTC) Сообщений: 11	Для проверки подписи используется функция библиотеки CAdES ‘CadesVerifyMessage’. Она возвращает ошибку CADES_VERIFY_END_CERT_REVOCATION (Ошибка проверки конечного сертификата на отзыв). При этом: — cертификат подписи помещен в хранилище My — cертификат УЦ помещен в хранилище Root — cписок отозванных сертификатов в хранилище СА пуст В чем может быть причина возникновения данной ошибки? Вот описание среды: 1. ОС Linux 2. Сертификат подписи помещен в хранилище My (как следует из документации, это стандартное хранилище для личных сертификатов). 3. Сертификат УЦ (КриптоПро) помещен в хранилище Root (как следует из документации, это стандартное хранилище для корневых сертификатов). 4. Список отозванных сертификатов в хранилище СА (как следует из документации, это стандартное хранилище, где должен быть этот список) пуст. 5. Функция библиотеки CAdES ‘CadesVerifyMessage’ возвращает ошибку CADES_VERIFY_END_CERT_REVOCATION (Ошибка проверки конечного сертификата на отзыв). Дополнительная информация 1. Если удалить сертификат УЦ (КриптоПро) из хранилища Root, то возвращается другая ошибка (CADES_VERIFY_NO_CHAIN, Не удалось построить цепочку для сертификата, на ключе которого подписано сообщение). 2. Если вместо функции CAdES ‘CadesVerifyMessage’ использовать функцию CAPILight ‘CryptVerifyMessageSignature’, то все OK. Заранее спасибо за советы…

rozhkov	#2 Оставлено : 16 января 2012 г. 19:22:46(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 25.01.2011(UTC) Сообщений: 589 Откуда: Крипто-Про	Проверьте правильность пути до библиотеки libcurl.so в /etc/opt/cprocsp/config.ini<config64.ini>

vlntn	#3 Оставлено : 16 января 2012 г. 21:02:33(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 22.11.2011(UTC) Сообщений: 11	rozhkov написал: Проверьте правильность пути до библиотеки libcurl.so в /etc/opt/cprocsp/config.ini<config64.ini> Спасибо за совет. В связи с этим два вопроса: 1) А если я хочу проверять отозванность сертификатов не по протоколу OCSP (т.е. удалённо на CA), а локально — путём проверки файла CRL. Как тогда надо настроить систему для такой проверки? И возможно ли это? 2) Библиотека libcurl.so (видимо для браузера curl) — это системная библиотека Linux или какая-то реализация от КриптоПро? Где её можно найти? Спасибо.

rozhkov	#4 Оставлено : 17 января 2012 г. 14:13:17(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 25.01.2011(UTC) Сообщений: 589 Откуда: Крипто-Про	1. Установить в хранилище CA актуальные СОС. 2. По поводу curl для начала http://ru.wikipedia.org/wiki/CURL а дальше что это думаю разберетесь, если не установлена, то из репозиториев для Вашей ОС установите.

vlntn	#5 Оставлено : 17 января 2012 г. 16:36:46(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 22.11.2011(UTC) Сообщений: 11	rozhkov написал: 1. Установить в хранилище CA актуальные СОС. 2. По поводу curl для начала http://ru.wikipedia.org/wiki/CURL а дальше что это думаю разберетесь, если не установлена, то из репозиториев для Вашей ОС установите. Огромное спасибо. А не подскажите ещё пару вещей 1 Как правильно установить актуальные СОС в хранилище Linux. И как сконфигурировать приложение, чтобы оно использовало именно СОС и не работало с OCSP? 2 У нас есть libcurl.so.3 и libcurl.so.0.0, но нет libcurl.so. Можно ли их использовать? 3 У нас Linux — виртуальная машина. Имеет ли это значение? Наверняка должен быть коннект к сайту с OCSP, может что ещё… Заранее спасибо.

cross	#6 Оставлено : 17 января 2012 г. 17:01:30(UTC)
Статус: Сотрудник Группы: Администраторы, Участники Зарегистрирован: 24.11.2009(UTC) Сообщений: 965 Откуда: Crypto-Pro Сказал(а) «Спасибо»: 3 раз Поблагодарили: 174 раз в 152 постах	1) СОС устанавливаются утилитой certmgr 2) Да можно. libcurl.so почти всегдаа является симлинком на саму библиотеку 3) Для проверки по OCSP нужен коннект к серверу OCSP. Для проверки по СОС нет. Лучше всего привести полный код проверки как с использованием CadesVerifyMessage так и с использованием CryptVerifyMessageSignature.
Техническую поддержку оказываем тут. Наша база знаний. Наша страничка в Instagram.

vlntn	#7 Оставлено : 18 января 2012 г. 19:13:05(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 22.11.2011(UTC) Сообщений: 11	cross написал: 1) СОС устанавливаются утилитой certmgr 2) Да можно. libcurl.so почти всегдаа является симлинком на саму библиотеку 3) Для проверки по OCSP нужен коннект к серверу OCSP. Для проверки по СОС нет. Лучше всего привести полный код проверки как с использованием CadesVerifyMessage так и с использованием CryptVerifyMessageSignature. Вопросы: >СОС устанавливаются утилитой certmgr Данной утилитой установить не получилось: /opt/cprocsp/bin/amd64/certmgr -inst -crl -store mCA -file <файл> Invalid data in file <файл> No CRL to install Файл CRL был скачан с тестового УЦ КриптоПро. Вопрос: В чем может быть причина? Получилось утилитой csptestf: /opt/cprocsp/bin/amd64/csptestf -ipsec -reg -list <файл> Registering… Store CA opened. Registering crl OK. После этого команда /opt/cprocsp/bin/amd64/certmgr -list -store mCA -crl дает следующий вывод: ============================================================================= 1——- Issuer : E=info@cryptopro.ru, C=RU, O=CRYPTO-PRO, CN=Test Center CRYPTO-PRO ThisUpdate: 06/01/2012 15:32:26 UTC NextUpdate: 14/01/2012 03:52:26 UTC ============================================================================= Вопрос: Правильно ли сформирован список (похоже ли это на то, что должно быть)? Из ответа: >Для проверки по OCSP нужен коннект к серверу OCSP. Для проверки по СОС нет. Вопросы: Как система узнает, какой способ проверки использовать? Надо ли как-то явно указывать системе, какой способ проверки использовать? Если да, то как?

vlntn	#8 Оставлено : 20 января 2012 г. 14:21:10(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 22.11.2011(UTC) Сообщений: 11	А вот, собственно, сам код. Может быть кто-то подскажет, что в нём не так или упущено… CRYPT_VERIFY_MESSAGE_PARA cryptVerifyParams; cryptVerifyParams.cbSize = sizeof(CRYPT_VERIFY_MESSAGE_PARA); cryptVerifyParams.dwMsgAndCertEncodingType = X509_ASN_ENCODING | PKCS_7_ASN_ENCODING; cryptVerifyParams.hCryptProv = 0; cryptVerifyParams.pfnGetSignerCertificate = NULL; cryptVerifyParams.pvGetArg = NULL; CADES_VERIFICATION_PARA cadesVerifyParams; cadesVerifyParams.dwSize = sizeof(CADES_VERIFICATION_PARA); cadesVerifyParams.dwCadesType = CADES_BES; cadesVerifyParams.pMessageContentHash = NULL; cadesVerifyParams.pProxyPara = NULL; cadesVerifyParams.hStore = NULL; cadesVerifyParams.bReserved2 = FALSE; cadesVerifyParams.pReserved3 = NULL; CADES_VERIFY_MESSAGE_PARA params; params.dwSize = sizeof(CADES_VERIFY_MESSAGE_PARA); params.pVerifyMessagePara = &cryptVerifyParams; params.pCadesVerifyPara = &cadesVerifyParams; DWORD nStat = CADES_VERIFY_SUCCESS; CADES_VERIFICATION_INFO* pInfo = NULL; #ifdef CAPILITE if(!::CryptVerifyMessageSignature(pParams->pVerifyMessagePara, nIdx, pSignedMsg, nLen, NULL, 0, NULL)) nStat = -1; #else if(!::CadesVerifyMessage(pParams, nIdx, pSignedMsg, nLen, NULL, &pInfo)) nStat = -1; #endif if(pInfo != NULL) { nStat = pInfo->dwStatus; ::CadesFreeVerificationInfo(pInfo); } if(nStat == (DWORD)-1) setSysErrMsg(); else setCadesErrMsg(nStat);

vlntn	#9 Оставлено : 24 января 2012 г. 14:53:34(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 22.11.2011(UTC) Сообщений: 11	Обнаружил, что происходит запись в системный лог: libcspr[24780]: capi20:!CryptRetrieveObjectByUrlA!() UrlRetriever failed (CURLcode: 0).! Эта ошибка не зависит от наличия или отсутствия сертификата, которым подписывается сообщение, в хранилище. Кто-нибудь может подсказать, что это означает?

BIM	#10 Оставлено : 10 мая 2012 г. 17:48:08(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 03.05.2012(UTC) Сообщений: 12 Откуда: Владимир	vlntn написал: >СОС устанавливаются утилитой certmgr Данной утилитой установить не получилось: /opt/cprocsp/bin/amd64/certmgr -inst -crl -store mCA -file <файл> Invalid data in file <файл> No CRL to install Файл CRL был скачан с тестового УЦ КриптоПро. Вопрос: В чем может быть причина? Аналогичная проблема. CSP 3.6, Ubuntu на /opt/cprocsp/bin/amd64/csptestf -ipsec -reg -list <файл> выдает: CSP (Type:71) v3.6.5359 KC1 Release Ver:3.6.6497 OS:Linux CPU:IA32 FastCode:READY,ENABLED. CSP (Type:75) v3.6.5359 KC1 Release Ver:3.6.6497 OS:Linux CPU:IA32 FastCode:READY,ENABLED. Registering… Restoration of crl FAILED! Registering crl FAILED! Total: [ErrorCode: 0x00000001] Помогите решить проблему.

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

Guest

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

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

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

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

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

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

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

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

Как открыть “Инструменты КриптоПро” на компьютере c Windows?

Воспользуйтесь этой инструкцией, если возникли проблемы с запуском программы.

• Перейдите во вкладку «Контейнеры».
• Затем в окне выберите контейнер закрытого ключа ЭЦП, который необходимо проверить.
• Нажмите кнопку «Протестировать контейнер».

Окно программы «Инструменты КриптоПро» с открытой вкладкой «Контейнеры»

После этого в течение 1 минуты откроется окно с информацией о результатах тестирования контейнера ЭЦП. Если ошибок в контейнере закрытого ключа ЭЦП не будет обнаружено, то в заголовке окна будет написано «Тестирование контейнера завершилось успехом», как на скриншоте ниже.

Окно программы «Инструменты КриптоПро» с успешными результатами тестирования контейнера ЭЦП

Если же при тестировании ЭЦП возникли ошибки, то появится информация об ошибках, которая будет подсвечена красным цветом, как например, на скриншоте ниже. В этом случае появление окна с результатами тестирования может занять больше времени.

Ошибка “Сертификат не действителен. Цепочка сертификатов обработана, но обработка прервана на корневом сертификате, у которого отсутствует отношение доверия с поставщиком доверия.”

Как исправить ошибку “0x800B010E: Процесс отмены не может быть продолжен – проверка сертификатов недоступна”?

Окно программы «Инструменты КриптоПро» с ошибкой при тестировании контейнера ЭЦП

В нашем случае возникла ошибка при проверке цепочки сертификатов «0x80092013: Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен.» Такая ошибка часто встречается при высокой нагрузке на сервера удостоверяющих центров, которые присутствуют в цепочке сертификатов ЭЦП. Поэтому спустя 15 секунд после неудачного тестирования, при повторном запуске теста ошибок обнаружено не было.

Получилось ли у вас протестировать контейнер ЭЦП? С какими ошибками вы столкнулись при тестировании?

Расскажите в комментариях 😉

Ошибка центра сертификации

Эта ошибка возникает из-за невозможности проверки путей AIA или CDP. То есть подчиненный центр не смог их найти, пути можно увидеть как часть сертификата подчиненного ЦС. Размещение файлов CRL и корневого сертификата по этим путям устранит эту ошибку.До сих пор нет правильного способа полностью отключить проверку отзыва сертификатов. Это также исправит вашу ошибку. Откройте командную строку и введитеcertutil -setreg ca CRLFlags + CRLF_REVCHECK_IGNORE_OFFLINE

Алексей Игнатьев/ автор статьиСпециалист и эксперт zhivye-oboi-windows.ru — профессиональный консультант, системный администратор. Опыт работы в этой сфере 7 лет.

Произошла небольшая неприятность на работе. Ноутбук, на котором настроено рабочее место для ЕГИССО срочно понадобилось отдать на время другому пользователю. «Ничего страшного» — подумал я, — «настрою портал на другом компьютере, благо как настраивать давно уже известно».

Но после того как все необходимые компоненты были установлены, средство для работы с электронной подписью CryptoDE начало капризничать и никак не хотело подписывать документы. Постоянно выскакивающее окно сообщало: «Ни один из сертификатов в хранилище не прошел проверку на квалифицированность в соответствии с настройками». Чтобы избавиться от этой ошибки, понадобилось немного поковыряться в настройках программы. В данной статье речь пойдет о том, как провести настройку CryptoDE для ЕГИССО.

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

«Админы делятся на тех, кто не делает бэкапы, и тех, кто уже делает». Народная мудрость.

при попытке подключения к серверу Windows 2008 R2 по SSTP постоянная ошибка“Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен .”
По умолчанию для VPN-подключений по протоколу SSTP клиенты должны проверить, что сертификат не отозван.
Для этого проверяется сервер, указанный в сертификате как сервер, на котором размещается список отзыва сертификатов (CRL).
Если с сервером, на котором размещается список отзыва сертификатов, не удается связаться, проверка завершается с ошибкой,
а VPN-подключение отбрасывается. Чтобы предотвратить это, следует опубликовать список отзыва сертификатов на сервере,
доступном через Интернет, или отменить обязательную проверку этого списка на клиенте. Чтобы отменить проверку списка отзыва сертификатов,
удалите параметр реестра в следующем расположении:Этот параметр имеет значение типа DWORD с именем NoCertRevocationCheck. Присвойте параметру значение 1.файлик можно взять у метя тут sstp_no_CRLпосле изменения реестра компьютер нужно перезагрузить, ошибка исчезнет.

Ситуация следующая. Имеются два центра сертификации (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

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

Настройка CryptoDE для ЕГИССО

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

• Нажимаем правой кнопкой мыши на значок Crypto+DE в трее и переходим в раздел «Настройки»
• Во вкладке «Настройки клиента» все значения оставляем по умолчанию.
• Нас интересует вкладка «Криптосервер 3». «Какие сертификаты проверять» выставляем значение «Только конечный сертификат»«Режим проверки» выставляем значение «С помощью списка отзыва сертификатов с подключением к сети»«Режим проверки квалифицированной ЭП» ставим «Не проверять»
• «Какие сертификаты проверять» выставляем значение «Только конечный сертификат»
• «Режим проверки» выставляем значение «С помощью списка отзыва сертификатов с подключением к сети»
• «Режим проверки квалифицированной ЭП» ставим «Не проверять»
• Все остальные значения я оставил по умолчанию. Не забываем нажать «Ок», чтобы все изменения вступили в силу.

Где скачать Crypto+DE

• С официального сайта ПФР ()
• Яндекс Диск ()

Ошибка

Если правой кнопкой мыши нажать на значок Crypto+DE, а затем «Выбрать сертификат по умолчанию», то программа успешно предложит выбрать сертификат из установленных сертификатов. Но это действие ничего не решит, т.к. при подписании документа выскочило окно, которое оповещает о том, что сертификат по умолчанию не соответствует требованиям текущего режима КЭП.

Итог

На этом настройка CryptoDE завершена. Все документы успешно подписываются и загружаются на портал в кабинете поставщика информации. Оставлю на всякий случай скриншот настроек, которые действуют у меня в данный момент. Если у Вас не заработало или что-то не получилось, можете смело написать в комментариях. Постараюсь всем помочь!

Остались вопросы? Помогу, чем смогу!

Ошибка центра сертификации

Специалист и эксперт zhivye-oboi-windows.ru — профессиональный консультант, системный администратор. Опыт работы в этой сфере 7 лет.

older21	#1 Оставлено : 28 мая 2019 г. 14:57:11(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 10.09.2012(UTC) Сообщений: 15 Откуда: Москва Сказал(а) «Спасибо»: 2 раз	Добрый день! Сервис КриптоПро SVS 2.0.1917 без доступа в Интернет. При проверке сертификата возвращается ошибка: The revocation function was unable to check revocation for the certificate При проверке подписи документов возвращается ошибка: Не удалось проверить подпись CAdES-BES. Ошибка: [The revocation process could not continue — the certificate(s) could not be checked]. Код: [0x800b010e].Ошибка проверки сертификата цепочки на отзыв. Хранилище корневых сертификатов: verify-TSL Утилитой DssTslTool загрузил списки отзыва — запустил на машине с выходом в Инет с параметрами: DSS.TslTool.exe —downloadcrlonly —skipcerts —skiproot И затем перенес на машину с SVS и запустил утилиту с параметрами: DSS.TslTool.exe -s verify-TSL —crlfromfolder C:DssTslTooltmp —tslfile C:DssTslTooltmptsl.xml Результат работы утилиты: В каталоге [C:DssTslTooltmp] найдено 1302 CRL Завершено успешно. Сервис SVS настроен на локальную проверку CRL: Имя хранилища сертификатов verify-TSL Режим проверки на отзыв Offline проверка на отзыв. Проверка на отзыв цепочики Проверять только конечный сертификат Несмотря на это, проверка сертификатов и подписей не проходит. Подскажите, что еще нужно настроить? Спасибо! Отредактировано пользователем 30 мая 2019 г. 14:21:39(UTC)  | Причина: Не указана

Грибанов Антон	#2 Оставлено : 30 мая 2019 г. 14:10:33(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 25.06.2014(UTC) Сообщений: 409 Сказал(а) «Спасибо»: 1 раз Поблагодарили: 48 раз в 48 постах	Добрый день. Для настройки работы через proxy рекомендуется воспользоваться следующей статьёй: https://docs.microsoft.c…element-network-settings
Техническую поддержку оказываем тут Наша база знаний

older21	#3 Оставлено : 30 мая 2019 г. 16:53:07(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 10.09.2012(UTC) Сообщений: 15 Откуда: Москва Сказал(а) «Спасибо»: 2 раз	Автор: Грибанов Антон Добрый день. Для настройки работы через proxy рекомендуется воспользоваться следующей статьёй: https://docs.microsoft.c…element-network-settings В файл конфигурации C:Program FilesCrypto ProDSSVerificationServiceWeb.config добавил блок (ххх.ххх.ххх.ххх:ррр — адрес и порт нашей прокси): <system.net> <defaultProxy> <proxy usesystemdefault=»true» proxyaddress=»http://ххх.ххх.ххх.ххх:ррр» bypassonlocal=»true» /> <bypasslist> <add address=»[a-z]+.contoso.com$» /> </bypasslist> </defaultProxy> </system.net> Перезапустил сервис, его поведение не изменилось.

older21	#4 Оставлено : 31 мая 2019 г. 11:35:22(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 10.09.2012(UTC) Сообщений: 15 Откуда: Москва Сказал(а) «Спасибо»: 2 раз	Уточнение — проверка подписи документа начала проходить. А проверка сертификата на валидность — так и не работает, с той же ошибкой.

Грибанов Антон	#5 Оставлено : 31 мая 2019 г. 14:43:49(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 25.06.2014(UTC) Сообщений: 409 Сказал(а) «Спасибо»: 1 раз Поблагодарили: 48 раз в 48 постах	1.Желательно обновиться до актуальной версии SVS: https://cryptopro.ru/products/pki/verify/downloads 2.Пришлите вывод команд: Get-VsEndpoint Get-VsProperties
Техническую поддержку оказываем тут Наша база знаний
1 пользователь поблагодарил Грибанов Антон за этот пост.	older21 оставлено 06.06.2019(UTC)

older21	#6 Оставлено : 6 июня 2019 г. 9:43:09(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 10.09.2012(UTC) Сообщений: 15 Откуда: Москва Сказал(а) «Спасибо»: 2 раз	Автор: Грибанов Антон 1.Желательно обновиться до актуальной версии SVS: https://cryptopro.ru/products/pki/verify/downloads Обновил и SVS и DSSTool, проверка сертификатов заработала. Спасибо!!! Отредактировано пользователем 6 июня 2019 г. 10:09:44(UTC)  | Причина: Не указана

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

Guest

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

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

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

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

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

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

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

Ситуация следующая. Имеются два центра сертификации (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

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

Добрый день уважаемые читатели, сегодня хочу рассказать как решается вот такая ошибка Службы сертификации 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

Ситуация следующая. Имеются два центра сертификации (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

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

Источник

Криптопро код ошибки 0x80092013

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

Ошибка центра сертификации

Ошибка Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен . 0x80092013 (-2146885613) при запуске центра сертификации в Windows Server 2008 R2

Данная ошибка выскакивает так как не удается проверить пути AIA или CDP. То есть подчиненный центр их не смог отыскать, посмотреть пути можно в составе сертификата вашего подчиненного CA. Положив по этим путям файлы CRL и корневого сертификата вы устраните эту ошибку.

Есть еще не правильный путь это полностью отключить проверку на отзыв сертификата. Что тоже устранит вашу ошибку. Открываете командную строку и пишите

Вот так вот просто решается Ошибка Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен . 0x80092013 (-2146885613) при запуске центра сертификации в Windows Server 2008 R2.

Источник

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

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, SP n), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table.

Источник

Сервер отзыва сертификатов недоступен ошибка 0x80092013 (-2146885613)

Сервер отзыва сертификатов недоступен ошибка 0x80092013 (-2146885613)

Добрый день уважаемые читатели, сегодня хочу рассказать как решается вот такая ошибка Службы сертификации 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, но все зависит от свободного времени.

Сетевые заметки системного администратора

при попытке подключения к серверу Windows 2008 R2 по SSTP постоянная ошибка

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

По умолчанию для VPN-подключений по протоколу SSTP клиенты должны проверить, что сертификат не отозван.
Для этого проверяется сервер, указанный в сертификате как сервер, на котором размещается список отзыва сертификатов (CRL).
Если с сервером, на котором размещается список отзыва сертификатов, не удается связаться, проверка завершается с ошибкой,
а VPN-подключение отбрасывается. Чтобы предотвратить это, следует опубликовать список отзыва сертификатов на сервере,
доступном через Интернет, или отменить обязательную проверку этого списка на клиенте. Чтобы отменить проверку списка отзыва сертификатов,
удалите параметр реестра в следующем расположении:

7Кб), всё проходит хорошо: сервер возвращает xml с информацией о том, что всё ок.
5) А вот если файл длиной больше 7Кб, то при получении ответа от сервера падает Exception:

A call to SSPI failed, see inner exception; The message received was unexpected or badly formatted.

Проверял на разных машинах, из разных мест. Проблема точно не в канале связи.
Но есть пара непонятных для меня моментов:
1) При валидации сертификата сервера не находится корневой сертификат. В ValidateServerCertificate:

chain.ChainStatus==PartialChain Не удается построить цепочку сертификатов для доверенного корневого центра.
; RevocationStatusUnknown Функция отзыва не смогла произвести проверку отзыва для сертификата.
; OfflineRevocation Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен .

2) После установки соединения в SslStream.LocalCertificate == null, хотя стрим создаётся с передачей userCertificateSelectionCallback:

и в методе ClientCertificateSelectionCallback локальный сертификат находится и проставляется куда следует.

Ребята, спасайте. Несколько дней бьюсь, куда копать — не ясно. С SSL раньше дела не имел, поэтому мог ошибиться где-то в элементарных вещах.

Купили сертификат для домена, загрузили в сервер Exchange 2016. А сервер пишет:

Не удалось проверить отзыв

Пример загрузки PFX сертификата Fabrikam.pfx с паролем «P@ssw0rd1»:

Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes('\FileServer01DataFabrikam.pfx')) -Password (ConvertTo-SecureString -String 'P@ssw0rd1' -AsPlainText -Force)

https://docs.microsoft.com/ru-ru/exchange/architecture/client-access/import-certificates?view=exchserver-2016

Почему это произошло?

Такая ошибка произошла потому, что Exchange сервер не имеет доступ в Интернет и не может проверить состояние сертификата, отозван он или нет.

Что делать?

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

Во-вторых, можно дать серверу Exchange доступ в Интернет. Тогда Exchange сможет проверить списки отзыва. Но иногда нет возможности дать серверу доступ в Интернет, можно только открыть доступ к конкретным доменам. Для этого требуется определить, куда Exchange полезет, чтобы проверить отзыв сертификата.

CRL и OCSP

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

CRL и OCSP — это 2 модели, которые могут использоваться для проверки сертификата на предмет его отзыва.

Модель CRL используется с самого начала существования PKI и работает так. Сервер CA при отзыве сертификата помещает о нём запись в специальный файл CRL. При этом туда помещается серийный номер сертификата, дата отзыва и причина отзыва. Клиенты при проверки сертификатов скачивают эти CRL и проверяют есть ли серийный номер этого сертификата в CRL.

В OCSP используется немного иной принцип. Клиент OCSP отправляет на сервер OCSP Responder специальный запрос, в котором содержится серийный номер проверяемого сертификата. OCSP Responder отвечает клиенту откликом: отозван или не отозван.

Оба метода могут использоваться одновременно. Exchange не успокоится, пока не проверит их оба. Наша задача: найти все домены (ссылки) CRL и OCSP нашего сертификата и добавить их в Firewall, чтобы разрешить к ним доступ серверу Exchange. Точнее даже не сертификата, а цепочки сертификатов.

Открываем наш сертификат на просмотр. Я использую формат CRT.

Проверяем, что это именно тот сертификат, который нам нужен. Он действителен. Выдан RapidaSSL. Переключаемся на вкладку «Путь сертификации».

Корневой центр сертификации DigiCert. Но нам нужен промежуточный, тот что нам выдал сертификат (если их несколько, то понадобятся все). Выбираем его. Просмотр сертификата.

Переходим на вкладку «Состав» и выбираем «Доступ к информации о центрах сертификации». И видим протокол определения состояния сертификата через сеть, где указано дополнительное имя OCSP, в данном случае:

• http://ocsp.digicert.com

Разрешаем туда доступ серверу Exchange.

Выбираем «Точки распространения списков отзыва (CRL)». И видим все пути к CRL, у меня это:

• http://crl3.digicert.com/DigiCertGlobalRootCA.crl
• http://cr4.digicert.com/DigiCertGlobalRootCA.crl

Разрешаем туда доступ серверу Exchange. Выполняем на сервере Exchange в командной строке:

certutil -urlcache ocsp delete 
certutil -urlcache crl delete

Перезагружаем сервер Exchange и отправляемся пить чай.

Теперь сертификат «Допустимый».

Чтобы решить эту проблему, пришлось немного покопаться в настройках программы.

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

Далее переходим во вкладку «Криптосервер 3» и в открывшемся окне «Какие сертификаты проверять» выбираем «Только конечный сертификат»

В «Режим проверки» подставляем значение

А

отмечаем чекбокс «Не проверять»

Остальное я оставила как было. Естественно, для вступления изменений в силу нужно не забыть кликнуть по кнопке ОК. В моем случае это решило проблему дальнейшей работы с сайтом ПФР.

При работе с online сервисами 1С и других разработчиков, где необходимо обращение к электронной подписи, пользователи часто сталкиваются с ошибками ее проверки. Что делать, если не удалось выполнить проверку отзыва сертификата 1С и какие еще возникают ошибки работы с ЭДО, разбираем подробно с вариантами решений.

Компании, у кого жестко настроена политика безопасности, чаще всего наблюдают сбои в работе с ЭП. Это из-за того, что постоянно очищается список имеющихся CRL на ПК или, наоборот, к ним не может достучаться криптография для проверки

Что вообще такое списки отзывов сертификатов

Certificate Revocation List или список отозванных сертификатов – это информация, предоставляемая удостоверяющими центрами о недействительных сертификатах, о тех, чей срок действия уже либо закончился, либо был прерван по различным обстоятельствам.

Ключи могут отзываться по различным причинам. Самые распространенные:

• компрометация ключа или истечение срока годности ЭП;
• неверно заполненные реквизиты в составе ключа;
• поменялся владелец компании или ресурса;
• если речь идет про ключи сайтов, сайт более недоступен, перестал работать.

Список отозванных сертификатов ключей электронных подписей имеет расширение CRL. Сокращенное наименование СОС. В некоторых кругах можно услышать также понятие — Список аннулированных сертификатов (САС).

В настоящий момент (процесс был запущен еще в далеком 2017 г.) все чаще прибегают к отказу от СОС в сторону Online Certificate Status Protocol (OCSP, Онлайн Протокол Состояния Сертификата).

Принципы работы списков отозванных сертификатов

Актуализирует и публикует списки отозванных сертификатов САС Certificate Authority (CA — центр сертификации), который данный сертификат и выпустил.

Предпосылки для отзыва сертификата

Причины, по которым требуется аннулировать сертификат:

Отправляет запрос на аннулирование/отзыв сертификат:

1. Владелец.
2. Директор компании.
3. ФНС может послать запрос, если обнаружит компрометацию ключа.

Ошибка работы с ЭДО в 1С. Сертификат не прошел проверку или отозван

Пользователи онлайн-сервисов 1С нередко спрашивают: почему только недавно все работало, а теперь программа пишет, что сертификат недействительный или не удалось проверить сертификат в списке отозванных. Почему же этот сертификат не удалось проверить? Ответ прост: потому что на ПК нет установленных актуальных СRL-сертификатов от удостоверяющих центров, которые бы «сказали», что сертификат все еще действителен.

Для того, чтобы установить списки отозванных необходимо выполнить следующие шаги:

1. Из своей 1С выгрузить открытую часть ключа сертификата. Для этого необходимо идти по цепочке таких действий:
   Администрирование → Обмен электронными документами → Настройка электронной подписи и шифрования → Найти необходимый сертификат и двойным щелчком его открыть → Сохранить в файл → Выбрать удобную папку и нажать ОК.
   Если сертификатов и организаций много, можно открыть Учетную запись ЭДО и выгрузить сертификат оттуда.
   
   
   
2. Перейдите в папку, куда скопировали открытую часть ключа из ПО 1С и откройте файл (он должен быть с расширением .cer).
3. После того, как файл откроется, на вкладке Состав необходимо найти пункт Точки распространения списков отзывов (раздел Показать → Только расширения).
   
4. После того, как нашли строку со списками, необходимо скопировать самую крайнюю ссылку, на конце которой стоит расширение .сrl.
   Будьте внимательны, ссылки могут быть на конце с разными расширениями.
   Копировать необходимо при помощи комбинации клавиш клавиатуры сtrl+с.

   Подключение 1С-ЭДО от официального партнера 1С. Комплект документов от 250 руб./мес.

   • Если по крайней не скачивается, проверьте весь ли путь скопировали.
   • Если после установки сертификата ничего не изменилось, попробуйте следующую ссылку (снизу вверх).
   • Ошибка воспроизвелась опять? Установите СОС по всей цепочке сертификации.
   • Если и после этих действий ошибка остается, скачайте списки отозванных сертификатов с официального сайта вашего удостоверяющего центра (там данные публикуются и обновляются ориентировочно раз в сутки).
   • Все еще сертификат недействителен? Проверьте валидность ключа на сайте госуслуг или иным способом. Обратитесь в УЦ за проверкой ключа.
   
5. Вставляем скопированную ссылку в браузер, скачиваем СОС и нажимаем Ввод (Enter).
   

   При прохождении по ссылке может выйти ошибка:

   

   В таком случае, как было указано ранее, можно попробовать скачать сертификат по другой ссылке из открытой части ключа ЭП.

   
   

   На сайте ФНС находятся также различные сертификаты, которые можно скачать и установить (от доверенных корневых до отозванных списков).

   
   
   

   Гарантия 6 мес. на услуги подключения и настройки ЭДО в 1С. Решаем любые задачи!

6. Находим наш скачанный файл и правой кнопкой мыши выбираем команду Установить списки отозванных.
   

   Откроется мастер импорта сертификатов, так называемый, помощник в установке сертификатов на компьютер.

   Нажимаем Далее → Автоматически выбирать хранилище на основе типа сертификата → Готово.

   
   
   

   Если выбирать пункт Поместить все сертификаты в следующие хранилища важно выбрать правильное хранилище, а именно: Промежуточные центры сертификации. И если активирована функция Показать физические хранилища указать Реестр (в зависимости от политики безопасности компании).

   
   

Если установка списков отозванных для личного сертификата не помогла, установите списки отзывов от других сертификатов из цепочки сертификации.

Удаленный узел не прошел проверку

Сообщение, которое также связано с корректной проверкой сертификатов.

С помощью операционной системы Windows платформа 1С:Предприятие проводит проверку сертификата средствами защищенного соединения TLS/SSL.

SSL (Secure Sockets Layer) — это протокол безопасности в Интернете, основанный на шифровании. Впервые он был разработан компанией Netscape в 1995 году с целью обеспечения конфиденциальности, аутентификации и целостности данных при общении через Интернет. SSL является предшественником современного шифрования TLS, используемого сегодня.

Веб-сайт, реализующий SSL/TLS, имеет в своем URL-адресе «HTTPS» вместо «HTTP». Протокол TLS (Transport Layer Security) основан на протоколе SSL. Безопасность транспортного уровня, или TLS, — это широко распространенный протокол безопасности, предназначенный для обеспечения конфиденциальности и безопасности данных при обмене данными через Интернет.

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

TLS был предложен IETF, международной организацией по стандартизации. Первая версия протокола была опубликована в 1999 году. Самая последняя версия TLS 1.3 — в 2018.

Итак, проблема, связанная с сообщением в конфигурации о том, что удаленный узел не прошел проверку связано с тем, что доступ в Интернет ограничен в общем или в частности только у пользователя, под которым запускается конфигурация и работает служба агент сервера 1С.

Наиболее распространенные причины:

Пути решения

Для начала необходимо разобраться с работой антивирусной программы и брандмауэром Windows. Далее перейти к настройкам прокси и хостов.

Прокси-сервер

Откройте панель управления от имени пользователя, под которым запущен и работает rphost → Свойства обозревателя (Свойства браузера) → Подключения → Настройка сети → снимите активированную галочку использования прокси-сервера, если оно не предусмотрено политикой безопасности. Если использование все-таки предусмотрено, укажите ресурс в качестве исключения.

Хост файл (host)

Расположен обычно по такому пути:

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

Постарались максимально доступно рассказать о наиболее частых ошибках, с которыми пользователи 1С могут столкнуться при работе в ЭДО, в т.ч. с применением сертификатов ключа проверки электронной подписи.