Re: PEM file line size

[Benjamin Kaduk via openssl-users]

On Thu, Feb 25, 2021 at 03:30:43PM -0800, Frank Liu wrote:
> Looking at test cases
> https://urldefense.com/v3/__https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/test/recipes/04-test_pem.t__;!!GjvTz_vk!A42D2c2brOwptas6T1iBt9i7pMWhwehkKAmeCuILgR-6iv5n0TQPQ6tkkVgG9A$
>  
> , openssl indeed is a parser that can handle other line sizes than 64
> chars. If we were to strictly follow RFC, shouldn't we error out none 64
> line size (except last line which could be equal or less than 64)? Leaving
> it "undefined behavior" would invite issues.

If you read RFC 1421 carefully (the ABNF, and the first line of Section
4.3.2.4), the 64 characters per line limitation only applies for encrypted (or
MIC-ONLY) messages.  Other messages can use arbitrary length lines for base64
content.

-Ben

Re: PEM file line size

[Frank Liu]

Looking at test cases
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/test/recipes/04-test_pem.t
, openssl indeed is a parser that can handle other line sizes than 64
chars. If we were to strictly follow RFC, shouldn't we error out none 64
line size (except last line which could be equal or less than 64)? Leaving
it "undefined behavior" would invite issues.

On Thu, Feb 25, 2021 at 2:57 AM Matthias Buehlmann <
matthias.buehlm...@mabulous.com> wrote:

> „Parsers MAYhandle other line sizes.These requirements are consistent with 
> PEM [RFC1421 ].“
>
>
> It‘s not a bug, it‘s undefined behaviour.
>
> On Wed, 24 Feb 2021 at 20:20 Frank Liu  wrote:
>
>> Hi,
>>
>> I noticed openssl 1.0.1 and 1.0.2 can't read a certificate PEM file with
>> base64 line size of multiples of 1265. Any other line size seems to be
>> fine, even though rfc7468 says "exactly 64 characters except for the final
>> line".
>>
>> The same pem file can be read fine with latest openssl 1.1.1j. Does
>> anybody know the bug or PR when that was fixed?
>>
>> Thanks!
>> Frank
>>
>

Re: ASN.1 encoding error

[Peter Sylvester]

Even with sound this would not be BER. i:-) Integers can have 9 or more leading 
zero bits in BERnot

ISO/IEC 8825-1:2008 (E) ITU-T Rec. X.690 (11/2008)

7 8.3 Encoding of an integer value

8.3.1The encoding of an integer value shall be primitive. The contents octets shall consist of one 
or more octets.


8.3.2If  the  contents  octets  of  an  integer  value  encoding consist  of  more  than  one  
octet,  then  the  bits  of  the first  octet and bit 8 of the second octet: a) shall not all be 
ones; and


b) shall not all be zero.

NOTE – These rules ensure that an integer value is always encoded in the smallest possible number of 
octets.


8.3.3The contents octets shall be a two's complement binary number equal to the integer value, and 
consisting of bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second octet, followed 
by bits 8 to 1 of each octet in turn up to and including the last octet of the contents octets.


NOTE – The value of a two's complement binary number is derived by numbering the bits in the 
contents octets, starting with bit1 of the last octet as bit zero and ending the numbering with bit 
8 of the first octet. Each bit is assigned a numerical value of 2N, where  N  is  its  position  in  
the  above  numbering  sequence. The  value  of  the  two's  complement  binary  number  is 
obtained  by  summing the numerical values assigned to each bit for those bits which are set to one, 
excluding bit 8 of the first octet, and then reducing this value by the numerical value assigned to 
bit 8 of the first octet if that bit is set to one.








On 25/02/2021 18:28, Benjamin Kaduk via openssl-users 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 +, 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 : /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   :00
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
"00", 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*

Re: ASN.1 encoding error

[John Robson via openssl-users]

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  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 +, 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 : /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   :00
> >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
> > "00", 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*

Re: ASN.1 encoding error

[Benjamin Kaduk via openssl-users]

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 +, 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 : /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   :00
>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
> "00", 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*

ASN.1 encoding error

[John Robson via openssl-users]

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 : /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   :00
   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
"00", 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*

Re: PEM file line size

[Frank Liu]

Hi,

Since this is undefined behavior, I guess it was accidentally fixed without
a bug or being noticed.

BTW, I found this openssl bug
 and pull request fix
, but that only fixed PEM
line length of 254 (or a multiple), not 1265.



On Thu, Feb 25, 2021 at 2:57 AM Matthias Buehlmann <
matthias.buehlm...@mabulous.com> wrote:

> „Parsers MAYhandle other line sizes.These requirements are consistent with 
> PEM [RFC1421 ].“
>
>
> It‘s not a bug, it‘s undefined behaviour.
>
> On Wed, 24 Feb 2021 at 20:20 Frank Liu  wrote:
>
>> Hi,
>>
>> I noticed openssl 1.0.1 and 1.0.2 can't read a certificate PEM file with
>> base64 line size of multiples of 1265. Any other line size seems to be
>> fine, even though rfc7468 says "exactly 64 characters except for the final
>> line".
>>
>> The same pem file can be read fine with latest openssl 1.1.1j. Does
>> anybody know the bug or PR when that was fixed?
>>
>> Thanks!
>> Frank
>>
>

Re: PEM file line size

[Matthias Buehlmann]

„Parsers MAYhandle other line sizes.These requirements are consistent
with PEM [RFC1421 ].“


It‘s not a bug, it‘s undefined behaviour.

On Wed, 24 Feb 2021 at 20:20 Frank Liu  wrote:

> Hi,
>
> I noticed openssl 1.0.1 and 1.0.2 can't read a certificate PEM file with
> base64 line size of multiples of 1265. Any other line size seems to be
> fine, even though rfc7468 says "exactly 64 characters except for the final
> line".
>
> The same pem file can be read fine with latest openssl 1.1.1j. Does
> anybody know the bug or PR when that was fixed?
>
> Thanks!
> Frank
>

Support of Indirect CRL and How to?

[Romain Viau]

Hi everybody,

I am trying to implement a complex PKI and some parts are based on a Indirect 
CRL issued by a specific certificate.

I found that the "openssl verify" command works fine if I had the CRL issuer as 
"-untrusted" argument. 
But this check doesn't work if I only add the CRLIssuer cert in the CApath 
(with `openssl rehash` operation).

The CA issuing the User certificate is offline, so I coudn't manage its CRL and 
my final use case is to implement the CRL verification by a server like Nginx 
or Apache. So, can I make it work with SSL_CONF_cmd and with which parameters?

Regards,

Romain