error:0480006C:PEM routines::no start line

Reproduit sur Node 26 (OpenSSL 3.5) avec X509Certificate et tls.createSecureContext(). OpenSSL 1.1.1 affiche le même échec sous la forme « error:0909006C:PEM routines:get_name:no start line », OpenSSL 1.1.0 sous la forme « error:0906D06C:PEM routines:PEM_read_bio:no start line ». Une erreur voisine : « error:04800066:PEM routines::bad end line » lorsque le marqueur END est endommagé.

OpenSSL 3.x — also surfaces in Node as ERR_OSSL_PEM_NO_START_LINE

Ce que cela signifie

Un analyseur PEM a parcouru l’entrée à la recherche d’une ligne « -----BEGIN ...----- » correspondant à l’objet qu’il attend, sans jamais en trouver. Soit le fichier n’est pas du PEM du tout (DER binaire, JSON, fichier vide), soit le libellé BEGIN désigne un autre objet que celui que veut l’analyseur, soit l’encadrement a été altéré en chemin.

Pourquoi cela se produit

• Des données DER (binaires) transmises à un analyseur PEM

  fréquente

  Les fichiers .der/.cer/.pfx sont binaires ; par définition, ils ne contiennent aucune ligne BEGIN. Les chargeurs qui ne lisent que du PEM (tls.createSecureContext() pour un certificat, la ligne de commande d’OpenSSL 1.1) aboutissent précisément à cette erreur. (X509Certificate de Node et les commandes d’OpenSSL 3 détectent le DER d’eux-mêmes.)

• Libellé discordant : bon fichier, mauvais objet

  fréquente

  Chaque analyseur cherche son propre libellé. Le code qui lit des certificats ignore entièrement les blocs « -----BEGIN PRIVATE KEY----- » et signale « no start line », ce qui est techniquement exact : aucune ligne de début CERTIFICATE n’existe.

• Encadrement cassé pendant le transport

  fréquente

  Des séquences \n littérales provenant de variables d’environnement ou de JSON, ou des caractères qui ressemblent à des tirets collés depuis un éditeur de documents, empêchent la reconnaissance de la ligne BEGIN. Un BOM UTF-8 avant le premier tiret fait échouer OpenSSL 1.1 (OpenSSL 3 et Node l’ignorent) ; les fins de ligne CRLF de Windows et l’absence de saut de ligne final sont tolérées.

Comment corriger l’erreur

1. 1.

   Examiner les premiers octets

   Une seule ligne de xxd suffit à distinguer le PEM (tirets ASCII), le DER (premier octet 0x30) et les données inexploitables. Convertissez ou corrigez ensuite en conséquence.

   head -c 32 file | xxd
   # 2d 2d 2d 2d 2d ("-----")  → PEM: check the label matches what the tool expects
   # 30 82 ...                  → DER: add -inform der or convert:
   openssl x509 -inform der -in cert.der -out cert.pem

2. 2.

   Réparer un PEM altéré pendant le transport

   Rétablissez les sauts de ligne et supprimez le BOM et les CR. Après réparation, la ligne BEGIN doit se composer exactement de cinq tirets, du libellé et de cinq tirets.

   printf '%s' "$PEM_VAR" | sed 's/\\n/\n/g' | sed '1s/^\xef\xbb\xbf//' | tr -d '\r' > fixed.pem
   head -1 fixed.pem   # -----BEGIN CERTIFICATE-----

3. 3.

   Dans Node, normaliser avant l’analyse

   La même erreur apparaît avec le code ERR_OSSL_PEM_NO_START_LINE dans X509Certificate et dans l’option cert de tls.createSecureContext() ; corriger les sauts de ligne de la variable d’environnement résout la plupart des cas. En revanche, lorsque les chargeurs de clés (createPublicKey, createPrivateKey) ne peuvent pas analyser l’entrée, ils signalent « error:1E08010C:DECODER routines::unsupported ».

   import { X509Certificate } from "node:crypto";
   const cert = new X509Certificate(process.env.CERT_PEM.replace(/\\n/g, "\n"));

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