LINUX.ORG.RU
ФорумAdmin

Где должен быть сертификат для фронта и бекенда для работы https - https

 , , ,


0

1

Коллеги, добрый день!

Изучаю варианты работы фронта nginx для ssl.

Есть желание добиться работы https фронта с https бекендом (например, apache).

Непонятно следующее:

  1. можно ли разместить сертификат только на бекенде, а на фронте не размещать?
  2. если размещать сертификат на фронте и на бекенде то как запрашивать его через certbot? Ведь он выдаст ошибку во второй раз на тот же домен.
  3. если включить SSL на фронте, но не указать сертификат то получим ошибку «укажите сертификат». То есть получение сертификата с бекенда невозможно?

Пример конфигурации nginx:

server {
   listen 443 ssl;
   server_name example.yourdomain.com;
   ssl_certificate  /path/to/your/certificate; 
   ssl_certificate_key  /path/to/your/certificate/key; 
   ssl_prefer_server_ciphers on;

   location / {
        proxy_pass https://localhost:4430;

        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For 
   $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto $scheme;
    }
}

Кто как вообще организует распределенные веб приложения для работы с https?

UPDATE1 Чтобы снять вопросы, распишу конкретную ситуацию:

  1. Есть VPS с публичным IPv4, она выполняет роль публичного веб-сервера на nginx
  2. Есть сервера за NAT, например, на апач (чтобы проще было, бывали и на nodejs, но тут не важно)
  3. Запросы http на публичный и проксирование на http закрытый сервер идут отлично. Реверс-прокси типа http-http работает
  4. Запросы https - http тоже отлично работают. Это когда мы сертификат выкатываем на фронт, а в proxy_pass шлем на http порт сервера за NAT.

Исследование https - https начал после развертывания простейшего сайта на вордпресс, который ранее работал на https сервере напрямую (без проксирования и прочего). Просто так он не встает, требуются манипуляции с базой данных и правки wp_config. Обнаружил множество похожих ситуаций и вопросы без ответа, веб-приложения разные при этом. Основной вопрос - как правильно? https - https правильно или не нужно? Если правильно, то как выкатывать сертификат, руками оба раза на сервер фронта и сервер бека? Руками же не очень профессионально кажется)



Последнее исправление: job_maker (всего исправлений: 5)

Ты сначала разберись, кто на ком стоит. Фронт, бекенд, терминов куча, а понимания нет.

В интернете нет никаких фронтов и бекендов. В интернете есть клиенты и серверы.

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

Проще всего: nginx отвечает за обработку HTTPS, за отдачу статики и за обработку динамических запросов. Апач выкинуть и всё.

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 2)

Надо наверно описать что за итоговую задачу ты решаешь, потому что желания странные. Отвечу сначала тупо на вопросы, а потом прокомментирую неправоту в желаниях.

1) Можно, но тогда вместо nginx_http придётся использовать nginx_stream и вобщем-то непонятно зачем он вообще нужен будет.

2) Если ты запросил сертификат и у тебя он уже есть в виде файла - можешь его раскладывать по любым местам, заново запрашивать каждой проге не нужно.

3) Верно. Автоматически он его не станет скачивать. Хотя теоретически и мог бы, если бы авторы nginx такое захотели делать. Но посколькоу это что-то странное - не сделали.

Теперь комментарии.

1) Зачем https на бекэнде? Он в другой сети через интернет находится? Если он в защищённой от внешних влияний локалке то смысла в https нет. Делать бек не в локалке смысла тоже нет. Грузить его ssl-терминацией - тоже не очень идея.

2) Зачем апач? Он устарел больше 10 лет назад.

3) certbot - не очень хороший вариант для запроса сертификатов, есть более хорошие легковесные клиенты к letsencrypt (например acme_tiny), но если не хочешь возиться с настройкой то наверно сойдёт

proxy_pass https://localhost:4430;

Если бек на том же компе что и фронт - то тем более нет никакого смысла в навешивании на бек https. Он добавит только расход cpu time и лишние мысли об обновлениях его ssl настроек.

firkax ★★★★★
()
Ответ на: комментарий от vbr

Да нет, с терминами у него всё в порядке. Фронт это то что показывается в интернет для юзеров, а бек это спрятанный за ним сервер, который обрабатывает логику запросов, но не хочет вникать в подробности публичного интернет-взаимодействия, его ещё сервером приложений называют.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

У этих терминов настолько расплывчатое значение, что за использование их вне чётко определённого контекста надо лишать пятничной пиццы. У меня фронт это веб-приложение на реакте, а бек это веб-приложение на ноде, и работают они на одном и том же сервере. Который спрятан за нгинксом, к примеру, который в данной конфигурации ни фронтом, ни беком не является. А нгинкс ещё и за haproxy балансером. У мобильщиков бэк это сервер, обрабатывающий их запросы. И всё это имеет очень опосредованное отношение к сетевой архитектуре, про которую топикстартер и пытается задать вопрос.

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от vbr

Ну это у тебя проблемы что что-то расплывчато, а я прекрасно сразу понял о чём речь.

фронт это веб-приложение на реакте, а бек это веб-приложение на ноде

😱

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

Где у тебя там фронтэнд, если в конфиге реверспрокси нарисован?

Если у тебя вопрос нужен ли хттпс между нжиниксом и апачем, то в общем случае нет, если ты считаешь внутреннюю сеть безопасной. Если не считаешь - то возможны варианты.

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от vbr

Фронт - это публичный VPS [br]Бекенд - это закрытый сервер за NAT в ЦОД. С помощью сетевых устройств безопасность обмена данными VPS - сервер в ЦОД выполнена.

Как вы расписали тут не подойдет. Вы предлагаете сделать несколько location для 1 сервера. У меня серверов минимум 2 (для конкретного примера = 2).

Сразу скажу, пофиксить веб-приложение можно, но мне бы хотелось понять материал, как правильно делать архитектуру для https-https запросов.

job_maker
() автор топика
Последнее исправление: job_maker (всего исправлений: 1)
Ответ на: комментарий от firkax
  1. понял. это типа как HAProxy будет? сервера разделены, на одном не сделаешь. У меня есть фронт для имен и прокси и есть много ресурсов в закрытом ЦОД. [code] stream { server { listen 25565; #Указываем nginx прослушивать порт 25565 (TCP) proxy_pass IP:15555; #Указываем, куда будет направляться трафик } } [/code] такое?

  2. Руками понятно. Но хотелось бы автоматизации. Типа щелк - разложил сертификаты, добавил в cron обновление. Можно между серверами файлы автоматом отправлять через скрипты, но хотел знать может есть более красивое решение.

  3. понял. вот тут [link]https://дягилевы.рф/index.php/unix/24-wordpress-na-bekende-nginx-apache[/link] таки ввели в заблуждение. Даже в документации описан только способ с указанием сертификата в конфиге nginx.

По комментам:

  1. Да, бекенд находится в защищенной сети и в другом ЦОД. По идее можно не делать и обойтись https -> http. Так я уже умею :) Но хочетcя и другие ситуации посмотреть, пойти вглубь так сказать :)

  2. просто как пример. пусть будет nodejs, или что угодно. На бекенде настроить ssl не сложно. На фронте тоже. Мне непонятно как это сделать удобно для администрирования.

  3. вот хочу повозиться ибо старый линукс задрот)) спасибо за наводку, поковыряю.

job_maker
() автор топика
Ответ на: комментарий от ya-betmen

Да, nginx как реверс прокси.

Внутреннюю сеть безопасной не считаю. Разное возможно. По сетевым слоям там сам знаю как сделать, но на уровне веб-приложения пока не очень понимаю.

job_maker
() автор топика
Ответ на: комментарий от job_maker

1. Да, но поскольку у тебя nginx то наверно ты хочешь как-то вмешиваться в http протокол посередине и этот вариант не годится.

2. Так по крону и можно копировать везде где нужно. Любые типовые действия можно автоматизировать, в чём бы они ни заключались.

3. Да, там определённо нерабочий конфиг без указания сертификата.

---

1. Но эти другие ситуации крайне редко нужны. А так, если на беке https - отличия будут в основном на беке. Фронту надо всё так же прописать куда проксировать и всё. Можно ещё настроить nginx чтобы он проверял сертификат бека при коннекте к нему, раз уж хочешь этими средствами защищать фронт-бек соединение.

firkax ★★★★★
()
Ответ на: комментарий от firkax
  1. да, согласен.
  2. понял, попробую сделать простенький скрипт на распространение сертификатов. Тут задача не сложная :)
  3. Так и думал. Да и nginx -t прямо намекает на это :)))

[quote] Можно ещё настроить nginx чтобы он проверял сертификат бека при коннекте к нему, раз уж хочешь этими средствами защищать фронт-бек соединение. [/quote] а это как? Наверное, предварительно разложить сертификат на фронт и на бек, а потом?… [code]

client certificate

ssl_client_certificate /etc/nginx/client_certs/ca.crt;

можно включить проверку опционально и обрабатывать далее, возвращая 403

ssl_verify_client optional;

либо обязательная проверка сертификата

ssl_verify_client on;

[/code] вот такое?

job_maker
() автор топика
Ответ на: комментарий от firkax

Зачем https на бекэнде? Он в другой сети через интернет находится? Если он в защищённой от внешних влияний локалке то смысла в https нет.

Некоторое ПО, хочет реверсивное прокси именно через ssl. А так да, в большинстве случаев это не нужно.

einhander ★★★★★
()
Ответ на: комментарий от job_maker

Нет, я про proxy_ssl_verify/proxy_ssl_trusted_certificate.

А ещё можно на беке проверять что к нему подключается настоящий фронт - тогда надо чтоб nginx слал беку тоже какой-то сертификат, это настраивается proxy_ssl_certificate/proxy_ssl_certificate_key. А как настроить бек чтобы он это проверял это уже вопрос к беку. Если бек - тоже nginx то это ssl_verify_client, да (на беке).

firkax ★★★★★
()
Ответ на: комментарий от einhander

О!

То есть схема типа: [code] Фронт nginx: server { # The listen directive serves content based on the port defined # For IPv4 addresses # For IPv6 addresses

# Replace the below if you have a domain name pointed to the server
server_name biotox.ru;

access_log /var/log/nginx/reverse-access.log;
error_log /var/log/nginx/reverse-error.log;

location / {
			# Specify the proxied server's address
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass https://ip:443;
}

listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example-site/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example-site/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

[/code]

Бекенд apache:

[code]

<VirtualHost *:443> ServerName example-site DocumentRoot /var/www/example-site SSLEngine on SSLCertificateFile ssl/cert.pem # самоподписанный серт SSLCertificateKeyFile ssl/cert.key # самоподписанный серт #SSLCertificateChainFile ssl/cert.ca-bundle # самоподписанный серт

[/code]

… будет работать?

job_maker
() автор топика
Последнее исправление: job_maker (всего исправлений: 1)
Ответ на: комментарий от job_maker

Кстати да, пожалуй это даже лучше чем раскидывать туда публичный сертификат - не придётся беку давать секретный ключ от внешнего https. По умолчанию nginx-у пофиг какой именно там сертификат, а чтоб было не пофиг - я выше написал (proxy_ssl_verify) и надо указать этот самоподписанный доверенным для прокси-коннекта.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Понял! спасибо, углублюсь в этот вопрос. Авторизация через ssl для клиент-сервера по сути. Только в разрезе nginx-nginx или nginx-apache.

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

Теперь модель понятна, буду в лабе тестировать! Коллеги, спасибо! Реально помогли!

job_maker
() автор топика
Последнее исправление: job_maker (всего исправлений: 2)
Ответ на: комментарий от job_maker

Эм нет, подключается фронт к беку а не наоборот. И отключать проверку не надо, надо правильно её настроить - указать доверенным именно этот самоподписанный сертификат. Систему публичных CA (как браузеры) nginx тут не применяет, доверяет только тому что ты ему непосредственно укажешь.

firkax ★★★★★
()
Ответ на: комментарий от Shushundr

1) повторю, проксировать на http2 бек - фича не нужная, поэтому скорее всего её никто не умеет (про nginx я писал из тех же соображений); сейчас обычно даже на http1 не проксируют а используют ещё более простые протоколы типа fastcgi

2) чего умеет проксировать апач - мне вдвойне безразлично, потому что апач не нужен

firkax ★★★★★
()
Ответ на: комментарий от job_maker

Внутреннюю сеть безопасной не считаю.

Кто-то может попасть во внутреннюю сеть но при этом не будет иметь доступа к хостам на которых живут нжиникс и апач или на сетевую железку, которая между?

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от einhander

Если тот софт реализован в виде прибитых гвоздями апач-модулей то придётся использовать апач, да. И, возможно, даже апач 1.3, если прибито к нему. Ну, бывает легаси. Но зачем из этого апача при этом что-то куда-то проксировать, да ещё и по http2-протоколу - непонятно.

firkax ★★★★★
()
Ответ на: комментарий от ya-betmen

Да, может быть сторонний доступ в сеть для сервиса, к примеру. ВМки в отдельном VLAN лежат, туда тоже бывает посторонние ковыряться идут для отладки программного слоя на некоторых ВМ.

На сетевую железку уже скорее нет, чем да.

job_maker
() автор топика
Ответ на: комментарий от job_maker

туда тоже бывает посторонние ковыряться идут для отладки программного слоя на некоторых ВМ.

Я правильно понял, что железо тоже несекурно? Если да, то при равной сложностипопадания в сеть и на железку смысла в ссл внутри нет - всё равно проходной двор. Если всё же в сеть попасть сильно проще то есть вариант запилить ссл с авторизацией по клиентскому серту.

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

В сеть попасть проще, так как проводятся сервисные работы третьими лицами, на железку только если целенаправленно ломиться, да и зафиксирую я такое.

Да, выше обсудили вариант с авторизацией по сертификату клиента. Мне понравилась схема, собираю в лабе пока неспешно.

job_maker
() автор топика
Последнее исправление: job_maker (всего исправлений: 1)
Ответ на: комментарий от job_maker

Ещё рассмотри вариант организовать VPN на базе того же wireguard, и его уже считать доверенным. Или организовать несколько сетей, одна доверенная, другая - нет. В целом я тоже думаю, что ради одного соединения поднимать VPN смысла нет, но если их станет больше, то может оказаться проще в одном месте обеспечить безопасность, а не держать вагон сертификатов и ключей (а если у вас, не дай бог, заведётся безопасник и потребует ротацию каждого организовать…)

vbr ★★★★
()