SSL-соединение, хранилище сертификатов Windows и механизм CAPI

Я создаю соединение SSL с помощью OpenSSL API. Как мы знаем, при рукопожатии SSL серия аутентификаций сертификатов происходит для сервера или клиента. Теперь для проверки подлинности сертификата клиента сертификат клиента и связанный с ним закрытый ключ хранятся в Windows Certificate Store.

Этот сертификат с private key импортируется в хранилище после их объединения в формат pfx, а затем этот файл pfx импортируется в хранилище сертификатов Windows. Теперь при импорте этого pfx-файла с помощью оснастки mmc он спрашивает, хотим ли мы сделать закрытый ключ exportable или нет. Теперь на сцену выходит OpenSSL для создания SSL-соединения.

Для этого нам нужно создать объект SSL_CTX, в который загружены все свойства, связанные с соединением. Теперь для загрузки закрытого ключа из хранилища сертификатов Windows в объект SSL_CTX я отметил этот закрытый ключ exportable, который я экспортирую с помощью Crypto API. Но я думаю, что помечать закрытый ключ как экспортируемый не имеет никакого смысла, это нарушение безопасности.

Поскольку закрытый ключ всегда будет помечен Non-Exportable, существует ли какой-либо метод или API OpenSSL и т. д., который может напрямую считывать и загружать закрытый ключ из хранилища сертификатов Windows в объект SST_CTX для установления соединения SSL.

Я точно знаю, что есть какой-то способ, чтобы это сработало, но я не понимаю. Я много искал это, но не нашел нужной вещи.

Обобщенный вопрос. Хранилище сертификатов содержит множество сертификатов и связанных закрытых ключей. Как осуществляется доступ к сертификатам и закрытым ключам при установлении соединения SSL?

EDIT: я прошел через API механизма openssl под названием

 `EVP_PKEY *ENGINE_load_private_key(ENGINE *e, const char *key_id,
      UI_METHOD *ui_method, void *callback_data);`

Теперь, как я могу получить этот key_id закрытого ключа, а также я думаю, что этот API внутренне называется криптографическим API CryptExportKey, и этот API терпит неудачу, если закрытый ключ помечен non-exportable.


ssl openssl private-key certificate-store cryptoapi
person User1234    schedule 31.12.2015    source источник
comment
См. Использование хранилища сертификатов Windows через OpenSSL в списке рассылки OpenSSL. Stack Overflow, вероятно, мог бы использовать хороший пример этого (я не знаю, что он существует).   -  person jww    schedule 01.01.2016
comment
@jww Спасибо за предоставленную ссылку. Это было немного полезно. Но проблема здесь заключается в том, чтобы использовать закрытый ключ из Магазина, фактически не экспортируя его для создания SSL-соединения.   -  person User1234    schedule 01.01.2016
comment
Механизм CAPI должен использовать CAPI для выполнения операций с закрытым ключом, поэтому экспорт не нужен. Неважно, где вы его используете — Подписание, Проверка, SSL-соединение и т. д. Если вы хотите экспортировать закрытый ключ (<insert reason here>), то это немного другая проблема. .   -  person jww    schedule 01.01.2016
comment
Я не помню наизусть, но если я правильно помню (прошло некоторое время с тех пор, как я играл с этим), вы можете создать механизм сертификатов (это объект Windows), который автоматически проверяет сертификаты для вас.   -  person TCS    schedule 01.01.2016
comment
@TCS спасибо за беспокойство. Но на самом деле проблема, с которой я сталкиваюсь, связана с закрытым ключом. Закрытый ключ присутствует в магазине Windows (помечен как неэкспортируемый). Теперь для создания сеанса SSL мне нужно загрузить этот закрытый ключ в объект ssl, используя SSL_CTX_use_PrivateKey API openssl.   -  person User1234    schedule 02.01.2016
comment
@jww: - я прошел API-интерфейсы capi engine. Во-первых, для создания SSL-соединения с использованием openssl мы должны загрузить закрытый ключ в объект ssl_ctx для вызова SSL_CTX_use_PrivateKey (openssl api). Теперь для этого механизма capi предоставляется capi_load_privkey' that internally exports the открытый ключ API, а не private key. Я не нахожу никакого другого API-интерфейса capi engine, который позволяет нам использовать закрытый ключ из самого хранилища без его фактического экспорта.   -  person User1234    schedule 02.01.2016
comment
Я не знаю, может ли openssl работать напрямую с магазином Windows таким образом.   -  person TCS    schedule 02.01.2016
comment
Это выглядит уместно: присоединить контекст ENGINE к SSL_CTX. К сожалению, нет полезных ответов. Вот что-то похожее с ответами: Как сгенерировать сертификат, если закрытый ключ находится в HSM? Но это не соответствует вашим требованиям.   -  person jww    schedule 02.01.2016
comment
@jww Означает ли это, что я иду в неправильном направлении для достижения того, чего хочу?   -  person User1234    schedule 02.01.2016
comment
@ User1234 — вот ветка обсуждения, которую вы ищете: Как переопределить поведение SSL_CTX_use_PrivateKey_file() с пользовательским движком. Техы даже обсуждают MS-CAPI. Обратите внимание на ответ доктора Хенсона. Он один из разработчиков OpenSSL. У Джейкоба также есть хорошая информация, но я склоняюсь к ответу разработчика OpenSSL.   -  person jww    schedule 03.01.2016
comment
@jww Спасибо, ссылка действительно очень полезна. Но проблема все еще сохраняется, потому что в этом обсуждении они пытаются загрузить, т.е. экспортировать закрытый ключ из магазина Windows, но это невозможно, поскольку закрытый ключ помечен как НЕЭКСПОРТИРУЕМЫЙ. Итак, вопрос снова зацикливается на том, как использовать неэкспортируемый закрытый ключ из самого хранилища сертификатов Windows (без экспорта) при аутентификации клиента?   -  person User1234    schedule 10.01.2016
comment
Эквиваленты .net tls, которые я использовал для OpenSSL (HTTPClient и Tcpclient+Sslstream), похоже, только косвенно обращаются к неэкспортируемым закрытым ключам. Вы сообщаете API, как найти нужные ключи с помощью запроса, и вы возвращаете объект коллекции сертификатов, но я думаю, что он имеет дескриптор только закрытых ключей, а не самих закрытых ключей. Это, кажется, указывает на то, что API делает то, что нужно TLS, и скрывает все за слоем абстракции. Итак... Интеграция OpenSSL на нужном вам уровне мне не кажется практичной.   -  person Timothy John Laird    schedule 06.11.2017