Назад | Перейти на главную страницу

Реализация SSL-сертификата для стека с лаком и несколькими веб-серверами NGINX

В моем текущем стеке есть Varnish -> NGINX (2 сервера) под управлением Drupal -> MySql.

Весь статический контент кэшируется и обслуживается Varnish по HTTP. Однако, когда пользователь регистрируется и хочет приобрести план, соединение с платежным шлюзом осуществляется через HTTPS. В настоящее время сертификат реализован на одном из серверов NGINX. Запись домена указывает на этот сервер NGINX.

Я собираюсь указать A-запись домена на сервер Varnish, чтобы я мог воспользоваться кешированием Varnish вместо загрузки сервера NGINX. Любой посетитель, который намеревается совершить покупку, будет переведен на NGINX. У меня есть два сомнения

  1. Должен ли я сгенерировать другой сертификат для второго сервера NGINX или достаточно просто реализовать сертификат, доступный на первом сервере, на втором?
  2. Эта установка вызовет какие-либо проблемы? У меня такое чувство, потому что серверы, содержащие сертификат, больше не имеют сопоставленного домена.

РЕДАКТИРОВАТЬ: я намерен, чтобы Varnish прослушивал порт 443 и передавал все запросы HTTPS на сервер NGINX

Varnish не поддерживает SSL-обертку (https) трафик, следовательно, вы должен использовать терминатор SSL перед ним.

Для этого можно использовать несколько различных приложений. Все они завершают SSL и пересылают http трафик на ваш сервер (Varnish):

  • (стандартный) веб-сервер http, который поддерживает SSL-подобный Apache или nginx
  • специальный терминатор SSL (называемый wrapper) лайк шпилька или станнель
  • специальный обратный прокси / балансировщик нагрузки с поддержкой SSL, например фунт

Предпочтительно приложение, специально разработанное для завершения запросов SSL и / или прокси.
В качестве веб-сервера nginx подошло бы лучше, чем Apache так как обычно считается более быстрым для статического контента или прокси.
nginx также упрощает компиляцию конкретной сборки с минимальными накладными расходами, которая содержит только все необходимые модули (http_core, http_proxy и http_ssl модули).

Когда весь SSL прерывается на терминаторе, ваш бэкэнд nginx экземплярам вообще ничего не нужно знать о SSL (кроме возврата правильного имени хоста и схемы во всех ссылках).
Следовательно, он не требует сертификата и закрытого ключа.