Unusual certificates

[Jakob Bohm]

On 2020-06-25 13:25, Hubert Kario wrote:
> On Thursday, 25 June 2020 12:15:00 CEST, Angus Robertson - Magenta 
> Systems Ltd wrote:
>> A client is having problems reading Polish Centum issued personal
>> certificates with OpenSSL 1.1.1, which read OK with 1.1.0 and earlier,
>> mostly.
>> Using PEM_read_bio_X509 with some of these certificates says
>> error:00000000:lib(0):func(0):reason(0), while the X509 command line
>> tool says 'unable to load certificate'.  Some certificates work with
>> both methods.
>>
>> Using the asn1parse command from any version of OpenSSL says 'Error:
>> offset out of range', while a Javascript based web tool is able to
>> decode the ASN1, but is perhaps more tolerant of errors.
>> So it seems there is something in the creation of these certificates
>> that OpenSSL has never liked, but until 1.1.1 was tolerated
>> sufficiently to allow them to be read.
>> This certificate reads OK in 1.1.1 but fails asn1parse:
>
> works just fine for me with 1.1.1g
>
>> This certificate can not be read in 1.1.1 but is OK in 1.1.0.
>
> but this one fails parsing
>
>>
>> Is there a more tolerant way to read ASN1 than the asn1parse command? 
>
> asn1parse expects BER encoding, that already is the most lenient, while
> still standards-compliant, encoding that is supported.
>
> Given that it errors out with
> 139628293990208:error:0D07209B:asn1 encoding 
> routines:ASN1_get_object:too long:crypto/asn1/asn1_lib.c:91:
> I'm guessing a mismatch between utf-8 and string encoding that makes
> the lengths inconsistent. Some tools may just ignore them, but that 
> doesn't
> make the certificate well-formed.
I have tried examining these two certificates with Peter Gutmann's 
dumpasn1.c
and a generic hex dumper.

For the second certificate, dumpasn1.c complains about a badly encoded 
SET at
file offset 0x8E (after Base64 decoding):

0008E                                           31 19
00090 05 c1 80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c
000A0 8d 4c 0c 0c 0c 4c 0e 4c 0c
000A9                            07 85 c3 4c 4e 4c 0c

My manual attempt to recover from this results in the following
further failures:

Attempt1: Straight BER/DER:
SET {
   NULL-object of a very huge length: The number of bytes is
     0x80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c 8d 4c
       0c 0c 0c 4c 0e 4c 0c 07 85 c3 4c 4e 4c 0c 8c 8d
       0c 8c cc 0c 0c 0c 16 85 c3 4c 8c 4c 0c 8c 8c cc
       8c cc 0c 0c 0c 16 8c 1d 4c 42 cc 02 41 80 d5 41
       01
     -- ERROR: This runs beyond end-of-file
     -- ERROR: This runs beyond end-of-SET (0x19 bytes)
}

Attempt2: Assume length byte for zero length NULL object omitted:
SET { NULL-object with missing length-encoding of its zero length
       private-tag-1 object with indefinite length
     -- ERROR: This runs beyond end-of-SET (0x19 bytes)
}

Attempt3: Treat SET as an opaque blob
SET { -- Contents ignored }
ObjectDescriptor of length 0x151CC bytes
   -- ERROR: This runs beyond end-of-file

Attempt4: Treat preceding string as encoded with length 1 too small
SET {
   SEQUENCE {
     OBJECT IDENTIFIER commonName -- 2.5.4.3
     UTF8String 'CUZ Sigillum - QCA11'
       -- WARNING: One byte beyond declared length of containing SEQUENCE
   }
     -- WARNING: One byte beyond declared length of containing SET
}
GraphicString '\c1\80\d5\41\18'
Application-tag-3 object of length 4 bytes: 0x15 90 55 14
PrintableString 4d 4c 8d 4c 0c 0c 0c 4c 0e 4c 0c
   -- WARNING: Bad characters
ObjectDescriptor of length 0x151CC bytes
   -- ERROR: This runs beyond end-of-file
   -- WARNING: This runs beyond length of containing DN (0x80 bytes)

Attempt5: Treat preceding string as encoded with length 2 too small
SET {
   SEQUENCE {
     OBJECT IDENTIFIER commonName -- 2.5.4.3
UTF8String 'CUZ Sigillum - QCA11\19'
       -- WARNING: 2 bytes beyond declared length of containing SEQUENCE
   }
     -- WARNING: 2 bytes beyond declared length of containing SET
  }
NULL-object of a very huge length: The number of bytes is
   0x80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c 8d 4c
     0c 0c 0c 4c 0e 4c 0c 07 85 c3 4c 4e 4c 0c 8c 8d
     0c 8c cc 0c 0c 0c 16 85 c3 4c 8c 4c 0c 8c 8c cc
     8c cc 0c 0c 0c 16 8c 1d 4c 42 cc 02 41 80 d5 41
     01
   -- ERROR: This runs beyond end-of-file
   -- WARNING: This runs beyond length of containing DN (0x80 bytes)

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded