Ok, understood. What you are saying is also consistent with my observation that adding the certificates to the untrusted store silences the errors. I'll look into attaching my own error handler when I call the C API (I assume there's an example somewhere - I've not looked yet).<br>
<br>However, I'm still intrigued as to why the xmlsec certificate chain tests in tests/aleksey-xmldsig-01 don't show similar behaviour. Roumen, I suspect you understand more than I do about this based on what you said in your previous message regarding tests/aleksey-xmldsig-01/enveloping-rsa-x509chain. I'm guessing that it's the pathlen constraint that is significant here, but I need to learn more about that in order to comment further. I tried the obvious and changed the order of the certificates in enveloping-rsa-x509chain in the hope that the signer certificate would be found first and so cause the error to be reported, but that didn't happen. As I understand it, the standards allow any certificate ordering so I guess that's a good thing. But it does mean that there's still something else going on that is currently beyond me! Any further thoughts?<br>
<div id="1ew0" class="udg9X"></div><br>Thanks again to you both for your efforts.<br><br><div class="gmail_quote">On Sat, Feb 23, 2008 at 9:16 PM, Aleksey Sanin <<a href="mailto:aleksey@aleksey.com">aleksey@aleksey.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I got to the bottom of it. Here is what is happening:<br>
- xmlsec reads the first x509data node and immediately tries to<br>
verify and extract the key, there is no full chain yet so<br>
we fail with the error;<br>
- xmlsec goes to the next node, immediately tries to<br>
verify and extract the key, there is no full chain yet so<br>
we fail with the error;<br>
- repeat the previous step several times;<br>
- finally we got to the 4th certificate that can be verified<br>
<br>
The bottom line is that the error is harmless. If you are using<br>
the xmlsec via C API, then you can install your own error handler<br>
callbacks, accumulate all the errors/warnings and then print<br>
them at the very end *if and only if* signature verification fails.<br>
Otherwise, just ignore all the errors.<br>
<br>
If you use command line tool, then you can do a similar trick<br>
with redirecting stderr to a temp file and checking the xmlsec<br>
command line tool return code.<br>
<br>
Best,<br>
<font color="#888888">Aleksey<br>
</font><div><div></div><div class="Wj3C7c"><br>
Aleksey Sanin wrote:<br>
> Mostly likely you need to debug openssl :) I'll try to take a look at<br>
> it over weekend but no promises....<br>
><br>
> Aleksey<br>
><br>
<br>
</div></div></blockquote></div><br>