Re: Unusual certificates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux