Hi, Other software using certs still have their own way to store and access them: eg firefox and opera browsers. Even Mozilla Thunderbird and Firefox store SEPARATELY their certs (!). I agree that things could be better but it is the way it is.
If M$ cryptoapi was a standard, maybe stunnel could use it to load certs and pass them to openssl, or -preferrably- specify a particular syntax to tell openssl to load them in that "standard manner". But it would add a huge amount of code for that, either in stunnel or openssl.
The same effect can be easily obtained by using M$ IE to export useful certs in a USER owned folder, to cer64 (ie pem) format, and then use these files in stunnel as usual. Every ordinary user can do that with a simple instruction.
"Subst" does in local the same job as "net use" on the network : mapping location (local for subst, remote for netuse) to a drive, so that -almost- the same startup script can be use to map drives and start stunnel, all this in a user context, not polluting other user context. Of course a script can use subst with something like this : subst z: %HOMEPATH% so that there is no need for a specific script per user.
Pierre
Le 06/09/2010 05:35, Jason Haar a écrit :
On 09/01/2010 09:02 PM, Michal Trojnara wrote:
I think this request should rather be addressed to the OpenSSL team. AFAIK Windows Certificate Store was specifically designed to prevent non-Microsoft SSL implementations from using it directly, i.e. without manual key export.
Hi Mike
You should look again - lots of non-M$ products use this API. e.g openvpn for Windows allows you to use the personal cert that other M$ components like MSIE uses - see " cryptoapicert"
--cryptoapicert select-string Load the certificate and private key from the Windows Certifi- cate System Store (Windows Only).
Use this option instead of --cert and --key. This makes it possible to use any smart card, supportedby Win- dows, but also any kind of certificate, residing in the Cert Store, where you have access to the private key. This option has been tested with a couple of different smart cards (GemSAFE, Cryptoflex, and Swedish Post Office eID) on the client side, and also an imported PKCS12 software certificate on the server side.