криптопро cpverify

Добрый день. Подскажите, если вызываю csptest для тестирования валидности подписания бинарного (в данном случае PDF) файла отсоединенной гостовской УКЭП на документе, командой
csptest -sfsign -verify -in c:\tmp\csp\test1.pdf -detached -signature c:\tmp\csp\test1.pdf.sgn

то что в таком случае будет проверено, когда утилита выдаёт итоговое положительное сообщение?
Detached Signature was verified OK
Total: SYS: 0,000 sec USR: 0,047 sec UTC: 0,063 sec
[ErrorCode: 0x00000000]

Проверяться будет соответствие файла и сигнатуры ЭП, или и валидность отметки даты-времени самой ЭП в составе SGN-файла тоже?

И не совсем ясно из стандартного хелпа к утилите – в процессе проверки выдаётся так же сообщение, не влияющее на итог проверки ЭП:
An error occurred in running the program.
signtsf.c:736:No user cert specified. Cryptocontext will be opened automaticaly.
Error number 0x2 (2).
Не удается найти указанный файл.

Как правильно в командной строке задавить вывод этого сообщения – чтобы только итоговое выводилось?

Добрый день.
csptest – тестовая утилита, использование которой в прикладных задачах не рекомендуется.
Правильный способ решения вашей задачи: cryptcp -verify -detached

С уважением,
Сергей Агафьин,
Начальник отдела разработки ФКН.
Техническую поддержку оказываем здесь.
Наша база знаний.

В курсе, что утилита для тестирования (собственно тестированием тестового пакета документов и сигнатур ЭП и занимаюсь). Просто хотелось бы лучше понимать, что конкретно проверяется, а что не проверяется опцией -sfsign -verify, и как вообще это работает.

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

и по поводу вопроса про “signtsf.c:736:No user cert specified. Cryptocontext will be opened automaticaly.”
тут вот немного прояснил
https://www.cryptopro.ru….aspx?g=posts&t=6291

но тогда непонятен момент – в SGN-файле есть сертификат.
Я его вижу через консоль, но почему тогда csptest его не видит и требует указать както явно в командной строке? Она же какраз валидность ЭП по этому сертификату проверяет, и выдаёт успешное сообщение “Detached Signature was verified OK”.
Вот этот момент хотелось бы лучше понять в использовании тестовой утилиты.

certmgr.exe -list -file c:\TMP\csp\test1.pdf.sgn
=============================================================================
1——-
Issuer : E=ca@****.ru, ОГРН=11********, ИНН=0066*******, C=RU, S=66 Свердловская область, L=Екатеринбург, STREET=”улица Ульяновская, д. ***, офис ***”, O=”Общество с ограниченной ответственностью “*****”, CN=”Общество с ограниченной ответственностью “*****”
Subject : E=*******@****.ru, ИНН=66*******, СНИЛС=***********, G=Евгений, SN=Евгеньев, CN=Евгеньев Евгений
Serial : 0x0319884D0046AECDA442E8633C91A84AE1
SHA1 Hash : 4e76ae229ced606e9e1df3e8059abb242d536db5
SubjKeyID : a85b079333bd19694fbe965a759a56ee54dc29da
Signature Algorithm : ГОСТ Р 34.11-2012/34.10-2012 256 бит
PublicKey Algorithm : ГОСТ Р 34.10-2012 256 бит (512 bits)
Not valid before : 24/02/2022 04:37:17 UTC
Not valid after : 24/02/2023 04:38:38 UTC
PrivateKey Link : No
OCSP URL : http://pki.sertum-pro.ru/ocspq2012/ocsp.srf
OCSP URL : http://pki2.sertum-pro.ru/ocspq2012/ocsp.srf
CA cert URL : http://ca.sertum-pro.ru/…es/sertum-pro-q-2021.crt
CA cert URL : http://ca.sertum.ru/cert…es/sertum-pro-q-2021.crt
CDP : http://ca.sertum-pro.ru/cdp/sertum-pro-q-2021.crl
CDP : http://ca.sertum.ru/cdp/sertum-pro-q-2021.crl
Extended Key Usage : 1.3.6.1.5.5.7.3.2
1.2.643.2.2.34.6
1.3.6.1.5.5.7.3.4
1.2.643.3.185.1
1.2.643.3.5.10.2.12
1.2.643.3.7.8.1
=============================================================================

[ErrorCode: 0x00000000]

А вам зачем?
Если ваша задача заключается в проверке подписи, то нужно пользоваться cryptcp.

С уважением,
Сергей Агафьин,
Начальник отдела разработки ФКН.
Техническую поддержку оказываем здесь.
Наша база знаний.

Всё просто – по планграфику работ поставка соответствующего ПО для продуктивной работы несколько отстаёт. А тестировать (пулять тестовые документы) стали уже сейчас. Поэтому довольствуемся тем, что есть в стандартной уже ранее купленной коробке Криптопро 4.

И хотелось бы на том что есть понять в т.ч., что там в SGN-файл вторая сторона натолкала (и натолкала ли всё, что нужно, или по минимуму – т.к. доверия контрагенту полного нет.

В частности хотелось бы понять, что можно извлечь из тестового SGN-файла штатными утилитами (csptest, cpverify, certmgr).
Не ясен например момент, какая версия cades, должны ли быть в SGN-файле ещё какието сертификаты (удостоверяющих центров, сервера метки времени например), и проверяется ли в т.ч. валидность даты-времени подписания ЭП.

И ещё вопрос: чем технически отличается опция -sfsign -verify от -lowsign -verify ?

Добрый день!

Есть XML-документ с подписью в формате XMLDSig. Пытаемся выполнить валидацию этой подписи через cryptcp.

В документе содержится следующий блок <Signature>:

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
        <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256" />
        <Reference URI="#id-1">
            <Transforms>
                <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            </Transforms>
            <DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256" />
            <DigestValue>6Im6T7+7e5HvqdLNnIo7MvkfPzaGtFXPafZnJD4naAE=</DigestValue>
        </Reference>
    </SignedInfo>
    <SignatureValue>Hahh6GJ8gSJwRuCFTCtX5AcQfEyFKO8VyxoIAnPRGzAAlr3zrzze1tkpHeAv8n//
2ILPAEqX3TSwFqTyln3K/w==</SignatureValue>
    <KeyInfo>
        <wsse:SecurityTokenReference>
            <wsse:Reference URI="#X-509-b4cd9b0ec38140268b4db1f31fa3e15a" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
        </wsse:SecurityTokenReference>
    </KeyInfo>
</Signature>

+ открытый ключ подписи и непосредственно тело с данными

Выполняю следующие действия:

1. Вычисляю хэш (digest) данных, на которые ссылается <Reference URI=”#id-1″>:

   Код:

   cpverify.exe -mk -alg GR3411_2012_256 data.xml

   где data.xml – это прошедшие каноникализацию подписанные данные.

2. Получаем результат в hex: E889BA4FBFBB7B91EFA9D2CD9C8A3B32F91F3F3686B455CF69F667243E276801, конвертируем данный hex в Base64, получаем: 6Im6T7+7e5HvqdLNnIo7MvkfPzaGtFXPafZnJD4naAE=
3. Видим, что рассчитанный хэш соответствует значению в <DigestValue> в исходном документе, следовательно переходим к проверке самой подписи.
4. Высчитываем хэш (digest) для блока <SignedInfo>:

   Код:

   cpverify.exe -mk -alg GR3411_2012_256 signedInfo.xml

   где signedInfo.xml содержит данные:

   Код:

   <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></CanonicalizationMethod><SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256"></SignatureMethod><Reference URI="#id-1"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform></Transforms><DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"></DigestMethod><DigestValue>6Im6T7+7e5HvqdLNnIo7MvkfPzaGtFXPafZnJD4naAE=</DigestValue></Reference></SignedInfo>

5. Получаем результат в hex: FDEBB94EB1CE9975D162A571B2139CE2DF1CE34DE732D2612437C62F80B45902, конвертируем данный hex в Base64, получаем /eu5TrHOmXXRYqVxshOc4t8c403nMtJhJDfGL4C0WQI=
6. Устанавливаем открытый ключ из исходного документа в хранилище. Получаем отпечаток: f3b370b04ad23d25fb2f19316434cf268ff0955e
7. Пытаемся проверить подпись, выполняя команду:

   Код:

   cryptcp -nochain -vsignf digest.txt -thumbprint f3b370b04ad23d25fb2f19316434cf268ff0955e

   где digest.txt – это хэш (в Base64), полученный на шаге 5
   рядом с digest.txt лежит файл digest.txt.sgn, который содержит в себе значение элемента <SignatureValue>

8. Получаем ответ [ErrorCode: 0xffffffff] без каких-либо дополнительных комментариев.

Вижу, что подпись в <SignatureValue> по сути не содержит информации о сертификате, из чего могу предположить, что нужно либо добавить какие-то параметры в вызов cryptcp на шаге 7, либо вообще использовать какую-то другую команду.

Хочу понять, как правильно выполнять валидацию такой подписи, и возможно ли это вообще через консольные утилиты КриптоПро?

Исходный XML-документ пробовал проверять через https://dss.cryptopro.ru/Verify/, там валидация прошла успешно, из чего делаю вывод, что проблема не в самом документе, а именно в нашем алгоритме его валидации.

Из того что нашел на просторах интернета и данного форума, вижу что как правило валидацию XMLDSig выполняют с помощью .NET или Java SDK, но прежде чем переходить к такой реализации, хочу убедиться что других вариантов нет.
Сервис валидации подписи у нас написан на NodeJS, взаимодействуем с КриптоПро как раз путем вызова консольных команд. При этом сервис нормально проверяет подписи, сформированные например через CryptoPro Browser Plugin, т.е. подписи которые в себе также содержат информацию о сертификате.

Добрый день.
На форуме где-то был пример валидации XMLDSig через утилиты, этот путь возможен (нужна проверка raw подписи, cryptcp вероятно не подойдет). Очевидна только одна проблема – если у Вас несколько процессов NodeJS проводят валидацию параллельно, то они должны использовать разные папки или разные имена файлов, чтобы в процессе проверки разные подписи не смешивались и не давали ошибки.

Заметки по алгоритму.

https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=11684 ответ про Raw в cryptcp

Раз уж у Вас NodeJS, может быть там получится использовать проверку Raw подписи через плагин и Javascript?
https://docs.cryptopro.r…in-samples-raw-signature

Отредактировано пользователем 15 апреля 2021 г. 8:36:33(UTC)
 | Причина: Не указана

Спасибо за ответ.

Да, у нас для валидации каждой подписи формируется отдельная временная папка.

На этот плагин я смотрел, но насколько я понял, он под капотом использует CryptoPro Browser-PlugIn, который просто так на NodeJS, не завести, т.к. это именно браузерный плагин.

Подскажите пожалуйста, что имеете ввиду под “за 5 минут сделать свою утилиту”? Разве подпись сформированную по ГОСТу можно без криптопровайдера проверить?

Попробовал проверить подпись через csptest, но судя по всему застрял на переводе Base64-подписи в DER. Поясню:

1. Сохраняю Base64-содержимое сертификата в файл cert.cer
2. Сохраняю каноникализированный <SignedInfo> в файл signedInfo.xml
3. Декодирую из Base64 содержимое тега <SignatureValue>, сохраняю в файл signedInfo.xml.sng
4. Выполняю команду:

   Код:

   csptest.exe -keys -verify GOST12_256 -in C:\sig-test\1\signed-info.xml -signature C:\sig-test\1\signed-info.xml.sgn -keytype signature -certificate C:\sig-test\1\cert.cer
   

   Получаю в ответ:

   Код:

   CSP (Type:80) v4.0.9019 KC1 Release Ver:4.0.9969 OS:Windows CPU:IA32 FastCode:READY:SSSE3.
   AcquireContext: OK. HCRYPTPROV: 21807288
   GetProvParam(PP_NAME): Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider
   Public key imported from cert file: C:\sig-test\1\cert.cer
   Hash object created with alg: GOST12_256 0x8021
   The data buffer has been hashed.
   An error occurred in running the program.
   ctkey.c:3534:Bad Signature.
   Error number 0x80090006 (-2146893818).
   Неправильная подпись.
   
   Total: SYS: 0,031 sec USR: 0,047 sec UTC: 0,176 sec
   [ErrorCode: 0x80090006]
   

Попробовал пойти в обратном порядке, сделал следующие действия:

1. Сформировал тестовый сертификат для подписи, сохранил в локальном хранилище, публичный ключ экспортировал в файл test-signer.cer
2. Выполняю команду:

   Код:

   csptest.exe -keys -sign GOST12_256 -in C:\sig-test\1\signed-info.xml -out C:\sig-test\1\signed-info.xml.self-signed.sgn -keytype signature -cont default
   

3. Выбираю контейнер со сформированным сертификатом для подписи.
4. В ответ получаю:

   Код:

   CSP (Type:80) v4.0.9019 KC1 Release Ver:4.0.9969 OS:Windows CPU:IA32 FastCode:READY:SSSE3.
   AcquireContext: OK. HCRYPTPROV: 13710280
   GetProvParam(PP_NAME): Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider
   Container name: "58401f2db-2059-b990-d56b-e2ab0af28cf"
   Signature key is available. HCRYPTKEY: 0xd2ffb0
   Hash object created with alg: GOST12_256 0x8021
   The data buffer has been hashed.
   Signature length 64 found.
   Signature was done.
   Output file (C:\sig-test\1\signed-info.xml.self-signed.sgn) has been saved
   Signature saved into file C:\sig-test\1\signed-info.xml.self-signed.sgn
   
   Keys in container:
     signature key
   Extensions:
     OID: 1.2.643.2.2.37.3.9
     PrivKey: Not specified - 15.07.2022 16:39:41 (UTC)
   Total: SYS: 0,438 sec USR: 0,219 sec UTC: 6,106 sec
   [ErrorCode: 0x00000000]
   

5. Проверяю сформированную только что подпись:

   Код:

   csptest.exe -keys -verify GOST12_256 -in C:\sig-test\1\signed-info.xml -signature C:\sig-test\1\signed-info.xml.self-signed.sgn -keytype signature -certificate C:\sig-test\1\test-signer.cer
   

6. В ответ получаю:

   Код:

   CSP (Type:80) v4.0.9019 KC1 Release Ver:4.0.9969 OS:Windows CPU:IA32 FastCode:READY:SSSE3.
   AcquireContext: OK. HCRYPTPROV: 16274368
   GetProvParam(PP_NAME): Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider
   Public key imported from cert file: C:\sig-test\1\test-signer.cer
   Hash object created with alg: GOST12_256 0x8021
   The data buffer has been hashed.
   Signature was verified OK
   
   Total: SYS: 0,031 sec USR: 0,047 sec UTC: 0,134 sec
   [ErrorCode: 0x00000000]
   

Т.е. подпись сформировал и проверил, вроде бы все ок.
Дальше пытаюсь проверить эту подпись в контексте всего XML-документа.

1. В исходном XML-файле заменяю сертификат на содержимое файла test-signer.cer
2. Содержимое файла с полученной подписью (signed-info.xml.self-signed.sgn) кодирую в Base64, и помещаю в элемент <SignatureValue>
3. Полученный файл пытаюсь проверить через https://dss.cryptopro.ru/Verify/ – получаю ошибку. Как уже писал ранее, исходный XML через данный сервис проверяется корректно.

При этом в моем понимании, так как подпись формируется только на SignedInfo, а он у меня остался неизменным, то такая “ручная подмена” подписи и сертификата должны сработать.

Если так, то в итоге могу предположить что где-то на этапе преобразования подписи в Base64 что-то идет не так. Либо где-то не соответствуют алгоритмы подписания, хотя я везде использовал GOST 2012 256, как указано в алгоритмах из <SignedInfo>

Нужна помощь в авторизации по API в Честном знаке.

Система авторизации там такая

curl -X GET "<url стенда v3>/auth/key"
-H "accept: application/json"

Ответ
{
   "uuid":"a63ff582-b723-4da7-958b-453da27a6c62", // Уникальный идентификатор сгенерированных случайных данных
   "data":"GNUFBAZBMPIUUMLXNMIOGSHTGFXZMT" // Случайная строка данных
}

Далее

curl -X POST "<url стенда v3>/auth/simpleSignIn"
-H "accept: application/json"
-H "Content-Type: application/json"

{
   "uuid":"string", // полученный id
   "data":"string" // Подписанные УКЭП зарегистрированного УОТ случайные данные в base64 (присоединённая ЭП)
}

Как подписать эту строку на удаленном Linux сервере.

Я установил там КриптоПро для Linux
Содержимое папки на сервере

certmgr
cpverify
cryptcp
csptest > csptestf
csptestf
csptestlite
curl
der2xer
genkpim
inittst
list_pcsc
wipefile

В вебинаре Честного знака сказали что-то про “экспорт сертификата”.
Экспорт сертификата ИП я нашел, как сделать, из виндового приложения КриптоПро ноута, который работает с флешкой,
а как заставить удаленный сервак подписать эту строку, необходимую для авторизации ?

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

Контейнер (папка с .key файлами или в каком виде имеется?) перенесён на сервер? Сертификат установили в хранилище?

Подписание:
/opt/cprocsp/bin/amd64/cryptcp -sign -thumbprint отпечаток “/path/file.txt” “/path/file.txt.p7s” -nochain -norev

file.txt – содержит текстовую строку

file.txt.p7s – будет содержать присоединенную подпись (данные из file.txt, сертификат, подпись)

далее прочитать file.txt.p7s, закодировать в base64 и отправить запрос через curl

либо другой вариант, через php – собрать расширение и подписывать\отправлять из php

Спасибо большое. Да, это то, что нужно.

Пробовал собрать, не работает
eval `/opt/cprocsp/src/doxygen/CSP/../setenv.sh –64`; make -f Makefile.unix
постоянно выдает кучу разных ошибок. То файла .h какого то не хватает, по версия не та. Причем почти все из них обсуждались на форуме.
Пробовал патч, пробовал все версии. Бесполезно. Php 7.4
Snimok ehkrana 2022-07-22 010226.png (91kb) загружен 2 раз(а).

Устанавливаю сертификат для пользователя www-root
sudo -u www-root /opt/cprocsp/bin/amd64/certmgr -inst -all -store uMy -file /home/cert.p7b

Пытаюсь подписать файл
sudo -u www-root /opt/cprocsp/bin/amd64/cryptcp -sign -thumbprint e07bcb550e38222ea9d0142c4c574bdd471df28f “/var/www/www-root/data/test.txt” “/var/www/www-root/data/test.txt.p7s” -nochain -norev

CryptCP 5.0 (c) “Crypto-Pro”, 2002-2022.
Command prompt Utility for file signature and encryption.

The following certificate will be used:
RDN:хххххххххххххххххххххххххххххххххххххх
Valid from 01.02.2022 11:00:15 to 01.05.2023 11:10:15

Folder ‘/var/www/www-root/data/’:
/var/www/www-root/data/test.txt… Error: Can not get certificate private key.
../../../../CSPbuild/CSP/samples/CPCrypt/DSign.cpp:489: 0x20000136
[ErrorCode: 0x20000136]

Где взять этот закрытый ключ, и как его установить (в контейнер, видимо).
Ключ вроде как должен находиться на флешке синей (иначе, зачем она нужна каждый раз).
Но сервер находится в датацентре за границей и воткнуть ее туда невозможно.
Правильно ли я понимаю, что вытащить закрытый ключ из флешки невозможно и она обязательно нужна, как физической объект,
а следовательно, единственный способ автоматизировать подпись, это собрать комп на статическом ip, куда воткнуть эту флешку ?

И, если все это так, что как создать этот самый контейнер ?

Отредактировано пользователем 22 июля 2022 г. 2:16:53(UTC)
 | Причина: Не указана

Добрый день.
Советовать насчет сервера за границей сложно, лучше бы что-то в пределах своей страны использовать для подписания. Могут быть разные “несоответствия” при передаче ключа через границу.

По вопросу – есть еще и облачные подписи, в таком случае на физический объект флешка не понадобится. Поддерживаются в КриптоПро с 5 версии.

Насчет копирования ключа на сервер (допустим, в своей стране) важно знать:
а) неизвлекаемый (неэкспортируемый) ли ключ и б) обычная флешка или токен.
1. Если флешка обычная, то достаточно скопировать контейнер (папку с именем вроде хххххххх.000 и с 6 файликами key) в определенную папку на сервере, примерно /var/opt/cprocsp/keys/root/ если запускаете под root. Далее установить сертификат с привязкой к контейнеру.
2. Если токен и ключ извлекаемый (экспортируемый), то можно штатно скопировать на обычную флешку средствами КриптоПро, далее как в предыдущем пункте.
3. Если токен и ключ неизвлекаемый (неэкспортируемый), – в активном или пассивном режиме создан ключ. Активный режим приговаривает к ситуации когда должен торчать конкретный физический носитель и больше никак. Пассивный режим означает, что токен только хранилище и в теории можно попробовать считать ключ, затем записать копию. “В теории”, потому что штатные средства тут не помогут, а соответствующие форматы не афишируют. Поэтому более реально перевыпустить сертификат специально указав, что ключ должен быть экспортируемый.

Нашел, как вытащить закрытый ключ с рутокена. Скопировал 6 .key файлов в папку.
Контейнер видит

root@server0:/opt/cprocsp/bin/amd64# /opt/cprocsp/bin/amd64/csptest -keyset -enum_cont -verifycontext -fqcn
CSP (Type:80) v5.0.10010 KC1 Release Ver:5.0.12500 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 39012595
\\.\HDIMAGE\d57b44fd-7ac9-4479-bf9a-b6be6d111eca-1
OK.
Total: SYS: 0.000 sec USR: 0.000 sec UTC: 0.010 sec
[ErrorCode: 0x00000000]

но упорно не хочет брать из него ключ

root@server0:/opt/cprocsp/bin/amd64# sudo -u www-root /opt/cprocsp/bin/amd64/cryptcp -sign -thumbprint e07bcb550e38222ea9d0142c4c574bdd471df28f “/var/www/www-root/data/test.txt” “/var/www/www-root/data/test.txt.p7s” -nochain -norev
CryptCP 5.0 (c) “Crypto-Pro”, 2002-2022.
Command prompt Utility for file signature and encryption.

The following certificate will be used:
RDN:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Valid from 01.02.2022 11:00:15 to 01.05.2023 11:10:15

Folder ‘/var/www/www-root/data/’:
/var/www/www-root/data/test.txt… Error: Can not get certificate private key.
../../../../CSPbuild/CSP/samples/CPCrypt/DSign.cpp:489: 0x20000136
[ErrorCode: 0x20000136]
root@server0:/opt/cprocsp/bin/amd64#

Добрый день. Это уже детали процедуры установки сертификата, которые чуть не в каждом руководстве по установке сертификата на Linux описываются. Конечно лишний раз повторить не помешает.

Во-первых, важно, чтобы команды были от одного пользователя. Выше одна команда без sudo то есть от самого пользователя root, а вторая (если я правильно понимаю) от www-root.

Если root контейнер HDIMAGE ищется в папке /var/opt/cprocsp/keys/root/ Если www-root контейнер HDIMAGE ищется в папке /var/opt/cprocsp/keys/www-root/ У соответствующего пользователя должны быть права на нужную папку – чтение и запись. (Для видимости всем по идее еще какая-то папка, но используется нечасто, так что точно не знаю.) Таким образом, в одном случае контейнер увидится, в другом нет. Тем не менее, обычно в такой ситуации из функций нижнего уровня “выскакивает” другая ошибка – “Набор ключей не существует” и делается попытка его сгенерировать. Другой код ошибки вероятно указывает, что еще с чем-то не все в порядке.

Во-вторых, если при подписании указывается не имя контейнера, а сертификат или реквизиты (отпечаток в командной строке выше) сертификата, то сертификат должен быть: а) установлен в хранилище сертификатов – выше можно увидеть в выводе что нашелся, показало его срок действия; б) при установке в хранилище должен быть указан контейнер для этого сертификата. Проверить можно командой (от нужного пользователя) вроде такой sudo -u www-root /opt/cprocsp/bin/amd64/certmgr -list -store uMy где uMy – имя хранилища, ищем строку PrivateKey: Yes и совпадение строки Container: с тем, что выдало csptest -keyset -enum_cont -verifycontext -fqcn , то есть \\.\HDIMAGE\d57b44fd-7ac9-4479-bf9a-b6be6d111eca-1

Если PrivateKey: No или неверное имя контейнера, то нужно переустановить сертификат в хранилище.

Отредактировано пользователем 5 сентября 2022 г. 7:41:24(UTC)
 | Причина: Не указана

Спасибо большое за ваш труд.
По рутом все работает ! )
но

root@server0:~# sudo -u www-root /opt/cprocsp/bin/amd64/certmgr -inst -all -store uMy -file /home/cert.p7b -cont ‘\\.\HDIMAGE\d57b44fd-7ac9-4479-bf9a-b6be6d111eca-1’

показывает данные серта
PrivateKey Link : No
Identification Kind : Personal presence

и пишет
Installing multiple certificates with private key link is not allowed

The data is invalid.

Я удалял серт и контейнер и создавал заново

/var/opt/cprocsp/keys/www-root/ – .key файлы залил, владельца поменял на www-root

/opt/cprocsp/bin/amd64/csptest -keyset -enum_cont -verifycontext -fqcn
и
sudo -u www-root /opt/cprocsp/bin/amd64/csptest -keyset -enum_cont -verifycontext -fqcn

показывают контейнеры для обоих пользователей

Как переустановить сертификат в хранилище, чтобы этот приватлинк привязался ?

в p7b несколько сертификатов? Укажите только личный сертификат

у меня нет файлов с расширением .cer
в .p7b должен быть вроде один сертификат
Для root все как-то поставилось той же командой, а www-root выдает ошибку

без -all пробовали?

Сработала комманда

sudo -u www-root /opt/cprocsp/bin/amd64/certmgr -inst -store uMy -cont ‘\\.\HDIMAGE\d57b44fd-7ac9-4479-bf9a-b6be6d111eca-1’

Спасибо всем большое, кто помог с проблемой !