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