| 10.05.2007 15:47:08 | Копирование ключевого контейнера с одного носителя на другой. В дальнейшем требует носитель-"оригинал" | | Ответов: 12 |
|
 Кирилл | | |
|
| Возникла следующая проблема - был выдан сертификат и закрытый ключ был записан на дискету. Впоследствии, последний был скопирован на ru-token. Почему-то теперь при вызове CryptAcquireCertificatePrivateKey(..., CRYPT_ACQUIRE_CACHE_FLAG,...) выпадает окно со списком носителей, где в качестве ключевого ожидается только дискета, про ru-token нет ни одного упоминания. Каким образом решить данную проблему? Причем, в некоторых случаях вроде как контейнер находится... |
| |
Ответы:
|
| 10.05.2007 16:04:25 | Kirill Sobolev |
|
| Надо переустановить сертификат, привязав его именно к контейнеру на рутокене. |
|
| 10.05.2007 16:35:38 | Кирилл |
|
Спасибо.
А в дальнейшем будет возможность в CryptoPro CSP работать с несколькими контейнерами? |
|
| 10.05.2007 17:54:34 | Kirill Sobolev |
|
| Работой со связкой сертификат-контейнер занимается не КриптоПро CSP, а Windows. Соответственно, это вопрос к MS. |
|
| 11.05.2007 11:41:31 | Кирилл |
|
| Была произведена операция - сертификат был удален из хранилища "Личные". Потом через панель управления КриптоПро Сервис-Просмотреть сертификаты в контейнере был выбран контейнер с сертификатом на ruToken, установлен. Но в дальнейшем произошла опять такая же ошибка - требовался контейнер с дискеты. Что можно сделать еще? |
|
| 11.05.2007 12:03:37 | Kirill Sobolev |
|
| Устанавливали тоже через контрольную панель КриптоПро CSP - Сервис - Установить личный сертификат? |
|
| 11.05.2007 12:25:57 | Кирилл |
|
| И так тоже пробовал. Удалил сертификат, предварительно его экспортировав в файл. Потом сделал установку личного сертификата, связав этот файл с новым контейнером. Причем, контейнер, находящийся на дискете, тоже удалил через панель КриптоПро. |
|
| 11.05.2007 13:40:13 | Kirill Sobolev |
|
Значит проблема в старой ссылке - она попала в кэш CryptoAPI. CryptAcquireCertificatePrivateKey этим грешит.
Удалите из \Documents and Settings\<имя пользователя>\Application Data\Microsoft\SystemCertificates\My\Keys\ файл, в котором эта ссылка содержится, либо вызывайте CryptAcquireContext через CRYPT_KEY_PROV_INFO. |
|
| 11.05.2007 13:49:46 | Кирилл |
|
| Что интересно, если получать контекст сертификата через возможности Capicom, через его графический интерфейс (IStorePtr), то функция CryptAcquireCertificatePrivateKey отрабатывает нормально со ссылкой на рутокен. Если же получать контекст через CertCreateCertificateContext, т.е. по наборам байт, то происходит вышеописанная ситуация. |
|
| 11.05.2007 15:41:30 | Кирилл |
|
А каким образом можно определить, какая ссылка старая? Сделать так получилось методом тыка.
Так же заметил, что не используя возможности капиком, последующий вызов CryptAcquireCertificatePrivateKey не использует кэш связей (после переименовывания папки с ключами она задумалась, но связь в итоге нашла автоматически). В случае с получением контекста сертификата из набора байт - CryptAcquireCertificatePrivateKey давала отлуп сразу. |
|
| 11.05.2007 16:03:54 | Кирилл |
|
И еще.
CertEnumCertificateContextProperties возращает, что у сертификата нет никаких свойств! Соответственно, CRYPT_KEY_PROV_INFO не получить. В то время как, вернувшись к выбору сертификата через Capicom, все находится. Почему так? Где теряются все ссылки и свойства? |
|
| 14.05.2007 10:01:38 | Kirill Sobolev |
|
Когда Вы создаете сертификат через CertCreateCertificateContext, то он не привязан ни к какому хранилищу и ссылки на секретный ключ у него нет.
CryptAcquireCertificatePrivateKey находит закешированную ссылку, которая была прописана при установке. CAPICOM же выбирает сертификат из хранилища, а там есть актуальная ссылка. |
|
| 14.05.2007 10:41:56 | Кирилл |
|
| Спасибо большое, это дает ответы на все. |
|
