Unusual certificates

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Unusual certificates

Angus Robertson - Magenta Systems Ltd
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:

-----BEGIN CERTIFICATE-----
MIIHXjCCBUagAwIBAgIIbBjyWVjJUvcwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV
BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy
dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ
MBcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAzMTkwODUxMDBaFw0yMTAz
MTgwODUxMDBaMGcxCzAJBgNVBAYTAlBMMREwDwYDVQQEDAhEWklFRFpJQzEPMA0G
A1UEKgwGUkFGQcWBMRowGAYDVQQFExFQTk9QTC03NDExMDMwMDQ3MTEYMBYGA1UE
AwwPUkFGQcWBIERaSUVEWklDMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAm94BNi+bv2+oUKzN27GV0+95sm1AuDKdiKw7M63HcnjL+YYLoQvhleD7KlZR
7ntZfJ05vpWpQWM0Pt54M1Y8sJQObg+tUDlulVi7nADOrUNb3Tgctq1vbou3OpIp
xaQUtC9qNpQbGXkgJRr09/nh5h09n4vgsvtS6cKlFfMe/o6xtUeWPYm+oVoAq5sG
in+aBSBdnd73v053kbdZcbDPXmOYuCr6O2MHi7p+McPg2KMJy+wfFX4SGSBJIAY2
Owt6mnIOCU6Y/dAUcbUDtNUTwq+gXL+zg7TdwkDDTohpnluNGfrYV5JYocHO63zo
3W/CyF/enCmNiC9QLakA22O04QIDAQABo4IC8jCCAu4wgdsGCCsGAQUFBwEDBIHO
MIHLMAgGBgQAjkYBATALBgYEAI5GAQMCAQowCAYGBACORgEEMHwGBgQAjkYBBTBy
MDYWMGh0dHA6Ly93d3cuc2lnaWxsdW0ucGwvcmVwb3p5dG9yaXVtL1FDQTFfUERT
LnBkZhMCRU4wOBYyaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0v
UUNBMV9QRFNQTC5wZGYTAlBMMBUGCCsGAQUFBwsCMAkGBwQAi+xJAQEwEwYGBACO
RgEGMAkGBwQAjkYBBgEwcwYIKwYBBQUHAQEEZzBlMD4GCCsGAQUFBzAChjJodHRw
Oi8vcmVwby5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0vcWNhMV8yMDE3LmNlcjAj
BggrBgEFBQcwAYYXaHR0cDovL29jc3Auc2lnaWxsdW0ucGwwHQYDVR0OBBYEFDFY
5Q2FMMXaCpCyXFmUT2qgyA0JMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUQvpPhjaB
nSihni0atVC7qifynLQwgfkGA1UdIASB8TCB7jCB6wYKKoRoAYb4PQAAAzCB3DCB
2QYIKwYBBQUHAgIwgcwMgclLd2FsaWZpa293YW55IGNlcnR5ZmlrYXQgcG9kcGlz
dSBlbGVrdHJvbmljem5lZ28gcG93c3RhxYIgdyBvcGFyY2l1IG8gUG9saXR5a8SZ
IFVzxYJ1ZyBaYXVmYW5pYSBDVVogU2lnaWxsdW0uIFRyZcWbxIcgUG9saXR5a2kg
Q1VaIFNpZ2lsbHVtIHpuYWpkdWplIHNpxJkgcG9kIGFkcmVzZW0gaHR0cDovL3d3
dy5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0wQgYDVR0fBDswOTA3oDWgM4YxaHR0
cDovL2NybC5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0vcWNhMV8yMDE3LmNybDAO
BgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcNAQELBQADggIBACQ+ancYPWmfVDB/PTrV
D+nK8TX2HPcbgk/JrGJF0vaL+l9gTprg+3yMlfpcQfBXBsm7RwOEAK8LgaaFb7Ta
WPD1635RoGaIZ36k6WgENUjFjANya3RIRSzcOjgpeQWc6SeA++NJjQFNh7J73LMG
V5udFwpVug5yzP+LTlZZ/hoY2rN9xmY7QBn/cbgoNieRyUHbxq4zGifiJoVfKEiT
Fxl/CoUfnngxsVIsvgxFmGdnMT2j0oBODKoXJ1A8oJAcg8KnYTzI7Dnt3a5cGypv
n6V6tGv0IbHxdFu8nnsyNOSp1YhqTcfRzUGXf9NHyj6vyX4UR2ODJPccWC0uSufW
9KYio228yqj0IERG2mr8huJEBW/MEE3STmxT3R6a1OCAsVAPi3gL2yAXfn3Gdiam
MLhj/WO3OD9OyiHqTY6+/md4vOHkHy7GnKlYIJblddtziv8ek9uH/imbOQIKDjLN
Bvw3j9a55GHT/8+fow2vn31OmSfMWvikP4pntEvuMAwG2laTs19+gWdknt4Q3ma5
NTf9UnbQsFJAcW+gw3QWAmts5fZsQT806OyDvjt6jRlkmuIkeYRcYJ/E2Pg9oKx3
RiCIA1BQTImpYvbTJg9Q1DYQpbDGxDB9ENJDAyMNSIs85nBLvrri4rD6FC4Bz/m/
Og4GfIWH02DKEKBds/zPi+L5
-----END CERTIFICATE-----

This certificate can not be read in 1.1.1 but is OK in 1.1.0.

-----BEGIN CERTIFICATE-----
MIIHbDCCBVSgAwIBAgIIO7L2MrGOOTMwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV
BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy
dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ
BcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAyMjQyMzAwMDBaFw0yMTAyM
jMyMzAwMDBaMHUxCzAJBgNVBAYTAlBMMRAwDgYDVQQEDAdTa2ltaW5hMRcwFQYDV
QQqDA5KYWNlayBXb2pjaWVjaDEaMBgGA1UEBRMRUE5PUEwtNzQwNjAyMDgyMTQxH
zAdBgNVBAMMFkphY2VrIFdvamNpZWNoIFNraW1pbmEwggEiMA0GCSqGSIb3DQEBA
QUAA4IBDwAwggEKAoIBAQDbTjEdIL21ctkfJ88d7EQDegNo5VLyPQXNSp5emoNIU
f/y+RiL47SrWxS/hqYLGLUlItMsA+VCyP/+Oi42nRXcsJrSZdVgqhZTaWTZca8mF
OeujXy9eVvnAlnDDeofC5zAxYoW4fQI1/aPwmJ437bHWa6NR0iXT9j0caYfK8vrP
+gLlakBJA5RV42mt4CBZMSiNNhA9KMi9UNbtqSzlPEpSJn8Vo2LWUe+yIlUcbCDg
aQ5EVi8K7U0j5BLVQfVparZGi7C50V1ZPwWsYlu7v1PKHMDXPwUzOlwZ//UrxdRn
v/AFgjLjxuS+FNvCOaiyr0EmxccLKFvqycvx6qOxFulAgMBAAGjggLyMIIC7jCB2
wYIKwYBBQUHAQMEgc4wgcswCAYGBACORgEBMAsGBgQAjkYBAwIBCjAIBgYEAI5GA
QQwfAYGBACORgEFMHIwNhYwaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0b
3JpdW0vUUNBMV9QRFMucGRmEwJFTjA4FjJodHRwOi8vd3d3LnNpZ2lsbHVtLnBsL
3JlcG96eXRvcml1bS9RQ0ExX1BEU1BMLnBkZhMCUEwwFQYIKwYBBQUHCwIwCQYHB
ACL7EkBATATBgYEAI5GAQYwCQYHBACORgEGATBzBggrBgEFBQcBAQRnMGUwPgYIK
wYBBQUHMAKGMmh0dHA6Ly9yZXBvLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9xY
2ExXzIwMTcuY2VyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zaWdpbGx1bS5wb
DAdBgNVHQ4EFgQUVjnQyGMfM0fhHUvao3qe2tB5ZAMwCQYDVR0TBAIwADAfBgNVH
SMEGDAWgBRC+k+GNoGdKKGeLRq1ULuqJ/KctDCB+QYDVR0gBIHxMIHuMIHrBgoqh
GgBhvg9AAADMIHcMIHZBggrBgEFBQcCAjCBzAyByUt3YWxpZmlrb3dhbnkgY2Vyd
HlmaWthdCBwb2RwaXN1IGVsZWt0cm9uaWN6bmVnbyBwb3dzdGHFgiB3IG9wYXJja
XUgbyBQb2xpdHlrxJkgVXPFgnVnIFphdWZhbmlhIENVWiBTaWdpbGx1bS4gVHJlx
ZvEhyBQb2xpdHlraSBDVVogU2lnaWxsdW0gem5hamR1amUgc2nEmSBwb2QgYWRyZ
XNlbSBodHRwOi8vd3d3LnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bTBCBgNVHR8EO
zA5MDegNaAzhjFodHRwOi8vY3JsLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9xY
2ExXzIwMTcuY3JsMA4GA1UdDwEB/wQEAwIGQDANBgkqhkiG9w0BAQsFAAOCAgEAJ
fef0HktjHsgL403s8XQggtqporvp5w2sZcQ+jCPb3h3xrztTjiUbIhw97No7u5J5
LV4pNuczzBynJYBeGQpYG/Tr37HNoCdQ+I8QfllF37O7MwCNWYbmenFjINIHogQu
tizdHRIUDP5FY+3ZmTG0ZGz4Yi0Bw+6IEvLZM8SF7Ula9Bkyu/oF5SAN/h/f0t53
PHIkqsiWG7xRUl9aBgyO8Q72r1tiY1aqfT665nRrOewXQHik9h1Fd/XwWtYZpnGh
ws8lFKGB/Dfa8BpXpx3hWdVgeUA75Spszt0Pcb0pCJyQ2x3F4VnphGv6p31VN5id
7M+nd3kUYuKHFjxVBWgiVlgeKrCD+wvM/jqNncW6ti6uXaeLM2WBI0FpLuT5ZD2G
5gtLZ8z3wI5BZsp07gl3ARD8EybcJVmVhxpfAcBgOTCoyhGbPKYIS0fmYYCzwFLS
t+I497avrAQtgDqDcCs1WlZWHts4dUudUJ8rV8uKgtVQUu0HofUZPjNPD8dJw6n3
YrVdsLleXQXKAJZCgti56lH+6eCsVs7fUNPAhnu3AHWvsBwFs/3DM3OBBXX5jtn8
miSC46ndNiq2hIsq+cvfVM4Qw57XDYgLWaINhI0QhluUqOAEDJmYitnesTfs3Ih/
CCHBWG9Yw6XkaBk8TCks/OOuo9B9PFGt5wRasty/Ls=
-----END CERTIFICATE-----

Is there a more tolerant way to read ASN1 than the asn1parse command?

Angus










Reply | Threaded
Open this post in threaded view
|

Re: Unusual certificates

Hubert Kario
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.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

Reply | Threaded
Open this post in threaded view
|

Re: Unusual certificates

Angus Robertson - Magenta Systems Ltd
In reply to this post by Angus Robertson - Magenta Systems Ltd
More information, the original certificates supplied by the end user
had unwrapped base64 blocks, lines 2,500 long.  I wrapped them for
email.  

If I try the asn1parse command on the wrapped certificates, they now
attempt to parse, the OK is fine, the bad one now gives an error
message from asn1parse:

Error in encoding
20236:error:0D07209B:asn1 encoding routines:ASN1_get_object:too
long:crypto\asn1\asn1_lib.c:91:

and error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode
from PEM_read_bio_X509.  

The RFC says 'Parsers MAY handle other line sizes' but it would be good
if OpenSSL gave a 'PEM line too long' error rather than no error.  I'll
change my library code to check for line ending in the base64 to give
the user a polite message.  

Now the only problem is what is asn1 decoding unhappy with?

Angus


Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: Unusual certificates

OpenSSL - User mailing list
The second certificate seems garbaged at the 4th RDN of the issuerName.
The Base64 edition might have added or deleted some characters.

Cordialement,
Erwann Abalea

Le 25/06/2020 16:00, « openssl-users au nom de Angus Robertson - Magenta Systems Ltd » <[hidden email] au nom de [hidden email]> a écrit :

    More information, the original certificates supplied by the end user
    had unwrapped base64 blocks, lines 2,500 long.  I wrapped them for
    email.  

    If I try the asn1parse command on the wrapped certificates, they now
    attempt to parse, the OK is fine, the bad one now gives an error
    message from asn1parse:

    Error in encoding
    20236:error:0D07209B:asn1 encoding routines:ASN1_get_object:too
    long:crypto\asn1\asn1_lib.c:91:

    and error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode
    from PEM_read_bio_X509.  

    The RFC says 'Parsers MAY handle other line sizes' but it would be good
    if OpenSSL gave a 'PEM line too long' error rather than no error.  I'll
    change my library code to check for line ending in the base64 to give
    the user a polite message.  

    Now the only problem is what is asn1 decoding unhappy with?

    Angus



Reply | Threaded
Open this post in threaded view
|

Re: Unusual certificates

OpenSSL - User mailing list
In reply to this post by Hubert Kario
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

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: Unusual certificates

Angus Robertson - Magenta Systems Ltd
In reply to this post by OpenSSL - User mailing list
> The second certificate seems garbaged at the 4th RDN of the
> issuerName.
> The Base64 edition might have added or deleted some characters.

Sorry, looks like my manual word wrapping lost a character:

-----BEGIN CERTIFICATE-----
MIIHbDCCBVSgAwIBAgIIO7L2MrGOOTMwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV
BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy
dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ
MBcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAyMjQyMzAwMDBaFw0yMTAy
MjMyMzAwMDBaMHUxCzAJBgNVBAYTAlBMMRAwDgYDVQQEDAdTa2ltaW5hMRcwFQYD
VQQqDA5KYWNlayBXb2pjaWVjaDEaMBgGA1UEBRMRUE5PUEwtNzQwNjAyMDgyMTQx
HzAdBgNVBAMMFkphY2VrIFdvamNpZWNoIFNraW1pbmEwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDbTjEdIL21ctkfJ88d7EQDegNo5VLyPQXNSp5emoNI
Uf/y+RiL47SrWxS/hqYLGLUlItMsA+VCyP/+Oi42nRXcsJrSZdVgqhZTaWTZca8m
FOeujXy9eVvnAlnDDeofC5zAxYoW4fQI1/aPwmJ437bHWa6NR0iXT9j0caYfK8vr
P+gLlakBJA5RV42mt4CBZMSiNNhA9KMi9UNbtqSzlPEpSJn8Vo2LWUe+yIlUcbCD
gaQ5EVi8K7U0j5BLVQfVparZGi7C50V1ZPwWsYlu7v1PKHMDXPwUzOlwZ//UrxdR
nv/AFgjLjxuS+FNvCOaiyr0EmxccLKFvqycvx6qOxFulAgMBAAGjggLyMIIC7jCB
2wYIKwYBBQUHAQMEgc4wgcswCAYGBACORgEBMAsGBgQAjkYBAwIBCjAIBgYEAI5G
AQQwfAYGBACORgEFMHIwNhYwaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0
b3JpdW0vUUNBMV9QRFMucGRmEwJFTjA4FjJodHRwOi8vd3d3LnNpZ2lsbHVtLnBs
L3JlcG96eXRvcml1bS9RQ0ExX1BEU1BMLnBkZhMCUEwwFQYIKwYBBQUHCwIwCQYH
BACL7EkBATATBgYEAI5GAQYwCQYHBACORgEGATBzBggrBgEFBQcBAQRnMGUwPgYI
KwYBBQUHMAKGMmh0dHA6Ly9yZXBvLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9x
Y2ExXzIwMTcuY2VyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zaWdpbGx1bS5w
bDAdBgNVHQ4EFgQUVjnQyGMfM0fhHUvao3qe2tB5ZAMwCQYDVR0TBAIwADAfBgNV
HSMEGDAWgBRC+k+GNoGdKKGeLRq1ULuqJ/KctDCB+QYDVR0gBIHxMIHuMIHrBgoq
hGgBhvg9AAADMIHcMIHZBggrBgEFBQcCAjCBzAyByUt3YWxpZmlrb3dhbnkgY2Vy
dHlmaWthdCBwb2RwaXN1IGVsZWt0cm9uaWN6bmVnbyBwb3dzdGHFgiB3IG9wYXJj
aXUgbyBQb2xpdHlrxJkgVXPFgnVnIFphdWZhbmlhIENVWiBTaWdpbGx1bS4gVHJl
xZvEhyBQb2xpdHlraSBDVVogU2lnaWxsdW0gem5hamR1amUgc2nEmSBwb2QgYWRy
ZXNlbSBodHRwOi8vd3d3LnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bTBCBgNVHR8E
OzA5MDegNaAzhjFodHRwOi8vY3JsLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9x
Y2ExXzIwMTcuY3JsMA4GA1UdDwEB/wQEAwIGQDANBgkqhkiG9w0BAQsFAAOCAgEA
Jfef0HktjHsgL403s8XQggtqporvp5w2sZcQ+jCPb3h3xrztTjiUbIhw97No7u5J
5LV4pNuczzBynJYBeGQpYG/Tr37HNoCdQ+I8QfllF37O7MwCNWYbmenFjINIHogQ
utizdHRIUDP5FY+3ZmTG0ZGz4Yi0Bw+6IEvLZM8SF7Ula9Bkyu/oF5SAN/h/f0t5
3PHIkqsiWG7xRUl9aBgyO8Q72r1tiY1aqfT665nRrOewXQHik9h1Fd/XwWtYZpnG
hws8lFKGB/Dfa8BpXpx3hWdVgeUA75Spszt0Pcb0pCJyQ2x3F4VnphGv6p31VN5i
d7M+nd3kUYuKHFjxVBWgiVlgeKrCD+wvM/jqNncW6ti6uXaeLM2WBI0FpLuT5ZD2
G5gtLZ8z3wI5BZsp07gl3ARD8EybcJVmVhxpfAcBgOTCoyhGbPKYIS0fmYYCzwFL
St+I497avrAQtgDqDcCs1WlZWHts4dUudUJ8rV8uKgtVQUu0HofUZPjNPD8dJw6n
3YrVdsLleXQXKAJZCgti56lH+6eCsVs7fUNPAhnu3AHWvsBwFs/3DM3OBBXX5jtn
8miSC46ndNiq2hIsq+cvfVM4Qw57XDYgLWaINhI0QhluUqOAEDJmYitnesTfs3Ih
/CCHBWG9Yw6XkaBk8TCks/OOuo9B9PFGt5wRasty/Ls=
-----END CERTIFICATE-----


This now reads correctly with OpenSSL.  So the real error here was that
sometimes OpenSSL accepts unwrapped base64, and sometimes not, but
asn1parse never accepts it.

Angus