error:1E08010C:DECODER routines::unsupported

Reproduit sur Node 26 / OpenSSL 3.x. La CLI d’OpenSSL affiche la forme longue : « error:1E08010C:DECODER routines:OSSL_DECODER_from_bio:unsupported ». Sous Node ≤16 (OpenSSL 1.1.1), les mêmes erreurs produisaient des messages différents.

Node.js crypto (OpenSSL 3) — code ERR_OSSL_UNSUPPORTED

Ce que cela signifie

Le décodeur d’OpenSSL 3 n’a pas pu analyser le matériel de clé que vous avez passé à createPrivateKey(), createPublicKey(), sign() ou verify(). Malgré le mot « unsupported », il ne s’agit presque jamais d’un algorithme manquant : cela signifie que les octets ne forment une clé lisible dans aucun des formats essayés par le décodeur.

Pourquoi cela se produit

• PEM issu d’une variable d’environnement avec des \n littéraux

  fréquente

  Les gestionnaires de secrets et les fichiers .env fournissent souvent « -----BEGIN PRIVATE KEY-----\nMIG... », où \n est formé de deux caractères (une barre oblique inverse suivie de n). OpenSSL voit un fichier d’une seule ligne sans encadrement PEM valide et abandonne.

• Chaîne vide ou contenu qui n’est pas une clé

  fréquente

  La variable contient "", un chemin de fichier (au lieu du contenu du fichier), un blob JSON ou un certificat alors qu’une clé brute était attendue. Tout ce qui n’est pas du matériel de clé PEM/DER aboutit exactement à cette erreur.

• Mauvaise classe de clé pour l’API

  fréquente

  Passer le PEM d’une clé publique à createPrivateKey() échoue avec ce message : le décodeur cherche une structure de clé privée et n’en trouve aucune. L’inverse n’est pas une erreur : createPublicKey() accepte une clé privée et en dérive la moitié publique.

• Octets DER sans métadonnées de format

  occasionnelle

  Du DER brut passé sous forme de simple Buffer est analysé par défaut comme du PEM. Sans { format: "der", type: "pkcs8" | "spki" | "sec1" }, le décodeur ne peut pas savoir à quelle structure s’attendre.

Comment corriger l’erreur

1. 1.

   Normaliser les PEM issus de variables d’environnement et vérifier l’étiquette

   Rétablissez les sauts de ligne et affichez la première ligne. Si l’étiquette est celle d’une clé publique (PUBLIC KEY) là où vous appelez createPrivateKey, la variable est reliée à la mauvaise clé.

   const pem = process.env.SIGNING_KEY.replace(/\\n/g, "\n");
   console.log(pem.split("\n")[0]);
   // -----BEGIN PRIVATE KEY-----      → createPrivateKey(pem)
   // -----BEGIN PUBLIC KEY-----       → createPublicKey(pem)
   // -----BEGIN EC PRIVATE KEY-----   → createPrivateKey(pem)  (SEC1, also fine)

2. 2.

   Déclarer explicitement le DER

   Lorsque la clé est du DER binaire (issu d’un blob de base de données, d’une conversion JWKS ou de protobuf), indiquez le format et le type ; le décodeur ne les devinera pas.

   import { createPrivateKey } from "node:crypto";
   
   const key = createPrivateKey({
     key: derBuffer,
     format: "der",
     type: "pkcs8",   // or "sec1" for BEGIN EC PRIVATE KEY material
   });

3. 3.

   Vérifier le matériel de clé en dehors de Node

   Laissez OpenSSL vous dire ce que sont réellement ces octets. Si cela échoue aussi, ce sont les données elles-mêmes qui sont endommagées : corrigez la source, pas l’appel Node.

   openssl pkey -in key.pem -noout -text | head
   # for DER:
   openssl pkey -in key.der -inform der -noout -text | head

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