self-signed certificate in certificate chain

Node.js 16 et les versions antérieures (OpenSSL 1.1.1) l’écrivaient « self signed certificate in certificate chain ». Avec fetch(), il s’agit de la cause de « TypeError: fetch failed » ; npm l’affiche sous la forme « npm error code SELF_SIGNED_CERT_IN_CHAIN ».

Node.js tls / https / fetch — code SELF_SIGNED_CERT_IN_CHAIN (OpenSSL X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN, 19)

Ce que cela signifie

La chaîne envoyée par le serveur se termine par un certificat racine auto-signé qui ne figure pas parmi les racines auxquelles Node.js fait confiance. Sur un réseau d’entreprise, c’est la signature typique d’un proxy d’inspection TLS : il re-signe chaque site avec sa propre racine et inclut cette racine dans la chaîne. Node.js utilise la liste de racines Mozilla qu’il embarque, et non le magasin de certificats du système d’exploitation où le service informatique a installé la racine du proxy.

Pourquoi cela se produit

• Un proxy d’inspection TLS ou un antivirus

  fréquente

  Zscaler, Netskope, Fortinet, Palo Alto et les antivirus qui analysent le HTTPS présentent leur propre racine. Les navigateurs lui font confiance via le magasin du système d’exploitation ; Node.js, par défaut, non.

• Un service privé envoie sa propre racine

  fréquente

  Les serveurs internes qui incluent la racine de l’entreprise dans leur chaîne exigent malgré tout que cette racine soit approuvée sur le client ; l’envoyer ne prouve rien.

• La racine est installée dans le système d’exploitation, mais Node.js utilise sa propre liste

  occasionnelle

  Node.js embarque les racines de Mozilla dans le binaire et ignore le magasin du système, sauf si --use-system-ca ou NODE_USE_SYSTEM_CA=1 est défini.

Comment corriger l’erreur

1. 1.

   Voir qui a émis la chaîne

   Parcourez la chaîne de certificats présentée par un site public. Si le certificat du sommet porte le nom de votre entreprise ou d’un éditeur de solutions de sécurité, faites confiance à cette racine ; s’il est inconnu, enquêtez avant d’accorder votre confiance à quoi que ce soit.

   openssl s_client -connect registry.npmjs.org:443 -servername registry.npmjs.org -showcerts </dev/null 2>/dev/null \
     | grep -E '^ *[0-9]+ s:|^ *i:'
   # The last line pair shows the root the chain ends in (s: and i: identical)

2. 2.

   Ajouter la racine avec NODE_EXTRA_CA_CERTS

   Les certificats du fichier s’ajoutent aux racines intégrées pour chaque connexion TLS du processus, y compris npm, yarn et fetch. Définissez la variable avant le démarrage du processus.

   export NODE_EXTRA_CA_CERTS=/etc/ssl/private-ca/corp-proxy-root.pem
   node app.js

3. 3.

   Utiliser le magasin du système d’exploitation

   --use-system-ca ou NODE_USE_SYSTEM_CA=1 fait accepter à Node.js les racines approuvées par le système d’exploitation : la racine du proxy déployée par le service informatique fonctionne donc sans copie de fichiers.

   # Managed machines already trust the proxy root in the OS store
   node --use-system-ca app.js
   NODE_USE_SYSTEM_CA=1 npm run build

4. 4.

   Diagnostic temporaire : NODE_TLS_REJECT_UNAUTHORIZED=0

   Désactive la vérification des certificats pour tout le processus. Ne l’utilisez que le temps d’une exécution, pour confirmer la cause ; derrière un proxy d’interception, cela masque aussi tout attaquant qui n’est pas le proxy.

   # Temporary diagnostic only: confirms trust is the only problem, then remove it
   NODE_TLS_REJECT_UNAUTHORIZED=0 node app.js

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