| ||||
| ||||
| Добрый день. Прежде чем задать вопрос, хочу поблагодарить КриптоПро за этот форум, да и вообще за примеры, на этом сайте. Вопрос следующий: я хочу хранить сертификаты и приватные ключи клиентов на дискете (использую пока майкрософтовский CSP), не устанавливая их в реестр. Как это реализовать? (на дискете находится сертификат (*.cer) с приваткеем (*.pvk)) На сколько я понимаю, закрытый ключ находиться в контейнере CSP и сертификат привязан к этому контейнеру. Но как сделать так, чтобы ключ не находился в конейнере (в реестре), а был на дискете? И что это за свойство сертификата CERT_PVK_FILE_PROP_ID? Когда его использует CSP? Спасибо большое. Валентин | ||||
| Ответы: | ||||
| ||||
| Сделать это можно наверн только в два шага. Микрософт по принципу всегда делает ключи в реестр а на 2000 и ХР в профайл. Но после этого можно пользовать PFX для экспорта закрытого ключа и сертификата в файл (на туже дискету) а ключ удалить через DELETE_KEYSET. Собственные приложения должны справиться с PFX (в CryptoAPI и CAPICOM 2.0 есть функции для работы с ним) и если посмотрите в дискуссии по CAPICOM там на этой неделе вопрос этот активно обсуждался. | ||||
| ||||
| Да, я пробовал так сделать: экспортировал в PFX сертификат с закрытым ключем, а на клиенте импортирую hCertStore = PFXImportCertStore(...) и далее достаю оттуда сам сертификат PCCERT_CONTEXT pCert = CertEnumCertificatesInStore(hCertStore, NULL). Затем пытаюсь использовать его, но Crypto API не может найти private key. Я решил посмотреть имя контейнера с ключами: запрашиваю HCRYPTPROV (CryptAcquireCertificatePrivateKey) и смотрю имя контейнера. На сколько я понимаю это имя контейнера в реестре , где лежали ключи перед экспортом сертификата (или я не прав?) и на локальной машине этого контейнера естественно нет ;(( Если я импортирую этот сертификат в персональное хранилище ("MY")CertAddCertificateContextToStore(...) то все работает. Как вообще указать Crypto API, что тип ключевого ностителя является дискета и как это сделано у вас? () желательно бы кусочек кода. Т.е. имя контейнера я задал, а вот тип носителя не могу найти как задать. Такое впечатление, что майкрософтовский CSP не поддерживает кроме реестра ничего. | ||||
| ||||
| Когда сертификат с ключом в микрософте экспортируется дополнительно прописывается имя контейнера и имя криптопровайдера. Вот например: BMPString Microsoft Base Cryptographic Provider v1.0 SEQUENCE OBJECT IDENTIFIER 1 2 840 113549 1 9 20 SET BMPString afba20e7190f110307020533359aca51_e3c70ceb-b98f-4 1fc-9515-b97bb1e369a5 Когда импортируется их PFX в справочник попадает сертификат и восстанавливается ключ с именем контейнера и с использованием того провайдера, который был записан. Сертификатом без AcquireContext пользоваться можно, но толко в тех функциях, которые это делают сами (например, CryptSignMessage). Дело в том что в справочник вместе с сертификатом прописывается атрибут, ссылающийся на провайдер и ключ в виде структуры CRYPT_KEY_PROV_INFO. Функции верхнего уровня сами грузят ключ, а низкоуровневым функциям нужен handle от провайдера. Действительно микрософт может работать только с реестром и хранить ключи на дискете его (наверно) не удасться научить. | ||||
| ||||
| У меня возник тот же самый вопрос. Кто-нибудь разобрался с этим? CERT_PVK_FILE_PROP_ID - зачем он нужен? Функция CEnroll.addBlobPropertyToCertificate тоже его может использовать, но какой толк от этого? | ||||
Valentin