[xmlsec] Unable to verify Multiple <X509Certificate> in a single signed XML
Naval Patel
www.naval.com at gmail.com
Tue Dec 28 08:27:43 PST 2010
Hi Aleksey,
I tried to verify the test file which is placed on your website at [
http://www.aleksey.com/xmlsec/tests/aleksey-xmldsig-01/enveloping-dsa-x509chain.xml]
using online tool present on your site as well as using a locally placed
xmlsec.exe. The command i am using locally is
xmlsec.exe --verify signature.xml [Please tell me if I am not using the
command correctly]
I error I get is still the same after all the different efforts i have put
in.
The current procedure i am following is:
1. Read the signature.xml file and add each certificate as trusted pem.
2. in X509_vfy.c, i would delete all the certs which are not self-signed or
intermediate CA.
The verification succeeds in this way of verification.
The risk i see in this process is that I am simply trusting any certificates
that are present in the signature.xml which is a big threat.
Will be extremely glad to know your response at your earliest.
Regards,
Naval.
On Wed, Dec 22, 2010 at 11:32 AM, Naval Patel <www.naval.com at gmail.com>wrote:
> This is the error when root CA is in the signed xml
>
>
> func=xmlSecOpenSSLX509StoreVerify:file=d:\svn_simulator\white\products\76xx\app\module\wrtconfig\wrtconfig\external\libxmlsec\src\openssl\x509vfy
> .c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto library
> function
> failed:subj=/C=IN/ST=Mah/L=Pune/O=Agreeya/OU=Almond/CN=rootca/emailAd
> dress=rootca at agreeya.com;err=19;msg=self signed certificate in certificate
> chain
>
> func=xmlSecOpenSSLX509StoreVerify:file=d:\svn_simulator\white\products\76xx\app\module\wrtconfig\wrtconfig\external\libxmlsec\src\openssl\x509vfy
> .c:line=408:obj=x509-store:subj=unknown:error=71:certificate verification
> failed:err=19;msg=self signed certificate in certificate chain
>
> this is the error when root ca is not in the signed xml, but passed
> explicitly as trusted.
>
>
> func=xmlSecOpenSSLX509StoreVerify:file=d:\svn_simulator\white\products\76xx\app\module\wrtconfig\wrtconfig\external\libxmlsec\src\openssl\x509vfy
> .c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto library
> function
> failed:subj=/C=IN/ST=Maharashtra/L=Pune/O=Agreeya/OU=Almond/CN=ca1/em
> ailAddress=ca1 at agreeya.com;err=24;msg=invalid CA certificate
>
> func=xmlSecOpenSSLX509StoreVerify:file=d:\svn_simulator\white\products\76xx\app\module\wrtconfig\wrtconfig\external\libxmlsec\src\openssl\x509vfy
> .c:line=408:obj=x509-store:subj=unknown:error=71:certificate verification
> failed:err=24;msg=invalid CA certificate
>
>
> Thanks,
> Naval.
>
>
> On Wed, Dec 22, 2010 at 11:27 AM, Aleksey Sanin <aleksey at aleksey.com>wrote:
>
>> Could you please copy/paste the complete error?
>>
>> Aleksey
>>
>>
>> On 12/21/10 9:56 PM, Naval Patel wrote:
>>
>>> If the entire cert chain is in the signed document the error i get is
>>> msg=self signed certificate in certificate chain
>>>
>>> if i remove the Root certificate from the chain in the signed xml file,
>>> and pass a root certificate as trusted, then i get the error as
>>> msg=invalid CA certificate
>>>
>>> is there something that i am missing or this is not the right way to do?
>>>
>>> thanks :)
>>>
>>> Naval.
>>>
>>> On Tue, Dec 21, 2010 at 9:24 PM, Aleksey Sanin <aleksey at aleksey.com
>>> <mailto:aleksey at aleksey.com>> wrote:
>>>
>>> What errors do you get?
>>>
>>> Aleksey
>>>
>>>
>>> On 12/21/10 12:38 AM, Naval Patel wrote:
>>>
>>> Hi,
>>>
>>> Its been quite some time i am modifying my code to allow a
>>> signed xml
>>> document containing the entire chain of certificates from "Local
>>> cert"
>>> through CAs and ultimately the Root CA. I have debugged the code
>>> till
>>> the call goes to *X509_verify_cert(&xsc)*. I have observed that
>>> for each
>>> *<X509Certificate> *the xmlsec adds the certificate to the
>>> X509_STACK.
>>> The function call (*xmlSecOpenSSLX509FindNextChainCert*) inside
>>> the *for
>>> loop* inside the function *xmlSecOpenSSLX509StoreVerify* with the
>>> comment [/* get one cert after another and try to verify */]
>>> returns
>>> NULL only when it finds that the certificate does not extend any
>>> other
>>> certificates.
>>>
>>> I have RootCa.pem > CA1.pem > CA2.pem > signerCert.pem.
>>>
>>> If i simply execute the signeddoc.xml, I am receiving the error
>>> [*msg=invalid CA certificate* for CA2.pem] ... the command used is
>>> *xmlsec.exe verify --trusted-pem RootCa.pem signeddoc.xml*
>>> I broke the certificate chain by removing RootCa.pem from the
>>> signeddoc.xml and the error i received is same as of the above
>>> case
>>> *xmlsec.exe verify --trusted-pem RootCa.pem signeddoc.xml
>>> *I changed the command for the above file as *xmlsec.exe verify
>>> --trusted-pem RootCa.pem --trusted-pem CA2.pem signeddoc.xml*,
>>> still the
>>> error was same
>>> I maintained only CA1, CA2 and signerCert.pem in signeddoc.xml
>>> and used
>>> the command *xmlsec.exe verify --trusted-pem RootCa.pem
>>> --trusted-pem
>>> CA1.pem --trusted-pem CA2.pem signeddoc.xml
>>> *Now I removed CA2 from the signeddoc.xml and kept only CA1 and
>>> signerCert.pem, and used the command *xmlsec.exe verify
>>> --trusted-pem
>>> RootCa.pem --trusted-pem CA1.pem --trusted-pem CA2.pem
>>> signeddoc.xml ...
>>> *i could see that the verification was passing.
>>>
>>> I have deviced another way too to make this work, but i am not
>>> sure how
>>> good this way is...
>>>
>>> before passing the signeddoc.xml to xmlsec, I load the
>>> x509certificate
>>> as trusted using the api *xmlSecCryptoAppKeysMngrCertLoadMemory*
>>> but the
>>> problem is not solved because the same document continues to be
>>> evaluated by xmlsec later and the results produced are same.
>>>
>>> Another alternative i thought was once the function
>>> *xmlSecOpenSSLX509FindNextChainCert *returns NULL, I would
>>> remove the
>>> other certificates from the STACK. That way, i will have trusted
>>> certs
>>> loaded to the global stack and while signerCert.pem is verified.
>>>
>>> Please let me know your suggestions, I will try your suggested
>>> methods.
>>>
>>> And thanks a lot for this library, it had done wonders for my
>>> work till
>>> now :)
>>>
>>> I had read an email from the archive
>>> [*http://www.aleksey.com/pipermail/xmlsec/2008/008326.html*], but
>>> i
>>> could not get the break through yet :(
>>>
>>> Regards,
>>> Naval
>>>
>>>
>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
>>>
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>
>>>
>>>
>>>
>>> --
>>> Naval Patel
>>> ~ have fun ~
>>>
>>
>
>
> --
> Naval Patel
> ~ have fun ~
>
--
Naval Patel
~ have fun ~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20101228/6c4851f5/attachment.html>
More information about the xmlsec
mailing list