Форум КриптоПро
»
Средства криптографической защиты информации
»
КриптоПро ЭЦП (усовершенствованная ЭЦП)
»
Ошиь=бка проверки сертификата, при наличии сертификата УЦ в хранилище сертификатов доверенных ЦС
Статус: Новичок
Группы: Участники
Зарегистрирован: 08.09.2020(UTC) Сообщений: 5 Сказал(а) «Спасибо»: 2 раз
|
Добрый вечер! Столкнулся сегодня с очень неожиданной проблемой. При проверке сертификата через утилиту CSP имеем: сертификат действителен. На странице "Путь сертификации" тоже все отображается корректно (корневой сертификат есть, установлен в хранилище и действителен). При проверке в плагине выдает сообщение: Ошибка при проверке цепочки сертификатов. Возможно на компьютере не установлены сертификаты УЦ, выдавшего ваш сертификат. После того, как несколько раз убедился, что корневой сертификат УЦ (для разработки и тестов используем собственный УЦ) установлен в хранилище доверенных серификатов, снял лог ProcMon`ом. Он явно показывает, что плагин читает ветку реестра с доверенными сертификатами и считывает нужный нам сертификат УЦ, чтоб можно было построить цепочку. Резюмируя: у меня затык куда копать. Варианты есть, но все они затратны по времени, и не гарантируют, что наши заказчики не столкнутся с этой проблемой. Прошу помощи в решении проблемы. Или хотя бы направления в котором копать. П.С. Готов предоставить любую информацию, которая поможет решить проблему. Сейчас прилагаю тестовые сертификаты, на которых и обнаружилась эта проблема. TestCertificates.zip (2kb) загружен 5 раз(а).
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 05.07.2018(UTC) Сообщений: 467
Сказал(а) «Спасибо»: 43 раз Поблагодарили: 69 раз в 61 постах
|
Возможно ошибка возникает при попытке получить инфу о том отозван ли сертификат или нет (CRL или OCSP). Вы уверены, что ваш УЦ складывает CRL именно туда? Просто если проверяете цепочку не на стороне УЦ (а скорее всего так оно и есть), работать по идее ничего не будет (если флаги не поставить, например, утилита cryptcp.exe позволяет игнорировать CRL при проверке ЭП). Попробуйте просто утилитой cryptcp.exe проверить еще ЭП. Если и там не сработает, проблема скорее всего не в плагине. Snimok ehkrana 2021-07-15 232450.png (41kb) загружен 7 раз(а).Отредактировано пользователем 15 июля 2021 г. 23:34:21(UTC)
| Причина: Не указана |
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 05.07.2018(UTC) Сообщений: 467
Сказал(а) «Спасибо»: 43 раз Поблагодарили: 69 раз в 61 постах
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,685 Сказал «Спасибо»: 500 раз Поблагодарили: 2044 раз в 1585 постах
|
Автор: Юрий Волобуев Добрый вечер! Столкнулся сегодня с очень неожиданной проблемой. При проверке сертификата через утилиту CSP имеем: сертификат действителен. На странице "Путь сертификации" тоже все отображается корректно (корневой сертификат есть, установлен в хранилище и действителен). При проверке в плагине выдает сообщение: Ошибка при проверке цепочки сертификатов. Возможно на компьютере не установлены сертификаты УЦ, выдавшего ваш сертификат. После того, как несколько раз убедился, что корневой сертификат УЦ (для разработки и тестов используем собственный УЦ) установлен в хранилище доверенных серификатов, снял лог ProcMon`ом. Он явно показывает, что плагин читает ветку реестра с доверенными сертификатами и считывает нужный нам сертификат УЦ, чтоб можно было построить цепочку. Резюмируя: у меня затык куда копать. Варианты есть, но все они затратны по времени, и не гарантируют, что наши заказчики не столкнутся с этой проблемой. Прошу помощи в решении проблемы. Или хотя бы направления в котором копать. П.С. Готов предоставить любую информацию, которая поможет решить проблему. Сейчас прилагаю тестовые сертификаты, на которых и обнаружилась эта проблема. TestCertificates.zip (2kb) загружен 5 раз(а). Как тестирование делаете, тип подписи cades bes? |
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,685 Сказал «Спасибо»: 500 раз Поблагодарили: 2044 раз в 1585 постах
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 08.09.2020(UTC) Сообщений: 5 Сказал(а) «Спасибо»: 2 раз
|
Автор: Андрей * Да, ошибка точно такая же.
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 08.09.2020(UTC) Сообщений: 5 Сказал(а) «Спасибо»: 2 раз
|
Автор: Анатолий Колкочев Возможно ошибка возникает при попытке получить инфу о том отозван ли сертификат или нет (CRL или OCSP). Вы уверены, что ваш УЦ складывает CRL именно туда? Просто если проверяете цепочку не на стороне УЦ (а скорее всего так оно и есть), работать по идее ничего не будет (если флаги не поставить, например, утилита cryptcp.exe позволяет игнорировать CRL при проверке ЭП). Попробуйте просто утилитой cryptcp.exe проверить еще ЭП. Если и там не сработает, проблема скорее всего не в плагине. Snimok ehkrana 2021-07-15 232450.png (41kb) загружен 7 раз(а). Да,я тоже сначала грешил на пути к crl, проверил обычным експлорером: указанные там файлы при подключенном впн нормально качаются. Хотя по началу тоже грешил на то, что наши админы чего-то там с доступом при переводе на удаленку налажали. Но нет. По поводу cryptcp.exe пока не понял, я же пытаюсь пока просто проверить сертификат. П.С. Еще раз перепроверил, но похоже все таки наши админы накосячили. Т.е. такой файл есть и он качается, только это нифига не файл СОСа. Что там за формат еще придется разобраться, но это уже хоть что-то. Попытаюсь разобраться, по результатам отпишусь. Отредактировано пользователем 16 июля 2021 г. 2:49:41(UTC)
| Причина: Не указана
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,685 Сказал «Спасибо»: 500 раз Поблагодарили: 2044 раз в 1585 постах
|
Почему используете 2001 ГОСТ в клиентском сертификате? Почему в CDP протокол file, а не http? |
|
1 пользователь поблагодарил Андрей * за этот пост.
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 08.09.2020(UTC) Сообщений: 5 Сказал(а) «Спасибо»: 2 раз
|
Автор: Андрей * Почему используете 2001 ГОСТ в клиентском сертификате? Это тестовые сертификаты, используются нами для прогона юнит тестов. Есть и с 2001 ГОСТ, и с 2012. С 2012 ГОСТ те же самые проблемы. Автор: Андрей * Почему в CDP протокол file, а не http? Это критично? Если да, то буду разбираться, кто и почему так настроил. Отредактировано пользователем 16 июля 2021 г. 13:59:14(UTC)
| Причина: Не указана
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 05.07.2018(UTC) Сообщений: 467
Сказал(а) «Спасибо»: 43 раз Поблагодарили: 69 раз в 61 постах
|
Автор: Юрий Волобуев Это критично? Если да, то буду разбираться, кто и почему так настроил.
https://datatracker.ietf...rfc5280#section-4.2.1.13Это rfc 5280. Вас интересует пункт 4.2.1.13. Цитата:If the distributionPoint field contains a directoryName, the entry for that directoryName contains the current CRL for the associated reasons and the CRL is issued by the associated cRLIssuer. The CRL may be stored in either the certificateRevocationList or authorityRevocationList attribute. The CRL is to be obtained by the application from whatever directory server is locally configured. The protocol the application uses to access the directory (e.g., DAP or LDAP) is a local matter.
If the DistributionPointName contains a general name of type URI, the following semantics MUST be assumed: the URI is a pointer to the current CRL for the associated reasons and will be issued by the associated cRLIssuer. When the HTTP or FTP URI scheme is used, the URI MUST point to a single DER encoded CRL as specified in [RFC2585]. HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-crl in the content-type header field of the response. When the LDAP URI scheme [RFC4516] is used, the URI MUST include a <dn> field containing the distinguished name of the entry holding the CRL, MUST include a single <attrdesc> that contains an appropriate attribute description for the attribute that holds the CRL [RFC4523], and SHOULD include a <host> (e.g., <ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com? certificateRevocationList;binary>). Omitting the <host> (e.g., <ldap:///cn=CA,dc=example,dc=com?authorityRevocationList;binary>) has the effect of relying on whatever a priori knowledge the client might have to contact an appropriate server.
When present, DistributionPointName SHOULD include at least one LDAP or HTTP URI.
КриптоПро делали проверку скорее всего по RFC, возможно поэтому ваша схема не работает (но лучше все же дождаться ответа Андрея *) Отредактировано пользователем 16 июля 2021 г. 16:44:28(UTC)
| Причина: Не указана |
|
1 пользователь поблагодарил TolikTipaTut1 за этот пост.
|
|
|
Форум КриптоПро
»
Средства криптографической защиты информации
»
КриптоПро ЭЦП (усовершенствованная ЭЦП)
»
Ошиь=бка проверки сертификата, при наличии сертификата УЦ в хранилище сертификатов доверенных ЦС
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close