asn1: structure error: tags don't match

Le message complet ajoute les tags attendu et trouvé ainsi que le contexte du champ, par exemple « tags don't match (16 vs {class:0 tag:2 ...}) ... AlgorithmIdentifier @2 ». Les entrées tronquées produisent l’erreur voisine « asn1: syntax error: data truncated ». Dans les versions actuelles de Go, le message provient des analyseurs de clés publiques et PKCS#8 ; x509.ParseCertificate signale les mêmes erreurs sous la forme « x509: malformed certificate ».

Go encoding/asn1 — surfaced through crypto/x509 parsers

Ce que cela signifie

Le décodeur DER de Go a trouvé un tag ASN.1 différent de celui qu’exige la structure cible : vous analysez du DER à peu près valide dans la mauvaise structure Go, ou quelque chose qui n’est pas du DER du tout. Les nombres du message sont des tags ASN.1 (16 = SEQUENCE, 2 = INTEGER, 13 dans un fichier PEM = le tiret par lequel il commence), qui permettent généralement d’identifier précisément la confusion.

Pourquoi cela se produit

• Octets PEM passés à un analyseur DER

  fréquente

  ParsePKIXPublicKey, ParsePKCS8PrivateKey et consorts attendent du DER brut. Leur passer du texte PEM (tirets et base64) sans appeler pem.Decode au préalable est de loin le déclencheur le plus courant. (ParseCertificate rejette lui aussi le texte PEM, avec « x509: malformed certificate ».)

• Mauvais analyseur pour le conteneur de clé

  fréquente

  Une clé privée ou un certificat entier fourni à ParsePKIXPublicKey : chaque conteneur a une structure distincte, et la vérification des tags détecte l’inversion dès le premier champ divergent. L’inversion des analyseurs de clé privée est signalée plus utilement : ParseECPrivateKey appliqué à des octets PKCS#8 indique « x509: failed to parse private key (use ParsePKCS8PrivateKey instead for this key format) », et inversement.

• Ce n’est ni un certificat ni une clé

  occasionnelle

  Une signature brute de 64 octets, un JWT ou des octets de tramage d’un protocole analysés comme de l’ASN.1. Si l’entrée commence par autre chose que 0x30 (SEQUENCE), aucun analyseur de la famille X.509 ne l’acceptera.

Comment corriger l’erreur

1. 1.

   Toujours commencer par pem.Decode

   Extrayez le bloc DER (et vérifiez son libellé) avant d’appeler un analyseur.

   block, _ := pem.Decode(pemBytes)
   if block == nil {
       return fmt.Errorf("input is not PEM")
   }
   cert, err := x509.ParseCertificate(block.Bytes)   // block.Type == "CERTIFICATE"

2. 2.

   Essayer les analyseurs de conteneurs dans l’ordre

   Quand le conteneur de la clé privée est inconnu, essayez PKCS#8, puis SEC1, puis PKCS#1 : c’est le tri habituel pour des clés de provenances diverses.

   if k, err := x509.ParsePKCS8PrivateKey(der); err == nil { return k, nil }
   if k, err := x509.ParseECPrivateKey(der); err == nil { return k, nil }
   if k, err := x509.ParsePKCS1PrivateKey(der); err == nil { return k, nil }
   return nil, errors.New("unrecognized private key format")

3. 3.

   Examiner les premiers octets

   Une seule ligne de hexdump vous indique si vous avez bien affaire à du DER, et openssl asn1parse montre la structure à comparer avec l’analyseur que vous avez choisi.

   head -c 16 key.der | xxd          # 30 81/82 ... → SEQUENCE, plausibly DER
   openssl asn1parse -inform der -in key.der | head -3

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