Node.js Имя хоста / IP не соответствует именам альт

У меня есть код:

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

Когда я запускаю его на рабочем столе с Node 0.9.4, я получаю его в консоли:

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

Когда я запускаю его на нетбуке с узлом 0,6.12, все работает без ошибок (ответ 302 – я думаю, это правильно).

В вопросе Node.js имя хоста / IP не соответствует сертификатам altnames , Rojuinex пишет: «Да, проблема с браузером … извините». Что означает «проблема браузера»?

UPD. Эта проблема была решена после откат на узле v0.8

Поскольку 0.9.2 (включая 0.10.x) node.js теперь проверяет сертификаты по умолчанию. Вот почему вы могли видеть, что он становится более строгим, когда вы обновляете узел node.js 0.8. (HT: https://github.com/mscdex/node-imap/issues/181#issuecomment-14781480 )

Вы можете избежать этого с помощью {rejectUnauthorized:false} , однако это имеет серьезные последствия для безопасности . Все, что вы отправляете партнеру, по-прежнему будет зашифровано, но гораздо проще установить атаку «человек в середине», то есть ваши данные будут зашифрованы для однорангового узла, но сам сверстник не является сервером, который вы так считаете!

Было бы лучше сначала диагностировать, почему сертификат не авторизуется, и посмотреть, можно ли это исправить.

Немного обновленный ответ (так как я столкнулся с этой проблемой в разных обстоятельствах).

Когда вы подключаетесь к серверу с использованием SSL, первое, что делает сервер, – это сертификат, в котором говорится: «Я api.dropbox.com». У сертификата есть «субъект», и у субъекта есть «CN» (сокращение от «общего имени».) В сертификате также может быть одно или несколько «subjectAltNames». Когда node.js подключается к серверу, node.js извлекает этот сертификат, а затем проверяет, соответствует ли доменное имя, на которое он ссылается (api.dropbox.com), либо CN, либо одно из имен. Обратите внимание, что в узле 0.10.x, если вы подключаетесь с использованием IP-адреса, IP-адрес должен находиться в именах altnames. Node.js не будет пытаться проверить IP-адрес на CN.

Установка флага rejectUnauthorized в значение false будет rejectUnauthorized вокруг этой проверки, но прежде всего, если сервер предоставляет вам разные учетные данные, чем вы ожидаете, происходит что-то подозрительное, а во-вторых, это также обходит другие проверки – это не очень хорошая идея, если вы подключаетесь через Интернет.

Если вы используете node> = 0.11.x, вы также можете указать функцию checkServerIdentity: function(host, cert) для модуля tls, которая должна возвращаться undefined если вы хотите разрешить соединение и исключить исключение в противном случае (хотя я не знаю ‘t знать, если request проксирует этот флаг через tls для вас.) Может быть удобно объявить такую ​​функцию и console.log(host, cert); чтобы понять, что происходит.

Я знаю, что это старо, НО для кого-то еще смотрящего:

Удалите https: // из имени хоста и добавьте порт 443.

 { method: 'POST', hostname: 'api.dropbox.com', port: 443 } 

Если вы используете пакет http-proxy , это происходит, когда ваш сервер является HTTP (например, localhost), а целью является HTTPS. Чтобы исправить эту проблему, установите для параметра changeOrigin значение true.

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

Если ваш сервер HTTPS, а целевой – HTTPS, вы должны включить сертификат 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); 

У меня была такая же проблема с использованием модуля запроса для запроса POST-запроса из другого места, и это было потому, что я оставил свойство хоста в заголовке (я копировал заголовок из исходного запроса).

Другой способ исправить это в других обстоятельствах – использовать NODE_TLS_REJECT_UNAUTHORIZED=0 в качестве переменной среды

NODE_TLS_REJECT_UNAUTHORIZED=0 node server.js

У нас нет этой проблемы, если мы тестируем наш клиентский запрос с адресом назначения localhost ( host или hostname на node.js), а общее имя нашего сервера CN = localhost в сертификате сервера. Но даже если мы изменим localhost на 127.0.0.1 или на любой другой IP-адрес, мы получим ошибку. Hostname/IP doesn't match certificate's altnames на node.js или SSL handshake failed в QT.

У меня была такая же проблема с моим сертификатом сервера по моему запросу клиента. Чтобы решить эту проблему в моем приложении node.js для клиента, мне нужно было поставить subjectAltName на моем server_extension со следующим значением:

 [ server_extension ] . . . subjectAltName = @alt_names_server [alt_names_server] IP.1 = xxxx 

и затем я использую -extension когда я создаю и подписываю сертификат.

пример:

В моем случае я сначала экспортирую файл конфигурации эмитента, так как этот файл server_extension файл server_extension :

 export OPENSSL_CONF=intermed-ca.cnf 

поэтому я создаю и подписываю свой серверный сертификат:

 openssl ca \ -in server.req.pem \ -out server.cert.pem \ -extensions server_extension \ -startdate `date +%y%m%d000000Z -u -d -2day` \ -enddate `date +%y%m%d000000Z -u -d +2years+1day` 

Он отлично работает на клиентах на основе node.js с запросами https, но он не работает с клиентами на основе QT QSsl, когда мы определяем sslConfiguration.setPeerVerifyMode(QSslSocket::VerifyPeer) , если мы не используем QSslSocket::VerifyNone это не сработает , Если мы используем VerifyNone это заставит наше приложение не проверять сертификат партнера, чтобы он принял любой сертификат. Поэтому, чтобы решить эту проблему, мне нужно изменить общее имя своего сервера в своем сертификате и заменить его значение для IP-адреса, на котором работает мой сервер.

например:

CN = 127.0.0.1

После проверки того, что сертификат выдается известным центром сертификации (CA), будут проверяться альтернативные имена субъекта, или общее имя будет проверено, чтобы проверить соответствие имени хоста. Это находится в функции checkServerIdentity . Если у сертификата есть альтернативные имена объекта и имя хоста отсутствует в списке, вы увидите сообщение об ошибке:

Имя хоста / IP не соответствует именам альт

Если у вас есть сертификат CA, который используется для создания сертификата, который вы используете (как правило, при использовании самозаверяющих сертификатов), это может быть обеспечено

 var r = require('request'); var opts = { method: "POST", ca: fs.readFileSync("ca.cer") }; r('https://api.dropbox.com', opts, function (error, response, body) { // do something }); 

Это подтвердит, что сертификат выдается CA, но проверка имени хоста будет выполнена. Просто поставка CA будет достаточной, если сертификат содержит имя хоста в альтернативных именах темы. Если это не так, и вы также хотите пропустить проверку имени хоста, вы можете передать функцию noop для checkServerIdentity

 var r = require('request'); var opts = { method: "POST", ca: fs.readFileSync("ca.cer"), agentOptions: { checkServerIdentity: function() {} } }; r('https://api.dropbox.com', opts, function (error, response, body) { // do something }); 
  • SyntaxError: использование const в строгом режиме?
  • Загрузка изображений с помощью node.js
  • Что такое опция -save для установки npm?
  • Как использовать модули npm из машинописного текста?
  • Удаление сопоставлений маршрутов в NodeJS Express
  • Присвоение имени домена локальному хосту для среды разработки
  • E11000 дублирует ключевой индекс ошибки в mongodb mongoose
  • Любой способ заставить строгий режим в узле?
  • Как обмениваться сеансами с Socket.IO 1.x и Express 4.x?
  • Внесение изменений в несколько записей на основе изменения одной записи с помощью SQL
  • Как установить node.js в качестве службы Windows?
  • Давайте будем гением компьютера.