<div dir="ltr"><div dir="ltr">That's plausible - although it would be odd that the other similar device hasn't done the same (i.e. BER vs DER).<div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 25 Feb 2021 at 17:29, Benjamin Kaduk <<a href="mailto:bkaduk@akamai.com">bkaduk@akamai.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">That sounds like the certificate is encoded using ASN.1 BER rules, that openssl<br>
accepts, but the python library is insisting on DER encoding (per the spec).<br>
<br>
-Ben<br>
<br>
On Thu, Feb 25, 2021 at 05:19:32PM +0000, John Robson via openssl-users wrote:<br>
> Hi all,<br>
> <br>
> I'm encountering an error connecting to a device which as far as I can see<br>
> has a reasonable certificate...<br>
> <br>
> The error coming back (through twisted and python) is:<br>
> <br>
> > twisted.python.failure.Failure OpenSSL.SSL.Error: [('asn1 encoding<br>
> > routines', 'c2i_ibuf', 'illegal padding'), ('asn1 encoding routines',<br>
> > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('asn1 encoding routines',<br>
> > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('SSL routines',<br>
> > 'tls_process_server_certificate', 'ASN1 lib')]<br>
> <br>
> <br>
> However if I run the following:<br>
> # openssl s_client -connect <host>:<port> </dev/null 2>/dev/null | openssl<br>
> x509 | openssl asn1parse<br>
>     0:d=0  hl=4 l= 733 cons: SEQUENCE<br>
>     4:d=1  hl=4 l= 453 cons: SEQUENCE<br>
>     8:d=2  hl=2 l=   3 cons: cont [ 0 ]<br>
>    10:d=3  hl=2 l=   1 prim: INTEGER           :02<br>
>    13:d=2  hl=2 l=   4 prim: INTEGER           :000000<br>
>    19:d=2  hl=2 l=  13 cons: SEQUENCE<br>
>    21:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption<br>
>    ... (continues)<br>
> <br>
> ...then OpenSSL seems to handle the whole certificate without problem, the<br>
> thing that looks "off" to me is the serial number being defined as<br>
> "000000", rather than "00" (which I see on the self signed certificates<br>
> from other devices of this type).<br>
> <br>
> Is that likely to be causing the issue?  It's ~20 years since I last had to<br>
> deal with ASN.1 properly, so I can't remember if using unnecessarily long<br>
> representations of integers is actually valid.<br>
> <br>
> The raw ASN.1 looks ok I *think* (although I note that it has four bytes<br>
> specified) "02 04 00 00 00 00"<br>
> <br>
> <br>
> I'm at the point where I might just try to get it to generate a new<br>
> certificate and see if it does that with a single byte zero (as per the<br>
> other similar device I've been looking at)<br>
> <br>
> Am I completely barking up the wrong tree, is there something else that I<br>
> can use other than the asn1parse option to figure out where the error might<br>
> be coming from?<br>
> <br>
> Cheers,<br>
> <br>
> John<br>
> <br>
> -- <br>
> <br>
> *John Robson*<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><span style="font-size:12px"><strong>John Robson<br></strong></span><span style="font-size:12px"><br>
</span></div></div>