Cert validation errors (was RE: [xmlsec] 0.0.8a build error on Win32)

Aleksey Sanin aleksey at aleksey.com
Wed Aug 28 18:03:45 PDT 2002

Please take a look at your file. It has public RSA key after the 
The xmlsec fails to verify cert but after this it is able to find good 
key in the
<sig:RSAKeyValue /> element. And XMLSec is perfectly happy with it :)
For example, if you run the xmlsec utility with '--allowed x509' option then
you'll have something like this:

[aleksey@/tmp/test]$ xmlsec verify --allowed x509 --print-all 
xmlSecX509DataNodeRead (keyinfo.c:1191): error 31: cert verification 
failed :
xmlSecKeyValueNodeRead (keyinfo.c:670): error 16: invalid key origin : 
xmlSecKeysMngrGetKey (keys.c:451): error 17: key not found :
xmlSecSignedInfoRead (xmldsig.c:1385): error 17: key not found :
xmlSecSignatureRead (xmldsig.c:1124): error 2: xmlsec operation failed : 
ignedInfoRead - -1
xmlSecDSigValidate (xmldsig.c:729): error 2: xmlsec operation failed : 
natureRead - -1
Error: operation failed


Moultrie, Ferrell (ISSAtlanta) wrote:

>  There is only one key and it's only certified by one CA, a self-signed
>root CA. So, w/o the PEM file, it must fail. I'm attaching a test
>document to this e-mail. Try:
>  xmlsec verify --print-all test_allkey_99.xml
>It says everything is cool (except the cert validation error) -- but it
>can't really be OK since there's no way to verify the cert w/o a trusted
>root specification.
>  xmlsec verify --print-all --trusted new_export.pem test_allkey_99.xml 
>The above works completely because the root of the cert can be
>validated. The issue appears to be that there must be at least one key
>whose certification passes *and* one of those certifiable keys must be
>used to validate the signed hash. Anything less is a security problem
>because anyone can resign the document with any key they choose based on
>a self-signed root and that root will be trusted -- the validation will
>succeed and there's no real way to tell it didn't. As you point out, I
>can't merely look for a cert validation error -- since the cert that
>fails may not be needed to validate the signature. Somehow xmlsec *has*
>to ensure that any key it reports success on must have been validated by
>a trusted cert chain.
>  Ferrell
>-----Original Message-----
>From: Aleksey Sanin [mailto:aleksey at aleksey.com] 
>Sent: Wednesday, August 28, 2002 7:59 PM
>To: Moultrie, Ferrell (ISSAtlanta)
>Cc: xmlsec at aleksey.com
>Subject: Re: [xmlsec] 0.0.8a build error on Win32
>Not necessary. Suppose your are signing a message with a key and
>provide more than one certificate for this key (for example, signed by
>root CAs A and B). It is possible that one of your recipients trusts
>the root CA A but not B and another trusts root CA B and not A.
>Then in this case *both* recipients will be able to successfully
>the message and both of them will have the same error.
>I believe that in your case the message verification succeeds because
>XML Sec library was able to find correct keys for the message in some
>other place (another cert, keys manager, etc.). From my point of view,
>this is a correct behavior and the verification *must* succeed (see
>scenario above).
>Moultrie, Ferrell (ISSAtlanta) wrote:
>> One other question .. when xmlSecDSigValidate() returns I'm getting a
>>return code of zero, and pResult->result is equal to
>>xmlSecTransformStatusOk. According to the doc, that means it worked.
>>However, down in the guts of x509 verification, the following error is
>>being generated: "error 31: cert verification failed : ".
>>while that does result in a callback to the default error handler, it
>>doesn't result in any final error status from the verification routine.
>>So, unless I monitor the error handler, I don't know that the error
>>occurred. In this case, because the uncertified public key is really OK
>>and the hash is OK and the data is OK, the verify returns OK -- but it
>>really isn't OK because I forgot to supply the PEM data needed to
>>authenticate the certificate. Shouldn't this have resulted in a
>>Verification with an invalid cert really isn't validation of the
>>signature, IMO. 
>> Ferrell
>>-----Original Message-----
>>From: Aleksey Sanin [mailto:aleksey at aleksey.com] 
>>Sent: Wednesday, August 28, 2002 7:36 PM
>>To: Moultrie, Ferrell (ISSAtlanta)
>>Cc: xmlsec at aleksey.com
>>Subject: Re: [xmlsec] 0.0.8a build error on Win32
>>Thanks for reporting the problem! I am really sucks :(  and I am doing
>>build right now. For 0.0.8 release I've tried to use a new box for
>>builds but looks like it was really WRONG idea. I did 0.0.9 release on
>>old box and now smoke testing it.  Should be done in 15-30 minutes.
>>Sorry for the inconvinience,
>>Moultrie, Ferrell (ISSAtlanta) wrote:
>>>When I try to build 0.0.8a, I get an error:
>>>D:\xmlsec-0.0.8\src\enveloped.c(24) : fatal error C1083: Cannot open
>>>include file: 'xmlsec/xpath.h': No such file or directory
>>>I don't see an xmlsec/xpath.h in the xmlsec distribution (there is one
>>>in libxml2 -- but this specifically asks for xmlsec/xpath.h). 
>>>If I simply comment out the line:
>>>//#include <xmlsec/xpath.h>
>>>.. then everything builds OK.
>>>Am I missing something? This same error persists in the 020828 daily
>>>build also.
>>>Ferrell Moultrie (ferrell at iss.net)
>>>Software Engineer
>>>Internet Security Systems, Inc.
>>>6303 Barfield Road
>>>Atlanta, Georgia 30328
>>>Phone:  404-236-2600
>>>Direct: 404-236-2849
>>>Fax:    404-236-2632
>>>Internet Security Systems -- The Power to Protect
>>>xmlsec mailing list
>>>xmlsec at aleksey.com
>>xmlsec mailing list
>>xmlsec at aleksey.com
><ISSKeys Source="ISS Atlanta"><!-- TestKey ISS keygen -->
><Contacts><Contact><Keys Address1="2626 Somewhere Lane" Address2="suite 200A" City="Atlanta" Country="US" Email="keys at iss.net" Fax="778-555-1212" Phone="777.555.1212" PostCode="30064" Weburl="http://web.fubar.net"></Keys><CustomerRelations Address1="1313 knowwhere Lane" Address2="suite 300A" City="Atlanta" Country="US" Email="customer_relations at iss.net" Fax="778-555-7799" Phone="777.555.7788" PostCode="30064" Weburl="http://web.customer_relations_iss.net"></CustomerRelations><Support Address1="1234 Anvil Rd." Address2="suite 440B" City="Atlanta" Country="US" Email="support at iss.net" Fax="778-555-7755" Phone="777.555.7744" PostCode="30064" Weburl="http://web.suport_iss.net"></Support><Version>1.0</Version><OCN>163444</OCN><Source>ISS Atlanta</Source><Serial>ACC64BB4-A53D-AC83-3E6F-E0AB737DEC9D</Serial><Timestamp>2000-06-14 10:34:09</Timestamp><sig:Signature xmlns:sig="http://www.w3.org/2000/09/xmldsig#">
><sig:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></sig:CanonicalizationMethod>
><sig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></sig:SignatureMethod>
><sig:Reference URI="">
><sig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
> and (
>    (ancestor-or-self::node() = /ISSKeys/Contacts/Contact) 
><sig:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"></sig:Transform>
><sig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></sig:DigestMethod>
></sig:Signature></Contact></Contacts><EndUsers><EndUser Address1="666 Rockets way" Address2="Apt. B" City="Scienceville" CompanyName="Spacely Sprockets" Country="US" Email="gjetson at sprokets.net" PostCode="" State="Disturbed" SubjectName="George Jetson" Title="Whipping Boy"><Version>1.0</Version><OCN>163444</OCN><Source>ISS Atlanta</Source><Serial>CE8135D7-8D27-4BC4-BCA6-2DBDE703B6AE</Serial><Timestamp>2000-06-14 10:34:09</Timestamp></EndUser></EndUsers><LicensedModules><LicensedModule ContactInfo="ACC64BB4-A53D-AC83-3E6F-E0AB737DEC9D" EndUserInfo="CE8135D7-8D27-4BC4-BCA6-2DBDE703B6AE" Identity="RO" LicenseExpiration="2003-06-14" LicenseType="evaluation" Limit="2147483647" LimitOutOfMaintenance="0" MaintenanceExpiration="2003-06-14"><Version>1.0</Version><OCN>163444</OCN><Source>ISS Atlanta</Source><Serial>F61BD0F3-D5D9-2F90-A24D-BF989200D712</Serial><Timestamp>2000-06-14 10:34:09</Timestamp></LicensedModule></LicensedModules></ISSKeys>

More information about the xmlsec mailing list