[xmlsec] mscrypto 1.2.18 key is not found
Aleksey Sanin
aleksey at aleksey.com
Mon Jul 11 19:45:40 PDT 2011
Great find, Ed! Thanks a lot! I would love to make it parametrized but
as I mentioned
I don't have Windows environment nowdays. But I do accept patches :)
Aleksey
On 7/11/11 7:42 PM, EdShallow wrote:
> PostScript ...
>
> Really, this behavior should be paramaterized via a setter method
> on a SILENT flag exactly as MS does it.
>
> Cheers,
> Ed
>
> On Mon, Jul 11, 2011 at 10:35 PM, EdShallow <ed.shallow at gmail.com
> <mailto:ed.shallow at gmail.com>> wrote:
>
> OK guys, I found the source of the changed behavior in 1.2.18
>
> It is in certkeys.c and relates to the SILENT flag below ...
>
> if (!CryptAcquireCertificatePrivateKey(pCert,
> CRYPT_ACQUIRE_SILENT_FLAG |
> CRYPT_ACQUIRE_COMPARE_KEY_FLAG,
> NULL,
> &hProv,
> &(ctx->dwKeySpec),
> &fCallerFreeProv)) {
> xmlSecError(XMLSEC_ERRORS_HERE,
> NULL,
> "CryptAcquireCertificatePrivateKey",
> XMLSEC_ERRORS_R_CRYPTO_FAILED,
> XMLSEC_ERRORS_NO_MESSAGE);
> return(-1);
>
> If one removes the CRYPT_ACQUIRE_SILENT_FLAG and re-compiles, then
> the old behavior can be achieved. In other words, with the removal
> of this flag, one will be prompted for the MSCRYPTO KeyName and
> password to login to (i.e. acquire) the key-pair as was the case
> with XMLSec 1.2.13 where this was the default behavior.
>
> Hope this helps those using XMLSec on the workstation as opposed
> to on the server where clearly a modal dialog prompt is not desirable.
>
> Cheers,
> Ed
>
> On Wed, Jun 22, 2011 at 1:09 AM, EdShallow <ed.shallow at gmail.com
> <mailto:ed.shallow at gmail.com>> wrote:
>
> Some updates with respect to mscrypto 1.2.18
>
> The "key is not found" error with 1.2.18 is misleading. In
> fact what is happening is that when specifying a KeyName for a
> certificate associated with its private key in a key store
> that is not "logged in", you get the "key is not found" error.
>
> If the CSP's container allows you to log in to the key store
> prior to usage, then XMSec mscrypto will succeed as long as
> the session with the private key has been logged in.
>
> Now please be aware not all CSPs allow you to login in advance
> of searching the certificate and adopting the key. In fact
> most don't and prompt at first programmatic usage (i.e.
> adoption or context acquire).
>
> The only CSP I have tried (and this is how I found the
> problem) is Entrust's CAPI CSP called Entrust Service Provider
> for Windows version 9.1. If I login to my Entrust key store
> before running an XMLSec sign operation, it works. If I am NOT
> already logged in to my Entrust key store when I executed the
> XMLSec command, it fails. Additionally the error message
> generated by XMLSec is not indicative of really what is happening.
>
> The standard Microsoft Cryptographic Service Provider and the
> Microsoft Enhanced Cryptographic Service Provider do NOT allow
> this login in advance of usage. A login dialog box appears
> only when your CAPI code attempts to acquire the certificate
> context and use the key for signing. Any use of these 2 CSPs
> fails with XMLSec 1.2.18.
>
> This "key is not found" behavior does NOT happen with 1.2.10,
> 1.2.11, 1.2.13 all of which work fine.
>
> When using these earlier versions of XMLSec, a dialog box with
> login prompt is presented as a result of key adoption and
> everything works fine after a successful password is entered.
> The dialog re-prompts until the correct password is provided.
> This is expected behavior.
>
> All this testing was done with Igor's 1.2.18 Unicode=yes
> binaries which do not crash but do exhibit the incorrect
> behavior described above. I did not test much with the
> Unicode=no binaries as soon as I encountered the crashes.
>
> I am not sure what triggers the dialog box with the key
> protection password prompt, but this is the error with 1.2.18.
> All earlier versions before 1.2.13 DO trigger this dialog box
> correctly.
>
> Hope this helps,
> Ed
>
>
>
>
> On Tue, Jun 21, 2011 at 4:38 PM, Roumen Petrov
> <xmlsec at roumenpetrov.info <mailto:xmlsec at roumenpetrov.info>>
> wrote:
>
> EdShallow wrote:
>
> OK guys, here is the story with mscrypto:
>
> [SNIP]
>
> throughout the above tests. it is clear that the
> mscrypto code somewhere
> after 1.2.13 has introduced the error.
>
> [SNIP]
> One change , if i remember well , is CP_ACP -> CP_UTF8 .
> It is based on request posted to the list.
> I don't have environment to test. Probably this could be
> issue, but you report ascii(latin1) names and I'm not sure
> that this modification is reason for failure.
>
> If "Shallow, Ed" and "Adam Grossman" work fine with 1.2.13
> there is not reason to fail if CP_ACP -> CP_UTF8.
>
> Also I'm afraid with report like "openssl sign with .p12 -
> crash". I don't know what to say .
>
>
> Roumen
>
>
>
>
> --
> Ed's Contact Information:
> Mobile Phone: 613-852-6410 <tel:613-852-6410>
> Gmail: ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>
> VOIP Address: 107529 at sip.ca1.voip.ms
> <mailto:107529 at sip.ca1.voip.ms>
> VOIP DID#: 613-458-5004 <tel:613-458-5004>
> Skype ID: edward.shallow
> Home Phone: 613-482-2090 <tel:613-482-2090>
>
>
>
>
> --
> Ed's Contact Information:
> Mobile Phone: 613-852-6410 <tel:613-852-6410>
> Gmail: ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>
> VOIP Address: 107529 at sip.ca1.voip.ms <mailto:107529 at sip.ca1.voip.ms>
> VOIP DID#: 613-458-5004 <tel:613-458-5004>
> Skype ID: edward.shallow
> Home Phone: 613-482-2090 <tel:613-482-2090>
>
>
>
>
> --
> Ed's Contact Information:
> Mobile Phone: 613-852-6410
> Gmail: ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>
> VOIP Address: 107529 at sip.ca1.voip.ms <mailto:107529 at sip.ca1.voip.ms>
> VOIP DID#: 613-458-5004
> Skype ID: edward.shallow
> Home Phone: 613-482-2090
>
>
>
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20110711/53018cc2/attachment.html>
More information about the xmlsec
mailing list