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 <bka...@akamai.com> 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 +0000, 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 <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?
> >
> > Cheers,
> >
> > John
> >
> > --
> >
> > *John Robson*
>
--
*John Robson*
