ASN.1 encoding error

[John Robson]

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 <bkaduk at 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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210225/076d53c8/attachment-0001.html>