Автор: dripfeeder 
Немного отступлю, сказав, что java, JCP на этом linux сервере и ключи 100% рабочие, т.к. используются для самописного сервиса подписания СМЭВ3 в автоматическом режиме всех входящих запросов в виде веб-сервиса.
Каталог с ключём в виде "st3t.000" и уже внутри все *.key
Я уже ключи, а точнее каталог с ними клал и сюда: "/opt/smev3/adapter/" и в "/var/opt/cprocsp/keys/root/", менял "Встроенный интерфейс" на "Файловое хранилище" но результат тот же.
Подскажите пожалуйста, куда копать, в каком направлении, т.к задача из разряда "вчера" (
Готов предоставить доп. информацию если необходимо. Спасибо.
Добрый день. По написанному сразу основные вопросы такие:
1) под каким пользователем стартует адаптер? "/var/opt/cprocsp/keys/root/" это для случая когда запущено под root, если у Вас другой пользователь последняя часть пути будет соответственно именем пользователя;
2) тот пользователь (под которым запускается) должен иметь права чтение+запись на папку с контейнером (в которой лежат 6 файликов .key) или точнее на каждый из 6 файликов, так как криптопровайдер время от времени их меняет (что-то вроде перешифрования ключа);
3)Что насчет обычных утилит КриптоПро CSP csptest/certmgr, они есть? Видят ли они какой-то сертификат / контейнер при запуске от имени того же пользователя? Если да, то перечень контейнеров - отличная подсказка, что должно быть в алиасе.
На windows имена контейнеров могут формироваться несколько по-другому в части имени считывателя, если фигурирует FAT12 или REGISTRY, то такое имя не пригодится под *nix. Если фигурирует HDIMAGE, то подойдет. По идее также должны подойти имена без считывателя, такое имя "дружественное" имя обычно можно подсмотреть без спецутилит текстовым редактором (только не пытайтесь текстовым редактором изменять) в файлике name.key (первые 4 байта - служебное кодирование ASN.1 далее идет имя, если конечно с файликом не шаманили вручную). В случае если шаманили в конце могут быть "лишние символы", не входящие в кодирование. Если имя длиннее 125 символов, то служебных байт в начале будет больше;
4) установлен ли пин-код на контейнер? Если да, то следующая проблема может быть в этом (когда контейнер найдется);
5) сертификат установлен в хранилище? С указанной ссылкой на контейнер? Это тоже потенциальная следующая проблема. Разные программы используют разный подход - одни сначала ищут сертификат в хранилище, потом по ссылке находят контейнер; другие наоборот сначала ищут контейнер потом ищут сертификат в контейнере и иногда найденный еще раз прогоняют по хранилищу. Оба подхода рабочие, но требуют наличия сертификата в разных местах. Возможно другой сервис использует другой подход и нужно сертификат добавить в еще одно место.
Лично по моему вкусу, первый подход дает более "прямое" движение логики, но всегда "сюрприз" вставлен ли носитель. В то же время во втором логика ходит кругами, но отлично отслеживает доступные контейнеры. В Вашем случае контейнер в папке, то есть ситуация "носитель не подключен" не самая актуальная (имею ввиду когда он найдется) и было бы оптимальнее искать по сертификату в хранилище.
6) контейнеры(в этом абзаце про контейнеры ОС *nix, не про ключевые контейнеры), докеры и/или Джава машины просто могут быть разные на одном и том же сервере, поэтому если один Джава сервис работает, это еще не гарантирует, что другой Джава сервис также будет работать (из-за настроек, классов, пакетов и т.д. в разных Джава мащинах). Будьте внимательны с этим, не раз на форуме оказывалось, что код выполняется совсем не той Джава машиной. Аналогично, если ключи в другом сервисе расположены в другом контейнере ОС, то их работоспособность может быть не связана с Вашей папкой ключей.
