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 <host>:<port> </dev/null 2>/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           :000000
   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
"000000", 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?




*John Robson*

Reply via email to