Hi Peter, Although the certificate's encoding of the serial number field breaks the BER specification about the minimal bytes representation, it is known that many CA's and libraries treat this field as a blob and usually encode it on a fixed length basis without caring about leading zeros. Specifically, Peter Gutmann in his X.509 Style Guide says this about this field : "If you're writing certificate-handling code, just treat the serial number as a blob which happens to be an encoded integer".
Moreover, major PKI libraries are tolerant vis-a-vis the encoding of the serial number field of a certificate and they verify successfully the certificate chain given by the original poster. For example, NSS, GnuTLS and CryptoAPI accept the given certificates and verify successfully their trust. Supporting or not specific broken implementations have always been the subject of heated debates. Concerning the specific issue here, it's clear that OpenSSL is too restrictive compared to other major libraries since this is a minor deviation from the BER specs (i.e. minimal bytes representation) and thus hurts deployments of real-world certificates. -- Mounir IDRASSI IDRIX http://www.idrix.fr > The encoding is invalid BER. > The openssl is tolerant but also destructive in copy. > > whenever you use openssl x509 -in -out ... you remove one leading 0 > octet. > > IMHO openssl should reject the cert because of invalid encoding. > > > On 08/29/2010 04:17 AM, Mounir IDRASSI wrote: >> 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 List openssl-users@openssl.org >>> Automated List Manager majord...@openssl.org >> >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> Development Mailing List openssl-...@openssl.org >> Automated List Manager majord...@openssl.org > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
