The appears to be a specification violation.

The issue occurs when trying to parse this section:

A3 81 24

81 indicates it's long form (multi-byte) and a single byte.  Then 24 is the length.

The check that leads to "DerInputStream.getLength(): Should use short form for length" checks for long form length octet that has a value less than 127 and rejects it because it should have used short form (single-byte).

However, according to spec whether to use long form or short for is at sender's option:

~~~
8.1.3.3
For the definite form, the length octets shall consist of one or more octets, and shall represent the number of octets in the contents octets using either the short form (see 8.1.3.4) or the long form (see 8.1.3.5) as a sender's
option.
NOTE – The short form can only be used if the number of octets in the contents octets is less than or equal to 127.
~~~

The disclaimer at the end doesn't mean that short form must be used if the length is less than 127, but that the short form only is possible with values less than 127.  

[1] https://www.itu.int/rec/T-REC-X.690-201508-I/en

And I'm wrong.  DER rules specify smallest number of octets should be used:

10
Distinguished encoding rules The encoding of a data values employed by the distinguished encoding rules is the basic encoding described in clause 8,
together with the following restrictions and those also listed in clause 11.

10.1
Length forms
The definite form of length encoding shall be used, encoded in the minimum number of octets. [Contrast with 8.1.3.2 b).]

I'll look into this after the imminent security update.

Yes, I moved this to RHEL7

seems easy to test