Я пытаюсь получить Узел https, сервер получил доступ через прокси узла.
Я купил сертификаты и получил автономный https хорошо работающий сервер. Первоначально были некоторые отклонения из-за нескольких сертификатов в одном файле, но это сообщение помогло:
http://stackoverflow.com/questions/16224064/running-ssl-node-js-server-with-godaddy-gd-bundle-crt.
Ранее у меня были все соединения через модуль прокси HTTP основанного на узле обратного nodejitsu прокси, который эффективно проксировал http-> http.
Теперь, как ожидалось, после получения целевого сервера изменился на https, прокси не работает, как это в основном:
client -> http-proxy(public IP) -> https connection(local IP)
который является эффективно man-in-the-middle сценарием, который является тем, что https стремится устранить.
Кроме того, я получил следующую ошибку от https сервера:
Error: Hostname/IP doesn't match certificate's altnames
Сертификаты очень хорошо, потому что https работает хорошо без прокси в середине. От чтения некоторых сообщений я понял, что следующее должно работать:
client -> https-proxy (Public IP) -> http connection (local IP)
Куда фактический локальный сервер выполняет http и общественность https. Это основано на объяснении в документации прокси HTTP:
https://github.com/nodejitsu/node-http-proxy
и в этом сообщении:
https://nadeesha.silvrback.com/creating-a-https-proxy-in-node-js
В документации модуля прокси HTTP, кажется, существует объяснение клиента-> https (прокси на общедоступном IP)-> https (прокси на локальном IP). Если так, какие сертификаты я должен настроить на цели https сервер?
Прежде чем я попробую любую из этих возможностей, я хотел бы знать: Что стандартные лучшие практики должны обработать это требование и как реализовать его под узлом. Я не хочу представлять Nginx или Apache только для обработки этого. Действительно ли я полностью вне дорожки здесь?
клиент -> https-proxy (публичный IP) -> http-соединение (локальный IP)
Это вполне корректная установка, при условии, что https-proxy (публичный IP) -> http-соединение (локальный IP)
находится по защищенной сети - т.е. ваш внутренний сервер не подвержен воздействию публичной сети.
клиент -> https-proxy (публичный IP) -> httpS-соединение (локальный IP)
В этом нет необходимости, если вы находитесь в частной сети и просто "перестарались" с вашим внутренним сервером и внешним прокси-сервером, выполняя шаги шифрования/дешифрования. Однако, это может потребоваться в некоторых сценариях, и, кроме того, современные компьютеры не так сильно задыхаются, делая шаги шифрования/дешифрования, как это было раньше. Но опять же, будет ли это ощущаться или нет, зависит от объема трафика
.