Request: Fehler: DEPTH_ZERO_SELF_SIGNED_CERT

Erstellt am 22. Jan. 2013  ·  51Kommentare  ·  Quelle: request/request

Ich verwende selbstsignierte Testzertifikate in meinem Apache2-Server und wenn ich die Anfrage aufrufe, erhalte ich die folgende Fehlermeldung:

Fehler: DEPTH_ZERO_SELF_SIGNED_CERT

Ich verwende den folgenden Code unten, um es zu testen. Beachten Sie, dass ich auch Nadel verwende und es mit der Option restoreUnauthorized=true funktioniert. Ich konnte auf Anfrage kein Äquivalent finden (ich habe strengSSL=false ausprobiert, aber ich denke, das ist die Standardeinstellung). Ich konnte auch keine anderen Beispiele finden, die das Problem lösen.

var request = require('request'),
    needle = require('needle');

request('https://127.0.0.1', function (error, response, body) {
  if (!error && response.statusCode == 200) {
    console.log("REQUEST:"+body);
  } else {
    console.error("REQUEST: "+error)
  }
});

needle.get('https://127.0.0.1',{rejectUnauthorized:false},function (error, response, body) {
  if (!error && response.statusCode == 200) {
    console.log("NEEDLE:"+body);
  }
});

Hilfreichster Kommentar

rejectUnauthorized: false hat bei mir nicht funktioniert. Stattdessen wurde der Fehler durch Hinzufügen des Folgenden behoben:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0" // Avoids DEPTH_ZERO_SELF_SIGNED_CERT error for self-signed certs

Alle 51 Kommentare

Selbes Problem hier. Verwenden von Knoten v0.10.1 und der neuesten Anforderungsversion.

gleiches Problem hier mit v0.10.2

Das gleiche Problem in v0.11.1-pre. Ich muss ungültige Zertifikate akzeptieren, weil ich ein Sicherheitstool entwickle.

@client = tls.connect @port , @target , {rejectUnhauthorized : false}, =>
@client.Nachricht schreiben
@client.setEncoding 'utf-8'

Der benötigte Code ist:

request({ url : 'https://127.0.0.1', rejectUnhauthorized : false }, function...

Edit: Ich habe den lahmen Kommentar entfernt, den ich gemacht habe, denn das ist einfach lahm von mir ....

rejectUnauthorized: false

rejectUnauthorized: false hat bei mir nicht funktioniert. Stattdessen wurde der Fehler durch Hinzufügen des Folgenden behoben:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0" // Avoids DEPTH_ZERO_SELF_SIGNED_CERT error for self-signed certs

Ich kann überprüfen, ob NODE_TLS_REJECT_UNAUTHORIZED=0 bei mir funktioniert, aber ablehnenUnauthorized: false nicht.
Verwenden von Knoten v0.10.1

@dankohn & @cliffano +1 für eure Vorschläge hier.

@case NODE_TLS_REJECT_UNAUTHORIZED ist nur eine Notlösung zu revert zu alten Verhaltensweisen (so dass ungültige und selbstsignierte Zertifikate) nach https://github.com/joyent/node/pull/4023 , so ist es nur eine Abhilfe für mich selbst zu bekommen -signiertes Zertifikat funktioniert.
Es sieht also so aus, als ob "rejectUnauthorized": false tut nicht das, was es tun soll.

Wir wissen, dass {rejectUnauthorized:false} in vielen Fällen funktioniert und in einigen anderen Fällen scheint es sich nicht auf den Kern auszubreiten. Die zu beantwortende Frage lautet: "Gibt es einen Randfall, in dem die Anforderung diese Option nicht richtig setzt oder beobachtet der Kern die Option in einigen Randfällen nicht richtig?"

Ich brauche einen vollständig reproduzierbaren Test, um diese Frage zu beantworten.

Leider habe ich keinen Testfall, aber das könnte hilfreich sein:

  • Der Server, mit dem ich spreche, erfordert aus irgendeinem Grund SSLv3 ( Python-Code als Referenz ; ich habe den gleichen Fehler in Node gesehen)
  • So erzwinge ich SSLv3 (was ich in Request nicht finden konnte): https.globalAgent.options.secureProtocol = 'SSLv3_method';

Hallo Leute,

Danke an alle, die an der Bibliothek arbeiten. Ich habe versucht, ein selbstsigniertes Zertifikat für einige Tests zu verwenden, und erhalte denselben Fehler. Details habe ich unten eingefügt. Lass es mich wissen, wenn du noch etwas brauchst. Ich habe alle Kombinationen der Verwendung von strictSSL und RejectUnauthorized ausprobiert, aber es scheint nicht zu funktionieren.

Knotenversion: 0.10.10
Betriebssystem: Windows 7 x64
OpenSSL: Win32 1.0.1e
Zertifikat generiert mit:
openssl genrsa –out priv.pem 1024
openssl req -x509 -new -key priv.pem -days 3650 -out cert.crt

Code zum Erstellen des Servers

var https = require('https');
var express = require('express');
var app = express();
var credentials = {
    key: fs.readFileSync(__dirname + '/priv.pem', 'utf8'),
    cert: fs.readFileSync(__dirname + '/cert.crt', 'utf8')
};
var server = https.createServer(credentials, app);
server.listen(3000);

Anfrage wie folgt verwenden:

var request = require('request');
request.defaults({
    strictSSL: false, // allow us to use our self-signed cert for testing
    rejectUnauthorized: false
});
request('https://localhost:3000', function(err) {
    console.error(err); // outputs the zero_depth error
});

@dankohn hat für mich gearbeitet

Da [email protected] und nodejs v0.10.15 rejectUnauthorized: false immer noch nicht funktionieren, muss ich immer noch diesen Hack verwenden:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0"

Was hässlich ist, denn ich möchte die Gültigkeit prüfen und selbstsignierte Zertifikate akzeptieren.

Habe das Problem beim Schreiben eines Tests gefunden, konnte es aber nicht replizieren.

Hatte ein interessantes Auftreten dieses Problems. Setzen Sie strictSSL: false, was bei einer Box funktionierte, bei einer anderen jedoch nicht (rejectUnauthorized=false ist ebenfalls fehlgeschlagen). Der Vorschlag von

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";

Funktioniert auch für Restler.

Ich konnte es mit rejectUnauthorized: false (Knoten v0.10.26) zum Laufen bringen.

Ich weiß, ist geschlossen und zusammengeführt
aber vielleicht erwähnenswert:
einige Bibliotheken von Drittanbietern hängen immer noch von der Anfrage ab und können ohne rejectUnauthorized: false

Ist das immer noch ein Thema?

Das ist so alt, dass ich schließe, wenn es tatsächlich noch ein Problem ist, lass es mich wissen und ich öffne wieder.

Das ist immer noch ein Thema für mich

Knoten 0.10.31 / Anfrage: 2.42.0

Screenshot: http://screencast.com/t/hcmHPBlxOHc

request.defaults(
  strictSSL: false # allow us to use our self-signed cert for testing
  rejectUnauthorized: false)

request "https://localhost:8000/index.html", (err, res, body) ->
  return console.error err if err # DEPTH_ZERO_SELF_SIGNED_CERT

Ich habe auch immer noch ein Problem damit, v0.10.20

Verwendung von process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0"; Trick für jetzt

@frankfuu denkst du, dass dieser "Trick" in der Dokumentation enthalten sein sollte?

Ja, wir könnten einige Dokumente und Tests für SSL-Probleme wie dieses und #811 verwenden. Sollte das Akzeptieren aller Zertifikate und das Akzeptieren nur der gewünschten Zertifikate beinhalten.

@syszer möglicherweise? naja zumindest fand ich es nützlich

Für mich immer noch ein Problem, v0.10.22.

@dankohn , @cliffano wo hast du die "NODE_TLS_REJECT_UNAUTHORIZED" : "0" eingefügt?

Das ist mein Code (funktioniert nicht):
var Seife = require('Seife');
var url = ' https://link.to/my/url/file.wsdl ';
var args = {Email: ' [email protected] ', Passwort: 'passwort123', deviceMac: '00-14-22-01-23-45'};
soap.createClient(url, {"NODE_TLS_REJECT_UNAUTHORIZED" : "0"}, function(err, client) {
client.myOperation(args, function(err, result) {
Konsole.log(Fehler, Ergebnis);
});
});

Setzen Sie es direkt an den Anfang der Datei:

// Avoids DEPTH_ZERO_SELF_SIGNED_CERT error for self-signed certs.
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';

Dan Kohn mailto:[email protected]
Tel: +1-415-233-1000

Am Donnerstag, den 9. Oktober 2014 um 11:41 Uhr schrieb Thanh [email protected] :

@dankohn https://github.com/dankohn , @cliffano
https://github.com/cliffano wo hast du das hingelegt
"NODE_TLS_REJECT_UNAUTHORIZED" : "0" in?

Das ist mein Code (funktioniert nicht):
var Seife = require('Seife');
var url = ' https://link.to/my/url/file.wsdl ';
var args = {Email: ' [email protected] ', Passwort: 'passwort123', deviceMac:
'00-14-22-01-23-45'};
Seife.createClient(url, {"NODE_TLS_REJECT_UNAUTHORIZED" : "0"},
Funktion (Fehler, Kunde) {
client.myOperation(args, function(err, result) {
Konsole.log(Fehler, Ergebnis);
});
});


Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/mikeal/request/issues/418#issuecomment -58528954.

@dankohn : Ich bekomme immer noch die gleiche Fehlermeldung. Mein Code sieht jetzt so aus:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
var Seife = require('Seife');
var url = ' https://link.to/my/url/file.wsdl ';
var args = {Email: ' [email protected] ', Passwort: 'passwort123', deviceMac: '00-14-22-01-23-45'};
soap.createClient(url, {rejectUna uthorized:false }, function(err, client) {
client.myOperation(args, function(err, result) {
Konsole.log(Fehler, Ergebnis);
});
});

@apiton :

meine URL beginnt nicht mit " https://www. " sondern " https://link. " kann es sein, dass dies das Problem ist?

@jksdua Beispiel war üblich und ich konnte den Fehler reproduzieren.

Um sowohl das @ fourq- als auch das @ jksdua- Problem zu lösen, möchten Sie dies tun

var request = require('request');
var request = request.defaults({
  strictSSL: false,
  rejectUnauthorized: false
});

Oder

var request = require('request').defaults({
  strictSSL: false,
  rejectUnauthorized: false
});

Die Methode defaults gibt eine Funktion zurück.
Sie müssen der Funktion also die Variable request zuweisen, damit die Standardoptionen funktionieren.

Kannst du auch rejectUnauthorized ?

Wenn Sie immer noch Probleme haben, würde ich gerne einen weiteren Testfall bekommen.

@thadeuszlay Ich weiß, dass Sie gerade um Hilfe bei der Verwendung gebeten haben:
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";

Brauchen Sie dabei noch Hilfe?

Beachten Sie, dass Sie in der Version 2.45.0 von Request nur strictSSL auf false setzen können, und dann wird rejectUnauthorized false gesetzt.

Wenn Sie jedoch strictSSL als false angeben, wird rejectUnauthorized standardmäßig auf undefined .
Ich gehe davon aus, dass das das gewünschte Verhalten ist.

Hallo @seanstrom

Ich erinnere mich nicht an das Beispiel, das ich gemacht habe, aber es war ähnlich wie bei @fourq

request.defaults(
striktes SSL: false
ablehnenUnberechtigt: false)

Ich habe keine Probleme mehr, seit ich "den Trick" verwende.

@frankfuu
Basierend auf dem Beispiel von @fourq habe ich diese Lösung oben gefunden.
https://github.com/mikeal/request/issues/418#issuecomment -58959393

Kannst du mal reinschauen, ob das bei dir funktioniert?

Beachten Sie, dass Sie in der Version 2.45.0 von Request nur strictSSL auf false setzen können, und dann wird auch disableUnauthorized ebenfalls false.

Ist wfm dort, wo es zuvor ohne RejectUnauthorized fehlgeschlagen ist.

@andig mein Chat-Jargon ist ein wenig verschwommen, also bestätige ich nur, dass du sagst:
Die Verwendung von strictSSL: false funktioniert für Sie
Richtig?

@andig mein Chat-Jargon ist ein wenig verschwommen, also bestätige ich nur, dass du sagst:

@seanstrom bitte verzeihen Sie die kindische Sprache.

Verwenden von strictSSL: false funktioniert für Sie. Richtig?

Richtig. Meine frühere fehlgeschlagene SSL-Verbindung, die RejectUnauthorized: false erforderte, funktioniert jetzt mit strictSSL: false only.

Ich werde dieses Thema schließen
Wenn dies immer noch ein Problem für jemanden ist, werde ich es erneut öffnen.
Gib mir Bescheid

immer noch ein Problem hier v10.0.32
beim Versuch process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
Ich bekomme:
_stream_readable.js:748
throw new Error('Kann jetzt nicht in den alten Modus wechseln.');

@webduvet können Sie uns ein Codebeispiel geben?
Das wird uns helfen, dieses Problem zu beheben

@seanstrom sicher, es war ein sehr einfaches Beispiel aus dem Nodejs-Dokument.

 process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
 var tls = erfordern('tls');
 var fs = erfordern('fs');
 var-Optionen = {
 cert: fs.readFileSync('test-cert.pem'),
 striktes SSL: false
 };
 var cleartextStream = tls.connect(8000, options, function() {
 console.log('Client verbunden',
 cleartextStream.authorized ? 'autorisiert' : 'nicht autorisiert');
 process.stdin.pipe(cleartextStream);
 process.stdin.resume();
 });

@seanstrom Ich

Die Sache ist, ablehnenUnautorisiert: false deaktiviert alle Überprüfungen, richtig? Weil es funktioniert, auch wenn ich kein PEM oder Schlüssel oder eine Liste akzeptabler Zertifikate anbiete. Ich muss ein Zertifikat (oder einen Schlüssel) bereitstellen und den Support der Anfrage-Engine tatsächlich die Zertifikatsliste überprüfen lassen.

Ja, rejectUnauthorized: false oder strictSSL: false sind keine idealen Lösungen, da sie alle Zertifikatsüberprüfungen deaktivieren. Es ist jedoch möglich, eigene CAs für selbstsignierte oder nicht erkannte Zertifikate hinzuzufügen. Ein Beispiel dafür finden Sie in unseren HTTPS-Tests: https://github.com/request/request/blob/master/tests/test-https.js

Danke, Nylen. Dieser Test hat uns geholfen aufzuklären, was wir falsch gemacht haben. Wir haben selbstsignierte Zertifikate verwendet, anstatt zuerst eine selbstsignierte Zertifizierungsstelle zu erstellen und dann diese Zertifizierungsstelle zum Signieren des Serverzertifikats zu verwenden. Ich dachte, das würden wir tun, aber das taten wir nicht.

Für diejenigen, die ein Prinzip verstehen wollen.

https://nodejs.org/dist/v0.12.9/docs/api/tls.html#tls_tls_connect_options_callback

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "1";
var tls = require('tls');
var fs = require('fs');
var constants = require('constants');
var util = require('util');

var options = {
    host: 'localhost',
    strictSSL: true,
    ca: [fs.readFileSync('trusted1.pem'), fs.readFileSync('trusted2.pem') ],
    rejectUnauthorized: true, // Trust to listed certificates only. Don't trust even google's certificates.
    secureOptions: constants.SSL_OP_NO_SSLv3 | constants.SSL_OP_NO_SSLv2 | constants.SSL_OP_NO_TLSv1 | constants.SSL_OP_NO_TLSv1_1,
    secureProtocol: 'SSLv23_method',
    ciphers: 'ECDHE-RSA-AES128-SHA256'
};

var socket = tls.connect(3001, options, function() {
    console.log('client connected',
        socket.authorized ? 'authorized' : 'unauthorized',
        socket.encrypted ? 'encrypted' : 'unencrypted',
        '\nCipher: ' + util.inspect(socket.getCipher()),
        '\nCert Info: \n' + util.inspect(socket.getPeerCertificate(true)));
    //process.stdin.pipe(socket);
    //process.stdin.resume();
});

Es hört sich wirklich so an, als ob alle Ihre Probleme darin bestehen, dass Ihr Client-System keine SSL-Zertifikatskonfiguration hat
Konfigurieren Sie zuerst Ihre Systeme openSsl unds, dann fügen Sie Ihre Anfrage hinzu, ob es sich um Get oder Post handelt, an process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0"; es würde funktionieren inshaa Allah

Hi,

Ich stehe vor dem ähnlichen Problem, jedoch nur in der Methode "POST", während "GET" einwandfrei funktioniert. Hier die Detailinformationen:

Testcode:

`
var frisby = erfordern('frisby');
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";

var CONF = process.env['CONF'];
var config = require('../config/' + CONF);
var data = require('../tests_data/batch_data.json');

frisby.globalSetup({
Anfrage: {
striktes SSL: falsch,
ablehnenUnberechtigt: falsch,-
headers: {'Autorisierung': 'token'},
inspectOnFailure: wahr
}
});

frisby.create('Test#1: Sunny Day-Szenario')
.post(config.api_url + data.api_endpoint, data.test_strace, {rejectUnauthorized: false}, {json: true})
.inspectHeaders()
.inspectRequest()
.inspectJSON()
.expectJSON(data.batch_test_response_1)
.werfen();
`

Ausführungsfehler:
Fehler-1
Message: Error: Error parsing JSON string: Unexpected token D Given: Destination URL may be down or URL is invalid, Error: ESOCKETTIMEDOUT Stacktrace: Error: Error parsing JSON string: Unexpected token D Given: Destination URL may be down or URL is invalid, Error: ESOCKETTIMEDOUT at _jsonParse (/usr/src/app/frisby_api/node_modules/frisby/lib/frisby.js:1219:11) at null.<anonymous> (/usr/src/app/frisby_api/node_modules/frisby/lib/frisby.js:650:20) at null.<anonymous> (/usr/src/app/frisby_api/node_modules/frisby/lib/frisby.js:1074:43) at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

Fehler-2

Message: TypeError: Cannot read property 'headers' of undefined Stacktrace: TypeError: Cannot read property 'headers' of undefined at Frisby.<anonymous> (/usr/src/app/frisby_api/node_modules/frisby/lib/frisby.js:894:20) at Frisby.<anonymous> (/usr/src/app/frisby_api/node_modules/frisby/lib/frisby.js:940:8) at null.<anonymous> (/usr/src/app/frisby_api/node_modules/frisby/lib/frisby.js:1112:18) at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

Was sollte hier aktualisiert werden, um diese Probleme zu beheben?

Danke

füge dies hinzu und es sollte es lösen:

https.globalAgent.options.rejectUnauthorized = false;

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen