Thanks for reply, Jakob.
> Your are probably right. Microsoft CAPI essentially treats all its key > storages like physical smart cards, which means that by default, you cannot > extract the private key using any documented method (if at all), > ... It's confusing... OpenSSL provides an API that it is called ENGINE_load_private_key but which returns the PUBLIC key ?! Passing the EVP_PKEY structure returned from ENGINE_load_private_key to OpenSSL using SSL_CTX_use_PrivateKey seems to work... The server-client communication works as expected though, I guess, OpenSSL expects a private key in SSL_CTX_use_PrivateKey. Is this possible because I use a RSA key ? > ...but you (and thus the OpenSSL "CAPI Engine") can ask CAPI to use the key > to decrypt or sign something. > MS CAPI has an option to mark a private key as "exportable" when you create > or install it, which means that the private key can then be read > anyway, but I don't know if that feature is used by the OpenSSL "CAPI > Engine". It is almost always a good idea NOT to mark private keys as > exportable. Note that whatever is decided when the private key is first > stored by CAPI will be permanent (There is a 3 step workaround for making an > exportable key non-exportable, but any ability to go the > other way would compromise security just by being possible). Indeed, private keys are not exportable as long as they are not marked as such when the certificate is imported in the windows store. Unfortunately, I am forced to use boost::asio::ssl which (AFAIK) does not integrate with CAPI engine so I cannot ask it to sign or decrypt communication. Anyway, seems more secure, then, to have the private key in a file encrypted with a password, then keeping it in the windows store, if I want to pass it to OpenSSL (through boost::asio::ssl) :) ________________________________ From: Jakob Bohm <jb-open...@wisemo.com> To: openssl-users@openssl.org Sent: Thursday, December 6, 2012 12:23 PM Subject: Re: How to over-ride SSL_CTX_use_PrivateKey_file() behavior with custom engine On 12/6/2012 9:13 AM, LN wrote: > Hi, > > Somehow related to private keys but about loading them with CAPI > engine... Does someone know if the ENGINE_load_private_key() for CAPI > engine returns the PUBLIC KEY ? > I have a feeling it does so because I tried to save that returned > EVP_PKEY to a PEM file with PEM_write_bio_PrivateKey and then to load it > back from the same file with PEM_read_bio_PrivateKey. > Saving worked, but loading failed (with some decoding error inside > openss). The length of the base64 string in the PEM file for the key was > very small in comparision with what is usually the length for private keys. > > PEM_write_bio_PUBKEY and PEM_read_bio_PUBKEY worked with the returned > EVP_PKEY. > Your are probably right. Microsoft CAPI essentially treats all its key storages like physical smart cards, which means that by default, you cannot extract the private key using any documented method (if at all), but you (and thus the OpenSSL "CAPI Engine") can ask CAPI to use the key to decrypt or sign something. MS CAPI has an option to mark a private key as "exportable" when you create or install it, which means that the private key can then be read anyway, but I don't know if that feature is used by the OpenSSL "CAPI Engine". It is almost always a good idea NOT to mark private keys as exportable. Note that whatever is decided when the private key is first stored by CAPI will be permanent (There is a 3 step workaround for making an exportable key non-exportable, but any ability to go the other way would compromise security just by being possible). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org