Re: ASN.1 encoding error
Even with sound this would not be BER. i:-) Integers can have 9 or more leading zero bits in BERnot ISO/IEC 8825-1:2008 (E) ITU-T Rec. X.690 (11/2008) 7 8.3 Encoding of an integer value 8.3.1The encoding of an integer value shall be primitive. The contents octets shall consist of one or more octets. 8.3.2If 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. 8.3.3The contents octets shall be a two's complement binary number equal to the integer value, and consisting of bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second octet, followed by bits 8 to 1 of each octet in turn up to and including the last octet of the contents octets. NOTE – The value of a two's complement binary number is derived by numbering the bits in the contents octets, starting with bit1 of the last octet as bit zero and ending the numbering with bit 8 of the first octet. Each bit is assigned a numerical value of 2N, where N is its position in the above numbering sequence. The value of the two's complement binary number is obtained by summing the numerical values assigned to each bit for those bits which are set to one, excluding bit 8 of the first octet, and then reducing this value by the numerical value assigned to bit 8 of the first octet if that bit is set to one. On 25/02/2021 18:28, Benjamin Kaduk via openssl-users wrote: That sounds like the certificate is encoded using ASN.1 BER rules, that openssl accepts, but the python library is insisting on DER encoding (per the spec). -Ben On Thu, Feb 25, 2021 at 05:19:32PM +, John Robson via openssl-users wrote: Hi all, I'm encountering an error connecting to a device which as far as I can see has a reasonable certificate... The error coming back (through twisted and python) is: twisted.python.failure.Failure OpenSSL.SSL.Error: [('asn1 encoding routines', 'c2i_ibuf', 'illegal padding'), ('asn1 encoding routines', 'asn1_template_noexp_d2i', 'nested asn1 error'), ('asn1 encoding routines', 'asn1_template_noexp_d2i', 'nested asn1 error'), ('SSL routines', 'tls_process_server_certificate', 'ASN1 lib')] However if I run the following: # openssl s_client -connect : /dev/null | openssl x509 | openssl asn1parse 0:d=0 hl=4 l= 733 cons: SEQUENCE 4:d=1 hl=4 l= 453 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 13:d=2 hl=2 l= 4 prim: INTEGER :00 19:d=2 hl=2 l= 13 cons: SEQUENCE 21:d=3 hl=2 l= 9 prim: OBJECT:sha256WithRSAEncryption ... (continues) ...then OpenSSL seems to handle the whole certificate without problem, the thing that looks "off" to me is the serial number being defined as "00", rather than "00" (which I see on the self signed certificates from other devices of this type). Is that likely to be causing the issue? It's ~20 years since I last had to deal with ASN.1 properly, so I can't remember if using unnecessarily long representations of integers is actually valid. The raw ASN.1 looks ok I *think* (although I note that it has four bytes specified) "02 04 00 00 00 00" I'm at the point where I might just try to get it to generate a new certificate and see if it does that with a single byte zero (as per the other similar device I've been looking at) Am I completely barking up the wrong tree, is there something else that I can use other than the asn1parse option to figure out where the error might be coming from? Cheers, John -- *John Robson*
Re: ASN.1 encoding error
That's plausible - although it would be odd that the other similar device hasn't done the same (i.e. BER vs DER). I think I'm going to get some new certs generated, preferably not on the device itself. At least there is a possible explanation of the difference in behaviour that I am seeing. Thanks, John On Thu, 25 Feb 2021 at 17:29, Benjamin Kaduk wrote: > That sounds like the certificate is encoded using ASN.1 BER rules, that > openssl > accepts, but the python library is insisting on DER encoding (per the > spec). > > -Ben > > On Thu, Feb 25, 2021 at 05:19:32PM +, John Robson via openssl-users > wrote: > > Hi all, > > > > I'm encountering an error connecting to a device which as far as I can > see > > has a reasonable certificate... > > > > The error coming back (through twisted and python) is: > > > > > twisted.python.failure.Failure OpenSSL.SSL.Error: [('asn1 encoding > > > routines', 'c2i_ibuf', 'illegal padding'), ('asn1 encoding routines', > > > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('asn1 encoding > routines', > > > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('SSL routines', > > > 'tls_process_server_certificate', 'ASN1 lib')] > > > > > > However if I run the following: > > # openssl s_client -connect : /dev/null | > openssl > > x509 | openssl asn1parse > > 0:d=0 hl=4 l= 733 cons: SEQUENCE > > 4:d=1 hl=4 l= 453 cons: SEQUENCE > > 8:d=2 hl=2 l= 3 cons: cont [ 0 ] > >10:d=3 hl=2 l= 1 prim: INTEGER :02 > >13:d=2 hl=2 l= 4 prim: INTEGER :00 > >19:d=2 hl=2 l= 13 cons: SEQUENCE > >21:d=3 hl=2 l= 9 prim: OBJECT:sha256WithRSAEncryption > >... (continues) > > > > ...then OpenSSL seems to handle the whole certificate without problem, > the > > thing that looks "off" to me is the serial number being defined as > > "00", rather than "00" (which I see on the self signed certificates > > from other devices of this type). > > > > Is that likely to be causing the issue? It's ~20 years since I last had > to > > deal with ASN.1 properly, so I can't remember if using unnecessarily long > > representations of integers is actually valid. > > > > The raw ASN.1 looks ok I *think* (although I note that it has four bytes > > specified) "02 04 00 00 00 00" > > > > > > I'm at the point where I might just try to get it to generate a new > > certificate and see if it does that with a single byte zero (as per the > > other similar device I've been looking at) > > > > Am I completely barking up the wrong tree, is there something else that I > > can use other than the asn1parse option to figure out where the error > might > > be coming from? > > > > Cheers, > > > > John > > > > -- > > > > *John Robson* > -- *John Robson*
Re: ASN.1 encoding error
That sounds like the certificate is encoded using ASN.1 BER rules, that openssl accepts, but the python library is insisting on DER encoding (per the spec). -Ben On Thu, Feb 25, 2021 at 05:19:32PM +, John Robson via openssl-users wrote: > Hi all, > > I'm encountering an error connecting to a device which as far as I can see > has a reasonable certificate... > > The error coming back (through twisted and python) is: > > > twisted.python.failure.Failure OpenSSL.SSL.Error: [('asn1 encoding > > routines', 'c2i_ibuf', 'illegal padding'), ('asn1 encoding routines', > > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('asn1 encoding routines', > > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('SSL routines', > > 'tls_process_server_certificate', 'ASN1 lib')] > > > However if I run the following: > # openssl s_client -connect : /dev/null | openssl > x509 | openssl asn1parse > 0:d=0 hl=4 l= 733 cons: SEQUENCE > 4:d=1 hl=4 l= 453 cons: SEQUENCE > 8:d=2 hl=2 l= 3 cons: cont [ 0 ] >10:d=3 hl=2 l= 1 prim: INTEGER :02 >13:d=2 hl=2 l= 4 prim: INTEGER :00 >19:d=2 hl=2 l= 13 cons: SEQUENCE >21:d=3 hl=2 l= 9 prim: OBJECT:sha256WithRSAEncryption >... (continues) > > ...then OpenSSL seems to handle the whole certificate without problem, the > thing that looks "off" to me is the serial number being defined as > "00", rather than "00" (which I see on the self signed certificates > from other devices of this type). > > Is that likely to be causing the issue? It's ~20 years since I last had to > deal with ASN.1 properly, so I can't remember if using unnecessarily long > representations of integers is actually valid. > > The raw ASN.1 looks ok I *think* (although I note that it has four bytes > specified) "02 04 00 00 00 00" > > > I'm at the point where I might just try to get it to generate a new > certificate and see if it does that with a single byte zero (as per the > other similar device I've been looking at) > > Am I completely barking up the wrong tree, is there something else that I > can use other than the asn1parse option to figure out where the error might > be coming from? > > Cheers, > > John > > -- > > *John Robson*
ASN.1 encoding error
Hi all, I'm encountering an error connecting to a device which as far as I can see has a reasonable certificate... The error coming back (through twisted and python) is: > twisted.python.failure.Failure OpenSSL.SSL.Error: [('asn1 encoding > routines', 'c2i_ibuf', 'illegal padding'), ('asn1 encoding routines', > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('asn1 encoding routines', > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('SSL routines', > 'tls_process_server_certificate', 'ASN1 lib')] However if I run the following: # openssl s_client -connect : /dev/null | openssl x509 | openssl asn1parse 0:d=0 hl=4 l= 733 cons: SEQUENCE 4:d=1 hl=4 l= 453 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 13:d=2 hl=2 l= 4 prim: INTEGER :00 19:d=2 hl=2 l= 13 cons: SEQUENCE 21:d=3 hl=2 l= 9 prim: OBJECT:sha256WithRSAEncryption ... (continues) ...then OpenSSL seems to handle the whole certificate without problem, the thing that looks "off" to me is the serial number being defined as "00", rather than "00" (which I see on the self signed certificates from other devices of this type). Is that likely to be causing the issue? It's ~20 years since I last had to deal with ASN.1 properly, so I can't remember if using unnecessarily long representations of integers is actually valid. The raw ASN.1 looks ok I *think* (although I note that it has four bytes specified) "02 04 00 00 00 00" I'm at the point where I might just try to get it to generate a new certificate and see if it does that with a single byte zero (as per the other similar device I've been looking at) Am I completely barking up the wrong tree, is there something else that I can use other than the asn1parse option to figure out where the error might be coming from? Cheers, John -- *John Robson*