У нед, 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

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 " 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:

Kind regards,
Goran Rakic

OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to