Автор: Андрей * Автор: two_oceans
Для выбора адресата в чей адрес отправить используется хранилище Aдресная книга (тут уже не фигурируют токены, так что время линейное). В них число сертификатов влияет на время отображения интерфейсов подписания. Если же указана некая информация о сертификате, то поиск от количества сертификатов замедляется не так сильно чем выбор для подписания.
Это ... про какое-то приложение? Outlook?
Каким образом подписание (личным сертификатом) связано с другим хранилищем?
или речь про.. шифрование на свой и сертификаты получателей?
Напрямую никак не связано. В начале это был один абзац про 2 хранилища Личные и Адресная книга. Хотел передать мысль про то, что они часто используются и не надо их захламлять. Переписано на 2 абзаца для облегчения понимания, а предложение "В них число сертификатов влияет на время отображения интерфейсов подписания." осталось неисправленным и должно подводить итог обоим абзацам. Отдельный абзац из одного короткого предложения смотрится не очень, осталось со вторым абзацем.
Более корректно наверно так: В
этих хранилищах (Личные и Адресная книга) число сертификатов влияет на время отображения интерфейсов
выбора сертификатов для подписания
(или шифрования, соответственно).
Цитата:CertFindCertificateInStore
В теории, да. На практике, я пытался в свой программе для СМЭВ, но в итоге сдался. Про эту функцию у меня очень мало добрых слов. Потому что она то ищет, то не ищет и непонятно в чем причина ненахождения.
Даже просто по отпечатку, при этом в перечислении по тому же хэндлу хранилища есть сертификат с таким отпечатком. Я бы понял, если не работало вообще - думал может не так параметры передаю, не в том формате. Но ведь нет, то ищет, то не ищет, в зависимости от запуска одного и того же скомпилированного exe из службы или как обычное приложение из проводника. Проверялось и в хранилище пользователя (которое под службой пустое - тут загадки нет) и в хранилище компьютера (с флагом только чтение - которое видно и пользователю и службе, при перечислении абсолютно одинаковое содержимое, при поиске отличие в результате).
По расширенному использованию ключа тупо на все отвечает "не найдено". Разбор идентичен и у моей структуры в разных кусках памяти и у возвращаемого из сертификатов списка оидов в одном куске памяти. Однако на FreePascal / Delphi немного сложно объединять разнородные куски памяти разного размера в один: просто динамически выделить буфер большего размера и приконкатить содержимое другого кусочка памяти проблемы нет, но там во всех структурах указатели друг на друга, и они поменяются при объедининении. Придется делать арифметические операции с указателями, со смещениями было бы проще. С другой стороны, при выделении основного куска памяти для создания структуры я не в курсе сколько памяти прибавлять на оиды, ведь у них разная длина.
Передавал основную структуру в одном куске с указателями на буферы оидов (допущение что известно максимальное число оидов), буферы оидов каждый в отдельном куске, все кусочки протестированы: IsBadReadPtr выдает false. Однако результат "не найдено".
Видимо надо обязательно уместить в одном куске. Как по мне, странно возвращать "не найдено", хотя речь про организацию памяти. "Как есть" вернувшийся список тоже не подходит, мне надо из 6 оидов сертификата искать только по двум (аутентификация клиента и СМЭВ ЭП-ОВ).
В итоге, гораздо надежнее перечислить все сертификаты в хранилище CertEnumCertificatesInStore, получить для каждого нужную характеристику и самому сравнить с искомым, чем разбираться с описаниями форматов параметров на Си++ и потом полагаться на непонятно какую работу CertFindCertificateInStore.
Цитата:- Запрашивается у каждой вложенной подписи структура: CryptMsgGetParam ( .. CMSG_SIGNER_INFO_PARAM ... )
- далее поиск сертификата CertFindCertificateInStore, в pvFindPara передаётся "уникальная" комбинация по УЦ\серийному номеру...
Ну нашли сертификат. Дальше то собственно что? ТС как раз не разобрался как подтолкнуть конкретный сертификат в функцию проверки VerifyCades либо в SignedData, потому и указывает Store целиком.
Отредактировано пользователем 15 октября 2021 г. 8:04:27(UTC)
| Причина: Не указана