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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>
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: [email protected] <mailto:[email protected]>
VOIP Address: [email protected]
<mailto:[email protected]>
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: [email protected] <mailto:[email protected]>
VOIP Address: [email protected] <mailto:[email protected]>
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: [email protected] <mailto:[email protected]>
VOIP Address: [email protected] <mailto:[email protected]>
VOIP DID#: 613-458-5004
Skype ID: edward.shallow
Home Phone: 613-482-2090
_______________________________________________
xmlsec mailing list
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
_______________________________________________
xmlsec mailing list
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
