self-signed certificate in certificate chain

Node.js 16 und älter (OpenSSL 1.1.1) schrieben „self signed certificate in certificate chain“. Bei fetch() ist die Meldung die Ursache von „TypeError: fetch failed“; npm gibt sie als „npm error code SELF_SIGNED_CERT_IN_CHAIN“ aus.

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

Was der Fehler bedeutet

Die vom Server gesendete Kette endet bei einem selbstsignierten Root-Zertifikat, das nicht zu den Root-Zertifikaten gehört, denen Node.js vertraut. In einem Firmennetzwerk ist das die typische Handschrift eines Proxys mit TLS-Inspektion: Er signiert jede Website mit seinem eigenen Root-Zertifikat neu und nimmt dieses Root-Zertifikat in die Kette auf. Node.js verwendet seine mitgelieferte Root-Liste von Mozilla, nicht den Trust Store des Betriebssystems, in dem die IT das Root-Zertifikat des Proxys installiert hat.

Warum der Fehler auftritt

• Ein Proxy mit TLS-Inspektion oder ein Virenscanner

  häufig

  Zscaler, Netskope, Fortinet, Palo Alto und Antivirenprodukte mit HTTPS-Scan präsentieren ihr eigenes Root-Zertifikat. Browser vertrauen ihm über den Trust Store des Betriebssystems; Node.js tut das standardmäßig nicht.

• Ein privater Dienst sendet sein eigenes Root-Zertifikat

  häufig

  Auch wenn interne Server das Root-Zertifikat der Firma in ihre Kette aufnehmen, muss der Client diesem Root-Zertifikat vertrauen; das Mitsenden beweist nichts.

• Das Root-Zertifikat ist im Betriebssystem installiert, aber Node.js verwendet seine eigene Liste

  gelegentlich

  Node.js liefert die Root-Zertifikate von Mozilla in der Binärdatei mit und ignoriert den Trust Store des Systems, sofern nicht --use-system-ca oder NODE_USE_SYSTEM_CA=1 gesetzt ist.

So behebst du den Fehler

1. 1.

   Nachsehen, wer die Kette ausgestellt hat

   Geh die Zertifikatskette des Peers durch, die du beim Verbinden mit einer öffentlichen Website erhältst. Trägt das oberste Zertifikat den Namen deiner Firma oder eines Security-Anbieters, vertraue diesem Root-Zertifikat; ist es unbekannt, kläre die Herkunft, bevor du irgendeinem Zertifikat vertraust.

   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.

   Root-Zertifikat mit NODE_EXTRA_CA_CERTS hinzufügen

   Die Zertifikate aus der Datei werden für jede TLS-Verbindung des Prozesses zu den eingebauten Root-Zertifikaten hinzugefügt, auch für npm, yarn und fetch. Setze die Variable, bevor der Prozess startet.

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

3. 3.

   Trust Store des Betriebssystems verwenden

   --use-system-ca oder NODE_USE_SYSTEM_CA=1 lässt Node.js Root-Zertifikate akzeptieren, denen das Betriebssystem vertraut; so funktioniert das von der IT verteilte Root-Zertifikat des Proxys, ohne dass du Dateien kopieren musst.

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

   Vorübergehende Diagnose: NODE_TLS_REJECT_UNAUTHORIZED=0

   Schaltet die Zertifikatsprüfung für den gesamten Prozess ab. Nutze das nur für einen einzigen Lauf, um die Ursache zu bestätigen; hinter einem abfangenden Proxy verbirgt es zudem jeden Angreifer, der nicht der Proxy selbst ist.

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

← Gesamte Signaturfehler-Datenbank durchsuchen