Hi,
The problem you are encountering is partly caused by the way OpenSSL
handles integers whose DER encoded value starts with one or more zeros :
in this case, OpenSSL removes the leading zero when creating the
corresponding ASN1_INTEGER structure thus leading to the fact that
computed DER of this structure and the original one will be different!!
In your case, the certificate you are trying to verify has a DER encoded
serial number 00 00 65. So, OpenSSL will create an ASN1_INTEGER with a
value of 00 65. And in the course of the certificate signature
verification, this structure will be encoded to DER which will lead to a
encoded value of 00 65. Thus, the generated DER of the CertInfo will
be different from the original one, which explains why the signature
verification fails.
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.
I will continue my investigation to find all the culprits.
Meanwhile, the question remains why in the first place the removal of
the leading zero from the parsed DER encoding was added since this
clearly have the side effect of making the computed DER different from
the original one.
Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr
On 8/28/2010 10:43 PM, Goran Rakic wrote:
Hi all,
I have two X.509 certificates MUPCAGradjani.crt and MUPCARoot.crt
downloaded from http://ca.mup.gov.rs/sertifikati-lat.html
Certificate path is MUPCARoot MUPCAGradjani and I would like to
validate MUPCAGradjani against the other. What I did is to convert both
to PEM format and rename them by hash as efd6650d.0 (Gradjani) and
fc5fe32d.0 (Root) using this script:
#!/bin/bash
hash=`openssl x509 -in $1 -inform DER -noout -hash`
echo Saving $1 as $hash.0
openssl x509 -in $1 -inform DER -out $hash.0 -outform PEM
Now I run:
$ openssl verify -CApath . efd6650d.0
error 7 at 0 depth lookup:certificate signature failure
16206:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:255:
16206:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP
lib:a_verify.c:173:/pre
Hm, that is not working. What am I doing wrong here?
I am running OpenSSL 0.9.8k 25 Mar 2009 on Ubuntu 10.04 GNU/Linux. I
also have my personal certificate issued by MUPCAGradjani that I would
like to verify but it is failing with the same error (just one level
down):
$ openssl verify -CApath . qualified.pem
qualified.pem: /CN=MUPCA Gradjani/O=MUP Republike
Srbije/L=Beograd/C=Republika Srbija (RS)
error 7 at 1 depth lookup:certificate signature failure
16258:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:255:
16258:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP
lib:a_verify.c:173:/pre
When I install downloaded certificates in Windows using Internet
Explorer and doubleclick on my personal certificate (qualified.cer) it
looks valid. I am not sure, but I believe it is doing certificate chain
validation so the certificates and paths should be valid. After all they
are issued by a trustful CA.
Output of openssl x509 -nameopt multiline,utf8,-esc_msb -noout -text
-in $1 looks reasonable for both downloaded certificates and is the
same before and after conversion to PEM (using -inform DER in the first
case). My take on this is that I am not doing conversion properly or
maybe the original certificates are in some other format requiring extra
argument, but I can not find answer in the docs.
How can I properly validate X.509 certificate from
http://ca.mup.gov.rs/sertifikati-lat.html by certificate chain?
Kind regards,
Goran
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
