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

Если та же функция возвращает текстовое значение параметра, то второй раз значение может быть не измениться, что означает "не установлено". Подробнее: записали на входе туда размер всего буфера, на выходе функции ничего не поменялось, но где-то в середине буфера функция записала символ 0, который символизирует конец строки.

Если потом нужна длина значащих данных, этот 0 приходится выискивать. Конечно есть соответствующая функция нахождения длины в VC рантаймах или можно просто склеивать строки, не зная размера. Однако это все равно риск - как бы за буфер не вылететь в процессе склейки/установления длины, если 0 в буфере все-таки нет. Просто для профилактики полезно записывание 0 в начало текстового буфера перед вызовом и 0 в конец текстового буфера после возврата из функции.ДаДействительно, тогда проблемка - функции разного уровня, между ними будет сложно увязать передачу параметра. Навскидку мне приходит в голову либо использование как раз того эффекта запоминания в хранилище сертификатов. Либо даже хранилище не нужно: просто установка ссылки на контейнер на токене в контекст сертификата каждый раз, раз уж идет речь о работе с токенами. Там кажется были настройки кэширования (вот только я не помню кэширования пин-кода или хэндла HCRYPTPROV).

Ещё один вопрос. А есть способ список контейнеров (ключей) только с USB токенов (rutoken/esmart/jacarta), в идеале ГОСТ2012 связанные с сертификатами подписи.
Есть ощущение, что можно это сделать параметрами функции CryptAcquireContext, но не очень понятно как именно.
С полученным криптопровайдеролм я потом вызываю CryptGetProvParam(hCryptProv, PP_ENUMCONTAINERS,...) для перебора всех ключей. (получения списка всех ключей с сертификатами).
В предположении что изначально неизвестно какой токен воткнут (если не воткнут), список должен быть пустым.

Добрый день.
Есть два варианта. У каждого свои недостатки:
1) Перечислить сертификаты в хранилище и выбрать те, у которых есть ссылка на закрытый ключ. Ссылка включает в себя имя контейнера и имя провайдера, которым контейнер можно открыть.
Плюсы: вы сможете получить список контейнеров, даже если токен не вставлен.
Минусы: сертификаты в хранилище обычного никто не чистит, так что на пользовательской машине может быть много мусора.

2) Перечислить контейнеры (PP_ENUMCONTAINERS) с флагом CRYPT_UNIQUE, выбрать те, у которых есть подстрока SCARD, последовательно их открывать и проверять сертификат (GetKeyParam(KP_CERTIFICATE)). В Windows есть специальная служба, которая автоматически ставит сертификат в Личное хранилище при подключении токена, так что с высокой вероятностью, если вы смогли перечислить токен с сертификатом, этот серт есть в хранилище. Ну а если нет, можете тут же сами кодом и установить.
Плюсы: никакого мусора
Минусы: медленнее; перечислятся только контейнеры с подключенных токенов

Честно говоря, не уверен, что до конца вас понял. Если стоит задача: установить сертификаты с токена в хранилище с правильной привязкой, наиболее простой способ - вызвать


В эту же команду при необходимости можно добавить фильтр по токенам и типам носителей. Например, чтобы ставить серты только с токенов и не трогать HDIMAGE, можно добавить

Пример кода я не дам, к сожалению.
Могу посоветовать посмотреть вот в какую сторону:
- получить сертификаты с правильными ссылками в сериализованном store: CryptGetProvParam(PP_USER_CERTSTORE, CP_CRYPT_SERIALIZED_STORE);
- открыть его с помощью CertOpenStore(CERT_STORE_PROV_SERIALIZED);
- пройтись в цикле с помощью CertEnumCertificatesInStore и ставить в хранилище CertAddCertificateContextToStore.

Если получать PP_USER_CERTSTORE в контексте, открытом по имени считывателя, то туда попадут только сертификаты с токена.

Обратите внимание, что для PKCS11-ключей в CSP 5.0.12000 нужно использовать другое имя считывателя! Не "Aktiv Rutoken ECP", а "PKCS11 Aktiv Rutoken ...". Это было исправлено в CSP 5.0 R3.