Еще раз, указанный пример, показывает как Java позволяет приложениям быть гибкими и не заставляет частные реализации завязываться на внутренее устройство JRE. Java CSP являясь частной реализацией JCA должна была сохранить эту гибкость как минимум.


Так надо было следовать полностью и использовать хранилища из CSP, а не привязываться к хранилищам JRE. Хорошо хоть остаавили публичными AbstractCertificateChainBuilder.CACERTS_TRUST_CERTIFICATES и AbstractCertificateChainBuilder.CACERTS_INTERMEDIATE_CERTIFICATES, надеюсь оно так и останется пока вы не добавите нормальную работу с хранилищами CSP и кастомными хранилищами.

Отредактировано пользователем 4 августа 2022 г. 12:13:07(UTC)  | Причина: Не указана

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

Сейчас используется хранилище, которые на момент разработки cades в jcp (не jcsp) требовалось использовать. По поводу root csp ранее ответили, полагаю, их чтение будет добавлено.

Код кадеса регулярно, как и другой код, претерпевает изменения, указанные классы - внутренние, использовать их не рекомендуется, в правилах пользования даже есть "белый" список api. Вполне вероятно, эта часть могла измениться и работает уже иначе. Недавно была добавлена возможность перечитать cacerts в коде, если известно, что cacerts обновился.