Здравствуйте.

Версия CSP 3.9.

При проверке подписи командой cryptcp -verify -errchain получаю результат "The certificate revocation status or one of the certificates in the certificate chain is unknown."

Curl в системе установлен. Сертификат удостоверяющего центра установлен в хранилище СА. В сертификате пользоватля CDP прописаны.

Заметил следующую закономерность: если в расширении в URL присутствуют скобки или пробелы (возможно, и другие знаки) – проверка статуса сертификата не удаётся.

Пример из сертификата, проходящего проверку:
[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://tax4.tensor.ru/certenroll/tensorca3.crl

Пример из сертификата, проверку не проходящего:
[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://tax4.tensor.ru/certenroll/tensorca3(2014).crl


Это одна часть вопроса.

Вторая часть: почему, если я вручную установлю CRL и сертификаты в локальные хранилища на сервере – проверка всё равно не проходит (судя по всему – локальные версии в расчёт не принимаются и cryptcp всё равно лезет онлайн)?

Заранее спасибо.

Отредактировано пользователем 6 октября 2014 г. 19:25:57(UTC)  | Причина: Форматирование текста

При проверке указываю только cryptcp -verify -errchain.
Сертификат УЦ является корневым.

Authority Information Access из сертификата пользователя:
[1]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://tax4.tensor.ru/tsp/tsp.srf
[2]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://tax4.tensor.ru/ocsp/ocsp.srf
[3]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://tax4.tensor.ru/certenroll/tensorca3(2014).crt
[4]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://tensor.ru/ca/tensorca3(2014).crt
[5]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://crl.tensor.ru/tax4/ca/tensorca3(2014).crt
[6]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://crl2.tensor.ru/tax4/ca/tensorca3(2014).crt
[7]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://crl3.tensor.ru/tax4/ca/tensorca3(2014).crt


Сертификат от этого же УЦ, проходящий проверку, содержит следующую информацию:
[1]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://tax4.tensor.ru/certenroll/tensorca3.crt
[2]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://tax4.tensor.ru/tsp/tsp.srf
[3]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://tax4.tensor.ru/ocsp/ocsp.srf
[4]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://tensor.ru/ca/tensorca3.crt


Разница, бросающаяся в глаза сразу – в названии файлов присутствуют скобки. Утилита certmgr с такими файлами работать не может (если только путь к файлу не заключить в кавычки).

Отредактировано пользователем 8 октября 2014 г. 13:06:12(UTC)  | Причина: Добавил информацию

Ставил и в корневое хранилище.


Устанавливал с сайта УЦ как по ссылке, указанной с сертификате пользователя, так и напрямую с сайта (через поиск).


Это проявляется очень просто: если скачать сертификат или СОС с сайта УЦ по тем ссылкам, которые даны в сертификате и сохранить под неизменными именами, то при установке как сертификата, так и СОС происходит ошибка из-за наличия в имени файла скобок.
Если файл переименовать (убрать скобки) или задавать путь к файлу в кавычках – всё устанавливается.

Да, я знаю как сделать так, чтобы операция установки сертификата прошла нормально при ручной установке.
Моя ремарка на счёт имени файла относилась к следующему: если в операционной системе существуют нюансы, влияющие на работоспособность программ в зависимости от наличия спецсимволов в пути к файлу (или в названии файла) – то, вполне вероятно, эти нюансы накладывают ограничения и на внутреннее устройство программ? То есть, если в сертификате указано имя файла, содержащее спецсимволы (почему в УЦ так поступают – вопрос другой) – вероятно это и является причиной сбоя при проверке сертификата, так как, судя по всему, файл скачивается во временную директорию и уже оттуда с ним производятся фоновые манипуляции, на которые я не могу никак повлиять, в отличие о ручных манипуляций.

Если сертификат или СОС не скачивается по технической причине – об этом есть соответствующее уведомление от curl. В случае же с «ненормальным» названием файла – в лог ничего не пишется (при стандартных настройках).

Да это и понятно, что в УЦ накосячили. Как понятно и то, что исправлять они ничего не станут.
При чём – такое положение дел встречается не так уж и редко, даже в УЦ, которые давно на рынке и, по идее, должны знать все нюансы. За последних пару месяцев я столкнулся с этой ситуацией уже неоднократно...


ОК. Мне нужно решить проблему пользователя (я обслуживаю одну из ГИС), который не может исполнять свои обязанности из-за косяка УЦ (заставлять пользователя обращаться в УЦ с требованием исправить ошибку – бесперспективно).
Поэтому и спросил здесь.

Мне не очень понятно почему криптопровайдер лезет в сеть за проверкой сертификата, при установленных локальных копиях корневого сертификата УЦ и СОС.
Можно ли что-то с этим сделать?

Отредактировано пользователем 14 октября 2014 г. 16:23:28(UTC)  | Причина: Опечатка в параметре команды certmgr