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@xxxxxxxxxx> 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
