Thanks dalini,
>
> if the order is equivalent then it may be
> either an encoding or an cr/lf problem
> it must binary equivalent
>
> otherwise the signature can't be verified
> since it won't match, different representations
>
> could be a problem there?
Yes, I suppose that must be the proble
Johnny Gonzalez wrote:
Hello Michael,
That's correct. The data must have the exact same
order.
How does OpenCA loads data from the DB to check the
signature with openca-sv?
When I read the data to be signed from the DB, it
appears in this order:
-BEGIN HEADER-
TYPE = PKCS#10
SERIAL = 4896
Hello Michael,
>
> That's correct. The data must have the exact same
> order.
How does OpenCA loads data from the DB to check the
signature with openca-sv?
When I read the data to be signed from the DB, it
appears in this order:
-BEGIN HEADER-
TYPE = PKCS#10
SERIAL = 4896
NOTBEFORE =
Johnny Gonzalez wrote:
OpenCA::PKCS7 returns errorcode 7911031
(OpenCA::PKCS7->new: Cannot initialize signature
(7912021). OpenCA::PKCS7->initSignature: Cannot parse
signature (7921021). OpenCA::PKCS7->getParsed: The
crypto-backend cannot verify the signature (7742075).
OpenCA::OpenSSL->verify:
Johnny Gonzalez wrote:
- When I use the interface the Method signText shows a
window with the data it is going to sign, that data
looks in a different order from the data I'm obtaining
in Java from the DB. So I guess that's the problem why
the signature is invalid.
That's correct. The data must hav
Hi,
quick update: I have a local version of scepPKIOperation that
implements a lot of the stuff I mentioned in the post and works
fine for me. It also includes some debugging code and I cleaned
it up a bit.
I won't commit it to CVS yet, because I am not yet done with it.
I attach the current vers
