Статус: Участник
Группы: Участники
Зарегистрирован: 20.01.2022(UTC) Сообщений: 25
|
В общем, тему можно закрывать (ждем решения проблемы валидации сертификатов при загркузке MY_STORE, CA_STORE и TRUST_STORE). Решение проблемы создания CAdES: 1. Импортируем корневой сертификат в trust store (файл можно локально положить в приложении, но хотелось бы чтобы JCSP умел брать trust store из CSP) 2. Используем хранилище MY_STORE из него можно получить как и приватный ключ, так и всю цепочку сертификатов. Отредактировано пользователем 25 июля 2022 г. 18:44:11(UTC)
| Причина: Не указана
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 20.01.2022(UTC) Сообщений: 25
|
Проблема с цепочкой сертификатов не только с HD_IMAGE_STORE, но и с токенами Рутокен, JCSP возвращает только один сертификат, на токене точно вся цепочка и корневой в том числе.
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 704 раз в 665 постах
|
Нужно определиться, с каким форматом вы работаете: pfx или HDIMAGE. Автор: biff Получается, что чтобы получить приватный ключ мне нужно брать его из HD_IMAGE, а как получить всю цепочку сертификатов от оригинального pfx?
Если с pfx, то из pfx можно получить все ключи и сертификаты с помощью имени хранилища с именем "PFXSTORE". Автор: biff Пока не ясно как получить всю цепочку, пользователям выдаются сертификаты с полной цепочкой, корневой сертификат ладно мы закинем cacerts, но промежуточный все равно нужен и он есть в pfx, а в HD_IMAGE контейнере его нет.
В ином случае, если нет функционала установки цепочки сертификатов (например, p7b) в ключевой контейнер, можно использовать enableAIAcaIssuers или содержать список промежуточных сертификатов, который передавать в CAdESSignature, или держать его в cacerts. Автор: biff Проблема с цепочкой сертификатов не только с HD_IMAGE_STORE, но и с токенами Рутокен, JCSP возвращает только один сертификат, на токене точно вся цепочка и корневой в том числе.
Это не проблема, а стандартное поведение для всех KeyStore: getCertificateChain возвращает сертификат(ы) из конкретного ключевого контейнера. Скорее всего, в ключевом контейнере на токене один сертификат, а остальные при просмотре в cptools или панели CSP докачиваются из сети/берутся из системных хранилищ. Отредактировано пользователем 25 июля 2022 г. 20:27:36(UTC)
| Причина: Не указана |
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 20.01.2022(UTC) Сообщений: 25
|
Цитата: Нужно определиться, с каким форматом вы работаете: pfx или HDIMAGE.
Со всеми форматами, которые поддерживает CSP как контейнеры. PFXSTORE не вариант использовать как и флаг enableAIAcaIssuers, проблема таже, что и с остальными контейнерами (писал выше), при чтении через JCSP методом load вызывается валидация либо скачивание всей цепочки сертификатов в контейнере и он пытается по сети скачать все сертификаты, но не все URL адреса там доступны (в самих сертификатах адреса не существующие), поэтому приложение просто виснет, если выключить сеть, то все работает, контейнеры загружаются. такой проблемы нет только с HDIMAGE контейнерами. Хорошо, похоже так и есть, всей цепочки в контейнерах нет. Будем хранить их сами. Спасибо за ответы. Отредактировано пользователем 25 июля 2022 г. 22:21:31(UTC)
| Причина: Не указана
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 704 раз в 665 постах
|
Автор: biff приложение просто виснет, если выключить сеть, то все работает, контейнеры загружаются Попробуйте с последней сборкой jcsp с сайта. |
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 20.01.2022(UTC) Сообщений: 25
|
Попробовать-то я конечно могу, но нам нужна сертифицированная версия для выхода в продуктив, а она-то и не работает. Ну и еще одна ложка дёгдя: в AbstractCertificateChainBuilder захардкожен путь до cacerts, поэтому кастомный cacerts уже не получится использовать, хотя Java это легко позволяет сделать через проперти javax.net.ssl.trustStore
|
|
|
|
Статус: Сотрудник
Группы: Модератор, Участники Зарегистрирован: 03.12.2018(UTC) Сообщений: 1,193 Сказал(а) «Спасибо»: 100 раз Поблагодарили: 274 раз в 254 постах
|
Цитата:javax.net.ssl.trustStore тлс и подпись используют разные механизмы. так что пример не корректен |
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 20.01.2022(UTC) Сообщений: 25
|
Это был всего лишь пример, что это можно делать, особенно для кастомных реализаций JCA, а не храдкодить пути до системного хранилища, если уж так хотите вот официальная инфрормацияЦитата: The user keystore is by default stored in a file named .keystore in the user's home directory, as determined by the user.home system property whose default value depends on the operating system:
Solaris, Linux, and MacOS: /home/username/ Windows: C:\Users\username\
Of course, keystore files can be located as desired. In some environments, it may make sense for multiple keystores to exist. For example, one keystore might hold a user's private keys, and another might hold certificates used to establish trust relationships.
In addition to the user's keystore, the JDK also maintains a system-wide keystore which is used to store trusted certificates from a variety of Certificate Authorities (CA's). These CA certificates can be used to help make trust decisions. For example, in SSL/TLS/DTLS when the SunJSSE provider is presented with certificates from a remote peer, the default trustmanager will consult one of the following files to determine if the connection is to be trusted:
Solaris, Linux, and MacOS: <java-home>/lib/security/cacerts Windows: <java-home>\lib\security\cacerts
Instead of using the system-wide cacerts keystore, applications can set up and use their own keystores, or even use the user keystore described above.
Отредактировано пользователем 1 августа 2022 г. 13:19:06(UTC)
| Причина: Не указана
|
|
|
|
Статус: Сотрудник
Группы: Модератор, Участники Зарегистрирован: 03.12.2018(UTC) Сообщений: 1,193 Сказал(а) «Спасибо»: 100 раз Поблагодарили: 274 раз в 254 постах
|
По нашему мнению администратор безопасности должен регулировать корни доверия. для изменения cacerts можно добавить пользователя в группу и сделав chmod на cacerts |
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 704 раз в 665 постах
|
Автор: biff Это был всего лишь пример, что это можно делать, особенно для кастомных реализаций JCA, а не храдкодить пути до системного хранилища, если уж так хотите вот официальная инфрормацияЦитата: The user keystore is by default stored in a file named .keystore in the user's home directory, as determined by the user.home system property whose default value depends on the operating system:
Solaris, Linux, and MacOS: /home/username/ Windows: C:\Users\username\
Of course, keystore files can be located as desired. In some environments, it may make sense for multiple keystores to exist. For example, one keystore might hold a user's private keys, and another might hold certificates used to establish trust relationships.
In addition to the user's keystore, the JDK also maintains a system-wide keystore which is used to store trusted certificates from a variety of Certificate Authorities (CA's). These CA certificates can be used to help make trust decisions. For example, in SSL/TLS/DTLS when the SunJSSE provider is presented with certificates from a remote peer, the default trustmanager will consult one of the following files to determine if the connection is to be trusted:
Solaris, Linux, and MacOS: <java-home>/lib/security/cacerts Windows: <java-home>\lib\security\cacerts
Instead of using the system-wide cacerts keystore, applications can set up and use their own keystores, or even use the user keystore described above.
Указанный пример касается TLS, где работа с хранилищем уже была заложена в API самого JDK и, если не следовать этой логике, в ряде случаев (там, где используется упомянутые system-свойства) могут возникнуть проблемы с интеграцией TLS модуля. Для *AdES было решено больше соответствовать поведению CAdES SDK из CSP, где список корневых получают из системного хранилища ROOT (соответственно, cacerts в Java CAdES). |
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close