Many thanks for clearifying that issue for me!
I was short before to go stupid on that ... ;-))
Ingo Fischer
Aleksey Sanin wrote:
Yes, you are right about -CAfile, I forget it, sorry. Actually,
everything works just
fine for me now (and all the openssl stuff was not needed :) ):
[EMAIL PROT
Hello !
Ops.. The line was too long and I missed the last two certs. However, this
changes nothing for me:
[EMAIL PROTECTED] openssl verify -CAfile c.pem b.pem
b.pem: OK
[EMAIL PROTECTED] openssl verify -CAfile b.pem a.pem
a.pem: /C=US/O=MasterCard International Incorpor
Yes, you are right about -CAfile, I forget it, sorry. Actually,
everything works just
fine for me now (and all the openssl stuff was not needed :) ):
[EMAIL PROTECTED] xmlsec verify --trusted c.pem
3dsec_xmldsig_verify_3006.xml
= Status:
== Signatures ok: 1
== Signatures fail: 0
=
In the XML-File there were 3 certificates at all included. The first
certificate you extracted as "a.pem".
I saved these certificates as b.pem and c.pem too.
Ops.. The line was too long and I missed the last two certs. However, this
changes nothing for me:
[EMAIL PROTECTED] openssl verify
Hello Aleskey,
In the XML-File there were 3 certificates at all included. The first certificate
you extracted as "a.pem".
I saved these certificates as b.pem and c.pem too.
when I run verify that with openssl I get an success for a.pem.
So you need all certificates which are presented in the XML
When I run the following on the attached files, I get the error below:
xmlsec sign --privkey DumpedKey.pem,DumpedCert.pem --output x1-sig.xml
x1-sig-template.xml
You have a minor problem in your templpate: you've had
empty element in
element and this caused Base64 error you've seen :)
Remov
Actually, it is already done :) But in the developer series
on the trunk. Unfortunatelly, backporting it to 0.0.X branch
would mean binary incompatibility and I would prefer to
do not do this.
And of course there is a quick and durty solution to just have
a separate table (transformId <-> readable
I'd like to report as much useful information as possible in the event
signature generation or validation fails. Ideally, this would include the
name of any failed transform(s). I could use xmlSecTransformId's href
member, but it seems like a really bad idea to rely on an internal
structure. Would