Bonjour, Le 11 févr. 2016 à 20:25, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu<mailto:u...@ll.mit.edu>> a écrit :
On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT <r...@openssl.org<mailto:r...@openssl.org>> wrote: On Wed Feb 10 21:59:12 2016, bcri...@gmail.com<mailto:bcri...@gmail.com> wrote: As the error is suggesting it doesn't like the serialNumber in the certificate. If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you get: 13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB DA : Error: Integer '00 59 ...' has non-DER encoding. ^^^^^ Probably correct IN THIS ONE CASE, because Most Significant Bit is zero even without the leading zero byte. See below. The problem is that is an invalid encoding. An ASN.1 INTEGER cannot contain leading zeroes. I’m pretty sure this is not correct. It’s been a while since I touched ASN.1, but I had quite a bit of experience with it back when. SO first of all, could you please cite your (authoritative) sources stating that an ASN.1 DER_encoded INTEGER cannot have leading zero. Here’s what others <http://stackoverflow.com/questions/5974633/asn-1-der-formatted-private-key had to say about this: X.690 edition 2015/08 is freely downloadable from the ITU-T website. Section 8.3 describes how an INTEGER is to be encoded in BER. 8.3.2 says: If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet and bit 8 of the second octet: a) shall not all be ones; and b) shall not all be zero. NOTE – These rules ensure that an integer value is always encoded in the smallest possible number of octets. In this specific example (00 59 …), the bits of the first octets and bit 8 of the second octet are all zero. This is invalid. There is no additional rule for DER on INTEGERs. Cordialement, Erwann Abalea
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
