Private key in User Store, Could not export private key - The parameter is incorrect (#-2146893785)

[mv2023 0]

Hello,

 

I have an application that needs to communicate with a server that asks for a digital certificate that is on a USB Token.
I solved the communication with that server with MSXML2.ServerXMLHTTP.6.0.

 

However, I would have liked to use your TsslHttpRest component.

 

For this I tried the OverbyteIcsHttpRestTst64 example.

I was not successful; the application displays 'SSL Client Certificate Requested by Server, But None to Send, Request May Fail'.

 

The USB token requires a password. With MSXML2.ServerXMLHTTP, the password dialog appears automatically at first use after the Token is inserted into the USB port.
The password can also be entered manually before the first use and I tried this with OverbyteIcsHttpRestTst64 but the result is the same.

 

I also tried setting 'MsCertTools.MsKeyProvider := MS_SMART_CARD_KEY_STORAGE_PROVIDER' but it has no effect.

 

The instruction 'Errs := MsCertTools.LoadOneFromStore(MsCertLoc, SslClientCertFile.Text, True)'
returns 'Can not find certificate and private key in Windows Store: XXXXXX'

 

If the Pkey parameter is false, the result is '' but MsCertTools.Comments is 'Private key in User Store, Could not export private key - The parameter is incorrect (#-2146893785)'.

I also tried with version 8.7 and with 9.1 daily build from 27.12.2023 and the result is the same

 

By the way, I think OverbyteIcsMsSslUtils line 1146 should be
if (Pos(Search, MyName) = 1) or (Pos(WildSearch, MyName) = 1) then

What am I doing wrong?
Thank you.

[Angus Robertson 577]

Digital certificates are sometimes distributed on USB tokens precisely to stop them being copied by software applications.  ICS can only access private keys that are stored in local windows store. 

 

The USB token is not a simple storage device, it has an operating system that allows applications to pass data to the token, which is then signed by the private key and passed back to the application as a hash.  This signing is normally done by a Windows or OpenSSL API, and they need to be aware of the token and use that instead.   All token suppliers provide drivers that allow Windows applications to use their tokens, but not usually for OpenSSL. 

 

OpenSSL needs extra code to access USB tokens, in the obsolete versions it was called an engine, with 3.0 and later it's called a provider, but it's just another DLL.  I understand there are OpenSSL providers to allow use signing with USB tokens, but they are supplied as C source code not Windows DLLs, and I've never tried any.  

 

Integrating such a provider into ICS would not be quick, or maybe some-one has done it already?

 

Angus

 

[mv2023 0]

So for now ICS is a closed road in this direction.

 

Thanks Angus,
A happy new year.

[Angus Robertson 577]

Sorry, no quick solution.  There are OpenSSL providers to access private keys on TPM2 devices and to access certificates in the Windows Store (which ICS can now do), but not to access the Windows crypto signing APIs so that other dongles can be supported, at least to my knowledge.

 

Angus

 

[DelphiUdIT 187]

"MS_SMART_CARD_KEY_STORAGE_PROVIDER" is useless with smartcard.

All the smartcards I have used are not read through that provider, but only through their own provider, which can be listed via CNG (CryptoApi Next Generation). So far I've only used Common Name (CN) access without using the password key for my purposes, and I was planning to move forward to specifically use a smartcard with Indy (but obviously it could work for ICS too). But time is running out and I don't know when I will be able to continue.