Le nom d'hôte/IP de Node.js ne correspond pas aux noms alternatifs du certificat.

Question

J'ai un code :

var r = require('request');
r({
  method: 'POST',
  url: 'https://api.dropbox.com'},
  function() { console.log(arguments)  } )

Lorsque je l'exécute sur le bureau avec Node 0.9.4, j'obtiens ceci dans la console :

{ '0': [Error: Hostname/IP doesn't match certificate's altnames] }

Lorsque je l'exécute sur Netbook avec Node 0.6.12, tout fonctionne sans erreur (réponse 302 - je pense que c'est juste).

En question Le nom d'hôte/IP de Node.js ne correspond pas aux noms alternatifs des certificats. , Rojuinex écrire : "Ouais, problème de navigateur... désolé". Que signifie "problème de navigateur" ?

UPD. Ce problème a été résolu après le roll back sur Node v0.8.

Answer 1

Depuis la version 0.9.2 (y compris la 0.10.x), node.js valide désormais les certificats par défaut. C'est pourquoi vous pouvez constater que la validation devient plus stricte lorsque vous passez à la version 0.8 de node.js. (HT : https://github.com/mscdex/node-imap/issues/181#issuecomment-14781480 )

Vous pouvez éviter cela avec l'option {rejectUnauthorized:false} Cependant, cette option a de sérieuses implications en matière de sécurité . Tout ce que vous envoyez à l'homologue sera toujours crypté, mais il devient beaucoup plus facile de monter une attaque de type "man-in-the-middle", c'est-à-dire que vos données seront cryptées jusqu'au pair mais que le pair lui-même n'est pas le serveur que vous croyez !

Il serait préférable de diagnostiquer d'abord pourquoi le certificat ne s'autorise pas et de voir si cela peut être corrigé à la place.

Answer 2

Une réponse légèrement mise à jour (puisque j'ai rencontré ce problème dans des circonstances différentes).

Lorsque vous vous connectez à un serveur en utilisant SSL, la première chose que fait le serveur est de présenter un certificat qui dit "Je suis api.dropbox.com". Le certificat a un "sujet" et le sujet a un "CN" (abréviation de "common name".) Le certificat peut également avoir un ou plusieurs "subjectAltNames". Lorsque node.js se connecte à un serveur, node.js récupère ce certificat, puis vérifie que le nom de domaine auquel il pense se connecter (api.dropbox.com) correspond soit au CN du sujet, soit à l'un des altnames. Notez que, dans node 0.10.x, si vous vous connectez en utilisant une IP, l'adresse IP doit être dans les noms alternatifs - node.js n'essaiera pas de vérifier l'IP par rapport au CN.

Fixer le rejectUnauthorized à false permet de contourner cette vérification, mais tout d'abord, si le serveur vous donne des informations d'identification différentes de celles que vous attendez, il y a quelque chose de louche, et ensuite, cela contournera également d'autres vérifications - ce n'est pas une bonne idée si vous vous connectez sur Internet.

Si vous utilisez node >= 0.11.x, vous pouvez aussi spécifier un checkServerIdentity: function(host, cert) au module tls, qui devrait renvoyer la fonction undefined si vous voulez autoriser la connexion et lancer une exception sinon (bien que je ne sache pas si request transmettra ce drapeau par proxy à tls pour vous). Il peut être pratique de déclarer une telle fonction et de console.log(host, cert); pour comprendre ce qui se passe.

Answer 3

Pour corriger le problème pour le paquet http-proxy

1) HTTP (localhost) accédant à HTTPS Pour résoudre ce problème, définissez changeOrigin sur true.

const proxy = httpProxy.createProxyServer();

proxy.web(req, res, {
  changeOrigin: true,
  target: https://example.com:3000,
});

2) HTTPS accédant à HTTPS vous devez inclure le certificat SSL

httpProxy.createServer({
  ssl: {
    key: fs.readFileSync('valid-ssl-key.pem', 'utf8'),
    cert: fs.readFileSync('valid-ssl-cert.pem', 'utf8')
  },
  target: 'https://example.com:3000',
  secure: true
}).listen(443);

Answer 4

L'autre façon de résoudre ce problème dans d'autres circonstances est d'utiliser NODE_TLS_REJECT_UNAUTHORIZED=0 comme variable d'environnement

NODE_TLS_REJECT_UNAUTHORIZED=0 node server.js

AVERTISSEMENT : C'est une mauvaise idée du point de vue de la sécurité.

Answer 5

J'ai eu le même problème en utilisant le module de requête pour proxyer une requête POST provenant d'un autre endroit et c'est parce que j'ai laissé la propriété host dans l'en-tête (je copiais l'en-tête de la requête originale).