Здравствуйте.
Автор: biff
В КриптоПро CSP есть свои хранилища CA и TRUSTED ROOT, почему же CAdES использует cacerts?
Так сложилось исторически, у Java вполне есть свое хранилище доверенных корневых сертификатов cacerts. Возможность работы с CSP появилась позже.
Автор: biff
И как получить обратно из CSP всю цепочку с помощью Java CSP? Грузить отдельно CA и ROOT хранилища и искать там или самому грузить по url всю цепочку?
Действовать в соответствии с описанием интерфейсов и документации. Других механизмов нет. Java CSP изначально настроен на взаимодействие с CSP тjлько по части криптографии, поддержка работы с его хранилищами появилась недавно.
Автор: biff
Если пытаться грузить CA и ROOT store в Java приложении, то приложение зависает на несколько минут, при этом если запускать CSP tools, то запускается за миллисекунды и спокойно отображает CA и ROOT хранилища. В Java CSP есть явные проблемы при работе с хранилищами CSP
В последних версиях Java CSP устранялись подобные проблемы.
Автор: biff
Проблема в производительности также наблюдается при работе с PFX_STORE_NAME, грузит сертификат несколько минут, хотя в интерфейсе CSP тотже сертификат грузится в секунду, но там хотя бы есть вся цепочка сертификатов.
См. выше, в последних версиях Java CSP устранялись подобные проблемы.
Автор: biff Суть проблемы, пользователь для подписи может использовать разные сертификаты от разных УЦ, в основном они устанавливают сертификаты только КрипроПро CSP и ничего не знают о cacerts и как в него добавлять сертификаты. На данный момент 42 аккредитованных УЦ, но в любой момент могут появится новые, использование параметра com.sun.security.enableAIAcaIssuers тоже не вариант, т.к. в некоторых сертификатах CA url уже не доступны (например УЦ Корус, в нем CA url
http://reestr-pki.ru/cdp/guc_gost12.crt). И у пользователей нет прав на редактирование cacerts, т.е. это нужно будет постоянно обновлять этот файл через политики.
Вопросами установки корневых сертификатов в cacerts обычно занимается администратор системы.
JCP/JCSP чаще используются в серверных системах, что у вас за ПО?
Автор: biff
AdES использует BC (BouncyCastle) для построения пути сертификатов (ru.CryptoPro.AdES.certificate.CertificateChainBuilderImpl). Почему бы не использовать JCSP провайдер, он же может получить CA_STORE и ROOT_STORE из CSP? И тем самым построить правильный путь и не нужно дополнительно сертификаты в cacerts импортировать.
...
Почему AdES классы в JavaCPS не могут использовать JCSP как источник CA сертификатов?
В конечном итоге используется провайдер RevCheck.
Возможность использовать системные хранилища в CAdES мы проверим, спасибо за предложение.
Автор: biff
вся работа JCA с провайдером JCSP будет перенаправлена в CPS как следует из вашего же описания.
Вся не будет, но вопрос на счет использования системных хранилищ мы изучим.
Автор: biff
1. Почему же тогда в JavaCSP нельзя поменять классы AdES чтобы они грузили сертификаты не из jvm, а из CSP тем более что есть для этого и константы соответствующие JCSP.ROOT_STORE_NAME и JCSP.CA_STORE_NAME?
Доступ к системным хранилищам появился недавно. Для библиотек *AdES* так сложилось исторически - работа прежде всего с Java, а не CSP, без жесткой привязки к провайдеру, одинаково для JCP (прежде всего) и Java CSP.
Автор: biff
2. Ну и про цепочку сертификатов: Почему из HD_IMAGE не возвращается вся цепочка сертификатов, а только один сертификат?
Метод getCertificateChain всегда возвращает цепочку сертификатов или один сертификат из ключевого контейнера заданного типа (HDIMAGE).