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

Reproduit avec OpenSSL 3.6 ; OpenSSL 1.1.x affiche le même échec sous la forme « error:0D07209B:asn1 encoding routines:ASN1_get_object:too long ». L’erreur très recherchée « header too long » (error:0680007B sous OpenSSL 3, error:0D07207B sous 1.1.x) en est une voisine : l’entrée se termine avant que l’en-tête tag-longueur lui-même soit complet (fichier vide ou d’un seul octet, ou en-tête coupé au milieu du champ de longueur).

Ce que cela signifie

L’analyseur DER a lu ce qui devait être un en-tête ASN.1 tag-longueur et a obtenu une longueur supérieure aux données disponibles : la signature classique de « ces octets ne sont pas du DER ». En général, l’entrée est du texte base64, du PEM ou des données tronquées analysées comme du DER brut, et non une structure subtilement cassée.

Pourquoi cela se produit

• Texte Base64/PEM analysé comme du DER binaire

  fréquente

  Des caractères ASCII interprétés comme des octets de tag ou de longueur produisent immédiatement des longueurs absurdes. Passer -inform der alors que le fichier est en PEM (ou envoyer du base64 dans un pipe sans décodage) est le cas d’école.

• DER tronqué

  fréquente

  Un téléchargement interrompu, une limite de taille de colonne en base de données ou un copier-coller qui perd les derniers octets laissent un en-tête qui annonce plus de contenu qu’il n’en existe. La longueur de la SEQUENCE extérieure ne correspond plus à la taille du fichier.

• Données concaténées ou décalées

  occasionnelle

  Des octets en trop avant la vraie structure (en-têtes HTTP enregistrés dans le fichier, tramage d’un autre protocole) décalent l’analyseur vers des octets qui se lisent comme un en-tête invalide, signalé par cette erreur ou par sa voisine « header too long » selon les octets. Un court préfixe de longueur peut aussi fausser l’analyse sans bruit : asn1parse affiche alors une première ligne absurde au lieu d’échouer.

Comment corriger l’erreur

1. 1.

   Faire correspondre le format d’entrée à l’analyseur

   Décodez d’abord le base64, ou indiquez à l’outil qu’il s’agit de PEM. asn1parse attend une entrée PEM par défaut ; -inform der est réservé aux données réellement binaires.

   # 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.

   Vérifier les tailles avant l’analyse

   Pour une signature ECDSA P-256 en DER, attendez-vous à environ 70 à 72 octets commençant par 0x30. Une « signature » de 96 octets est probablement du base64 ; 64 octets correspondent à r‖s brut, qui n’est pas du tout du DER.

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

3. 3.

   S’il s’agit d’une signature r‖s brute, la convertir

   JWS et WebCrypto produisent des signatures ECDSA brutes de 64 octets qu’aucun analyseur DER n’acceptera. Le convertisseur ci-dessous transforme le format brut en DER (et inversement) et affiche les entiers r et s : collez les octets et voyez quel format vous avez réellement entre les mains.

← Parcourir toute la base de données des erreurs de signature