Request: Erreur : certificat auto-signé dans la chaîne de certificats

Créé le 5 févr. 2016  ·  14Commentaires  ·  Source: request/request

J'essaie d'analyser mes requêtes contre un serveur à l'aide de Charles Proxy. Le serveur utilise TSL, j'ai donc le faux certificat classique pour pouvoir afficher un trafic clair.

NodeJS / Request ne l'aime pas, donc mon script ne s'exécute pas et renvoie cette erreur.

Comment puis-je contourner cela?

                console.log('Response status: ' + response.statusCode);
                                                          ^
TypeError: Cannot read property 'statusCode' of undefined
    at Request._callback (/xxx:88:59)
    at self.callback (/xxx:199:22)
    at Request.emit (events.js:107:17)
    at Request.onRequestError (/xxx:821:8)
    at ClientRequest.emit (events.js:107:17)
    at TLSSocket.socketErrorListener (_http_client.js:271:9)
    at TLSSocket.emit (events.js:107:17)
    at TLSSocket.<anonymous> (_tls_wrap.js:942:18)
    at TLSSocket.emit (events.js:104:17)
    at TLSSocket._finishInit (_tls_wrap.js:460:8)
Error: Error: self signed certificate in certificate chain
Help (please use Stackoverflow)

Commentaire le plus utile

Merci pour l'explication. J'ai découvert comment éviter les problèmes avec les faux certificats au cas où quelqu'un serait intéressé :

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";

Avec cela, je peux utiliser une fausse authentification SSL pour inspecter les communications entre mon client et un serveur.

Tous les 14 commentaires

dans ce cas, response n'est pas défini.
la réponse n'a pas besoin d'être définie.
La réponse ne sera définie que si une réponse réelle est arrivée.
s'il y a eu une erreur de connexion, ce n'est pas le cas.

vérifiez que error soit défini, ou que response.statusCode soit supérieur ou égal à 400.

si vous voulez déboguer cette utilisation

env NODE_DEBUG="*" node asdf.js

Merci pour l'explication. J'ai découvert comment éviter les problèmes avec les faux certificats au cas où quelqu'un serait intéressé :

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";

Avec cela, je peux utiliser une fausse authentification SSL pour inspecter les communications entre mon client et un serveur.

Mon erreur était similaire mais maintenant je vais bien merci @nmaxcom

Erreur : impossible de vérifier le premier certificat
en erreur (natif)
chez TLSSocket.(_tls_wrap.js:929:36)
à TLSSocket.emit (events.js:104:17)
à TLSSocket._finishInit (_tls_wrap.js:460:8)

ou vous pouvez simplement utiliser let's encrypt, des certificats signés par une autorité de certification légitime.
les certificats auto-signés n'ont plus de sens maintenant.

request.get({ uri: 'https://mydocker.com/v2/_catalog', rejectUnauthorized: false }

Pour l'AC auto-signé, nous pouvons spécifier 'rejectUnauthorized = false'.
Vérifiez request.js à la ligne 623 et _tls_wrap.js dans node.js.

Les meilleures alternatives sont :
a) Effectuez la terminaison SSL sur votre équilibreur de charge
b) Utilisez un certificat gratuit

Vous disposez ainsi d'une configuration unique sur tous vos environnements.
Vous aurez une plus grande confiance dans vos déploiements et filtrerez les erreurs plus tôt.

rejeter worksuvres non autorisées dans options.rejectUnauthorized = false
mais pas dans options.agentOptions.rejectUnauthorized = false

Je ne sais pas pourquoi

https://github.com/request/request/blob/v2.81.1/request.js#L257 -L259

Désolé, ne voyez que le code. Je comprends que strictSSL n'est qu'un alias de rejectUnauthorized
Je dois dire que c'est un mauvais nom, utilisez simplement rejectUnauthorized 😭

obtenir cette erreur lors de l'exécution du code
Erreur d'analyse : erreur de syntaxe, 'var' inattendu (T_VAR), attente de la fin du fichier dans C:xampphtdocsPHPIMAPadminindex.php à la ligne 146

var notifier = require('mail-notifier');
var imap = {
nom d'utilisateur : « anandlintas2017 »,
mot de passe : "xxxxxxxxx",
hébergeur : "imap.gmail.com",
port : 993, // port imap
secure : true // utilise une connexion sécurisée
} ;

notifier(imap).on('mail',function(mail){console.log(mail);}).start();
?>

pour les personnes qui suggèrent de définir unlockUnauthorized=false, que se passe-t-il si j'ai des serveurs internes qui devraient avoir des connexions cryptées entre eux avec des certificats auto-signés , iguess setting shoutUnauthorized à false arrêtera l'erreur mais mes connexions sont 100% sujettes aux attaques MITM , je voir qu'il s'agit d'un bogue dans la bibliothèque nodejs tls dont il souffre et je ne trouve aucun correctif nulle part (j'ai google à la page 5 des résultats de google qui est vraiment profond) je ne sais pas comment les autres ne le font pas parlez-en, suis-je raté quelque chose ici ! !!!!! S'il vous plait corrigez moi si je me trompe !!

rejectUnauthorized works in options.rejectUnauthorized = false
but not in options.agentOptions.rejectUnauthorized = false

Les deux ne fonctionnent pas pour moi

request.get({ uri: 'https://s3.amazonaws.com/...',
    rejectUnauthorized: false,
    // strictSSL: false,
    proxy: '127.0.0.1:8080',
    agentOptions: {
        rejectUnauthorized: false,
        // strictSSL: false,
    },
}, (...args) => {
    console.log(args);
    process.exit();
});

PS Exécution du code depuis ELECTRON avec l'indicateur de désactivation SSL activé.

Pour moi, la désactivation de l'antivirus Kaspersky a résolu le problème.

https://github.com/request/request/issues/2061#issuecomment -182573171 semble être la réponse à la question générale

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0" ;

Ne donne aucun effet.

Cette page vous a été utile?
0 / 5 - 0 notes