У нед, 29. 08 2010. у 04:17 +0200, Mounir IDRASSI пише: > > After some digging, I found that part of the problem is caused by the > functions c2i_ASN1_INTEGER and d2i_ASN1_UINTEGER in file > crypto\asn1\a_int.c. At lines 244 and 314, there is an if block that > removes any leading zeros. Commenting out these blocks solves the DER > encoding mismatch but the verification still fails because the computed > digest is different from the recovered one.
Thank you, I can confirm that your suggestion is working. Applying a patch that you described does solve a problem for me. The MUPCAGradjani certificate can be verified against the MUPCARoot, as well as certificates issued by the MUPCAGradjani, like the two personal certificates I have on my eID card. I had to reconvert DER to PEM with patched openssl to get PEM certificates with "correct" serial number encoding. I read the other messages in this thread, but I am not an expert in the field so I do not know if openssl should add a support for "incorrect" serial numbers. In RFC 3280 there is a note about "Non-conforming CAs" where section "4.1.2.2 Serial number" is saying that "certificate users SHOULD be prepared to gracefully handle such certificates". Maybe the note can apply in this case? What I do know is that without a patch openssl can not be used with certificates issued on a Serbian national eID card. At least one other Serbian CA is hit by the same problem (http://ca.pks.rs/certs/) where PKI solution was provided by a same company. I have published patched openssl package for Ubuntu GNU/Linux distribution in my Ubuntu PPA at: https://launchpad.net/~grakic/+archive/serbian-eid Kind regards, Goran Rakic ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
