error:0680009B:asn1 encoding routines:ASN1_get_object:too long

Reproduziert mit OpenSSL 3.6; OpenSSL 1.1.x gibt denselben Fehler als „error:0D07209B:asn1 encoding routines:ASN1_get_object:too long“ aus. Das viel gesuchte „header too long“ (error:0680007B unter OpenSSL 3, error:0D07207B unter 1.1.x) ist ein verwandter Fehler: Die Eingabe endet, bevor der Header aus Tag und Länge selbst vollständig ist – eine leere Datei, eine Datei mit nur einem Byte oder ein Header, der mitten in der Längenangabe abbricht.

Was der Fehler bedeutet

Der DER-Parser hat gelesen, was ein ASN.1-Header aus Tag und Länge sein sollte, und eine Länge erhalten, die über die vorhandenen Daten hinausgeht – das klassische Anzeichen für „diese Bytes sind kein DER“. Meist ist die Eingabe base64-Text, PEM oder abgeschnittene Daten, die als rohes DER geparst werden, und keine subtil beschädigte Struktur.

Warum der Fehler auftritt

• Base64-/PEM-Text als binäres DER geparst

  häufig

  ASCII-Zeichen, die als Tag- und Längenbytes interpretiert werden, ergeben sofort absurde Längen. Der Lehrbuchfall ist -inform der, obwohl die Datei PEM ist (oder base64, das ohne Dekodieren per Pipe weitergereicht wird).

• Abgeschnittenes DER

  häufig

  Ein abgebrochener Download, eine Längenbegrenzung der Datenbankspalte oder Kopieren und Einfügen, bei dem die letzten Bytes verloren gehen, hinterlässt einen Header, der mehr Inhalt ankündigt, als vorhanden ist. Die Länge der äußeren SEQUENCE stimmt nicht mehr mit der Dateigröße überein.

• Aneinandergehängte oder versetzte Daten

  gelegentlich

  Zusätzliche Bytes vor der eigentlichen Struktur – in die Datei mitgespeicherte HTTP-Header, das Framing eines anderen Protokolls – verschieben den Parser in Bytes, die sich als ungültiger Header lesen. Je nach Bytes wird das als dieser Fehler oder als sein Verwandter „header too long“ gemeldet. Ein kurzes Längenpräfix kann auch stillschweigend falsch geparst werden: asn1parse gibt dann eine unsinnige erste Zeile aus, statt fehlzuschlagen.

So behebst du den Fehler

1. 1.

   Eingabeformat auf den Parser abstimmen

   Dekodiere zuerst das base64 oder sag dem Tool, dass es sich um PEM handelt. asn1parse erwartet standardmäßig eine PEM-Eingabe; -inform der ist nur für echte Binärdaten gedacht.

   # base64 signature/blob → DER, then parse
   openssl base64 -d -in sig.b64 | openssl asn1parse -inform der
   
   # PEM object: let asn1parse handle the armor itself
   openssl asn1parse -in cert.pem

2. 2.

   Größen vor dem Parsen prüfen

   Rechne bei einer DER-kodierten ECDSA-Signatur mit P-256 mit etwa 70–72 Byte, beginnend mit 0x30. Eine 96 Byte lange „Signatur“ ist wahrscheinlich base64; 64 Byte sind rohes r‖s, also gar kein DER.

   wc -c < sig.der
   head -c 8 sig.der | xxd   # 30 44/45/46 ... → DER SEQUENCE

3. 3.

   Bei einer rohen r‖s-Signatur: konvertieren

   JWS und WebCrypto erzeugen rohe ECDSA-Signaturen mit 64 Byte, die kein DER-Parser akzeptiert. Der Konverter unten wandelt das Rohformat in DER um (und zurück) und zeigt die Ganzzahlen r und s an – füge die Bytes ein und sieh nach, welches Format du tatsächlich vor dir hast.

← Gesamte Signaturfehler-Datenbank durchsuchen