<div dir="ltr">Wonderful, thanks Aleksey. This looks promising. I'll dig into this and see if I can make it work.<div><br></div><div style>Paul</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 14, 2013 at 6:57 PM, Aleksey Sanin <span dir="ltr"><<a href="mailto:aleksey@aleksey.com" target="_blank">aleksey@aleksey.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Take a look at this function. I think it might help with some of the<br>
issues you are having:<br>
<br>
<a href="https://www.openssl.org/docs/ssl/SSL_CTX_set_cert_verify_callback.html" target="_blank">https://www.openssl.org/docs/ssl/SSL_CTX_set_cert_verify_callback.html</a><br>
<br>
On the xmlsec-openssl side, you need to understand the<br>
xmlSecOpenSSLX509FindCert() function. In particular, I believe you<br>
need to make sure that ski search (last if block) works with you certs.<br>
<br>
Does it make sense?<br>
<br>
<br>
<br>
Aleksey<br>
<div><div class="h5"><br>
On 2/14/13 4:41 PM, Paul Hinze wrote:<br>
> Hello Aleksey et al,<br>
><br>
> Thanks for all your work on XMLSec, and apologies in advance for the<br>
> long mail.<br>
><br>
> I'm working on a library in Ruby that uses ruby-ffi to interop with XMLSec.<br>
><br>
> The goal is to implement a sufficient subset of XMLSec functionality to<br>
> allow it to serve as a valid backend for the ruby-saml library, which<br>
> currently uses its own home-grown implementation of XML security<br>
> standards. I believe that will allow ruby-saml to handle XML security<br>
> considerations more "correctly" as well as provide the opportunity to<br>
> have ruby-saml support signing, encrypting  and decrypting (which it<br>
> currently does not).<br>
><br>
> I've got a basic framework up and running with a few passing tests, but<br>
> now that I'm trying to exercise my code with a sample of real world SAML<br>
> requests, I'm running into trouble with xmlSecDSigCtxVerify (with<br>
> OpenSSL for crypto) refusing to verify signatures for which it cannot<br>
> build a proper CA chain.<br>
><br>
> As far as I understand it, the de facto trust model for SAML<br>
> integrations is to check the fingerprint of the signing certificate<br>
> against a pre-shared fingerprint stored by the consumer when the trust<br>
> relationship is established. Provided the fingerprint matches that of<br>
> the signing cert, and provided the XML signature is verified against<br>
> that cert, everything is assumed to be peachy.<br>
><br>
> Now, I'm aware that this trust model may be flawed, and I'm also aware<br>
> that this model goes against the grain of the "web of trust" concept<br>
> that OpenSSL is built on.<br>
><br>
> My question is whether it's technically feasible to utilize XMLSec to<br>
> support this model. Essentially I need to be able to verify signatures<br>
> for which the cert may be self-signed, or for which the CA cert is not<br>
> immediately available.<br>
><br>
> My current working strategy is to extract the cert from the XML document<br>
> in question and load it into the keys manager that will be used for the<br>
> verification.<br>
><br>
> Here's the code that successfully passes tests against a self-signed<br>
> cert I generated:<br>
><br>
> <a href="https://github.com/instructure/xml_security/blob/0e3cbc30da1558ad2ffa541482014727d088a153/lib/xml_security/signature_verifier.rb" target="_blank">https://github.com/instructure/xml_security/blob/0e3cbc30da1558ad2ffa541482014727d088a153/lib/xml_security/signature_verifier.rb</a><br>

><br>
> Here is the test cert for which this code works:<br>
><br>
> <a href="https://gist.github.com/phinze/745c4b224dde8e0053fb" target="_blank">https://gist.github.com/phinze/745c4b224dde8e0053fb</a><br>
><br>
> Now as I attempted to integrate with ruby-saml, I ran into a set of<br>
> requests in the ruby-saml tests signed with the following key:<br>
><br>
> <a href="https://gist.github.com/phinze/fdce716947bc6128d6e6" target="_blank">https://gist.github.com/phinze/fdce716947bc6128d6e6</a><br>
><br>
> Verifying those signatures with the same code yields an error here:<br>
><br>
> x509vfy.c:360 (xmlSecOpenSSLX509StoreVerify) - x509-store<br>
> X509_verify_cert 4 subj={{redacted}};err=20;msg=unable to get local<br>
> issuer certificate<br>
><br>
> My understanding is that the x509v3 extensions on the latter cert<br>
> prevent it from acting as a CA for itself.<br>
><br>
> I've tried sticking XMLSEC_KEYINFO_FLAGS_X509DATA_DONT_VERIFY_CERTS on<br>
> the keyInfoReadCtx flags of the digital signature context, but that only<br>
> yields a different error:<br>
><br>
> keys.c:1370 (xmlSecKeysMngrGetKey) -  xmlSecKeysMngrFindKey 1<br>
><br>
> From reading archives it seems like this flag disables the extraction of<br>
> the certificate from the XML, which I'm guessing is what's happening in<br>
> this case.<br>
><br>
> I'm also running into trouble with certs issued by a valid CA for which<br>
> I do not have the CA cert in the context where my code is running, since<br>
> the prior versions of the application relied only on a pre-shared<br>
> fingerprint.<br>
><br>
> So, is there a way for me to pull this off? Or do I need to look<br>
> elsewhere for code that can achieve the behavior I'm looking to model?<br>
><br>
> Thanks so much for your time,<br>
><br>
> Paul<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> xmlsec mailing list<br>
> <a href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</a><br>
> <a href="http://www.aleksey.com/mailman/listinfo/xmlsec" target="_blank">http://www.aleksey.com/mailman/listinfo/xmlsec</a><br>
><br>
</blockquote></div><br></div>