Nginx с несколькими перенаправленными доменами и сертификатом letsencrypt

Я пытаюсь настроить Nginx в качестве прокси-сервера для всех серверов разработки, расположенных за моим статическим IP-адресом.

Я прочитал этот вопрос: Позволяет зашифровать с помощью обратного прокси-сервера nginx

Уже, и это часть моего пути (Это дает мне хорошо известный каталог на одном из виртуальных серверов.), но мои настройки достаточно разные, так что есть еще один шаг, который мне нужен, чтобы сделать эту работу, и пока Iv'e не смог проработать этот шаг, любые эксперты Nginx там, я уверен, что мог бы сделать с рукой Вот.

Текущая установка

Итак, в настоящее время у меня есть один статический IP-адрес, для целей этого вопроса можно называть его

1.2.3.4

В DNS моего хост-провайдера у меня настроено 2 маршрута DNS с подстановочными знаками (Кстати, у меня есть полный контроль над ними, поэтому, если в итоге окажется, что легче просто изменить записи DNS, чем использовать файл, тогда я сделаю это.), 2 маршрута с подстановочными знаками

*.example.com -> 1.2.3.4
*.anotherexample.com -> 1.2.3.4

Таким образом, независимо от того, что вводится для этих двух доменов, они ВСЕГДА имеют один и тот же статический IP-адрес.

http://example.com/ , http://doodah.example.com/ , http://biscuits.anotherexample.com/ и так далее ВСЕ приходят к 1.2.3.4

Внутри этого IP-адреса через порт, управляемый NAT, пересылка с 80 снаружи на 80 внутри (Я могу открывать другие по мере необходимости, например: 443) - это сервер с одним заданием и только одним заданием.

На этом сервере запущен Nginx в Ubuntu 16.04 LTS, он проверяет имя входящего хоста, а затем передает это соединение другому серверу.

Так например

http://www.example.com/ будет прокси перенаправлен на сервер, на котором запущен этот веб-сайт

http://application.anotherexample.com/ будет прокси-сервером, на котором когда-либо сервер запускает приложение, связанное с этим именем хоста

два виртуальных сервера являются особенными в том смысле, что они настроены на ответ на

* .example.com и * .anotherexample.com

Итак, если приходит запрос на idonetexist.example.com в конечном итоге он будет обслуживать веб-сайт по умолчанию для example.com и аналогично noserverhere.anotherexample.com будет делать то же самое.

Это означает, что независимо от того, какой хост / поддомен получает этот прокси-сервер, что-то будет доставлено.

Итак, для обработки этих двух подстановочных знаков у меня есть следующие два файла конфигурации:

server {

  listen 80;

  server_name
    example.com
    www.example.com
    *.example.com;

  location /.well-known {
    alias /var/www/html/letsencrypt;
  }

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://address.of-the.internal.example-webserver
    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_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;
    access_log /var/log/nginx/example.com.log;
    error_log /var/log/nginx/example.com.log error;

  }
}

и

server {

  listen 80;

  server_name
    anotherexample.com
    www.anotherexample.com
    *.anotherexample.com;

  location /.well-known {
    alias /var/www/html/letsencrypt;
  }

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://address.of-the.internal.anotherexample-webserver
    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_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;
    access_log /var/log/nginx/anotherexample.com.log;
    error_log /var/log/nginx/anotherexample.com.log error;

  }
}

Пока все это работает отлично, и любые запросы от Let's encrypt для проверки SSL-сертификатов в каталоге ". Well-known" работают, но именно в этот момент мой вариант использования начинает отклоняться от исходного вопроса, который я связал в верх моего вопроса.

Чтобы реализовать другие виртуальные серверы, например, указывающие на приложения и другие поддомены в любом из двух моих зарегистрированных доменов, у меня есть несколько конфигураций виртуальных серверов, поэтому, например, у меня будут другие конфигурации, которые выглядят как следующий:

server {

  listen 80;

  server_name application1.example.com;

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://internal.address.of-example-app-one
    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_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;
    access_log /var/log/nginx/exampleappone.access.log;
    error_log /var/log/nginx/exampleappone.error.log error;

  }
}

server {

  listen 80;

  server_name application2.example.com;

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://internal.address.of-example-app-two
    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_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;
    access_log /var/log/nginx/exampleapptwo.access.log;
    error_log /var/log/nginx/exampleapptwo.error.log error;

  }
}

и

server {

  listen 80;

  server_name application1.anotherexample.com;

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://internal.address.of-anotherexample-app-one
    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_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;
    access_log /var/log/nginx/anotherexampleappone.access.log;
    error_log /var/log/nginx/anotherexampleappone.error.log error;

  }
}

Когда новое приложение добавляется на внутренние серверы, создается новый файл конфигурации на основе показанных выше с соответствующими изменениями, который затем сохраняется в / и т.д. / nginx / сайты-доступные / вместе со всеми другими файлами конфигурации.

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

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

Чего я пытаюсь достичь

С ответом на первый вопрос, на который я ссылался выше, я начал работать с обработкой сайтов по умолчанию, то есть с сайтами, которые НЕ имеют отдельной конфигурации для их прокси-сервера на другой сервер, и это делает Let's encrypt счастливым, потому что он может найти свои идентификационные файлы, чтобы доказать, что я владею двумя доменами.

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

Что я хотел бы сделать, так это найти способ получить подстановочные сертификаты * .example.com и * .anotherexample.com от Let's encrypt, все автоматизированные с использованием certbot, с автоматическим продлением.

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

На мой взгляд, что-то подсказывает мне, что ключом к этому является фактическое применение SSL к фактическому серверу "по умолчанию", который создает Nginx, но поскольку я не могу назначить ему несколько сертификатов, я не верю, что буду возможность назначать сертификаты example.com и anotherexample.com на одном виртуальном сервере.

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

Еще одна мысль, которая у меня была (Что я собираюсь поиграть после того, как закончу набирать это) заключается в том, чтобы поставить другой прокси впереди, единственная ответственность которого заключается в том, чтобы принять соединение, отправить сертификат, а затем передать соединение на Nginx, который решает, какой виртуальный сервер также отправить соединение, я думаю, в этом случае может быть HAProxy или что-то в этом роде аналогичный.

В итоге

1) Если бы у меня не было отдельных файлов конфигурации, перекрывающих различные поддомены, исходный ответ на исходный вопрос работал бы отлично.

2) Мне нужно фактически объединить поддомены в главный домен, где будет указан сертификат, но при этом сохраняя файлы отдельно.

3) Мне нужно, чтобы SSL работал прозрачно из * ... подстановочного SSL-сертификата, и я не хочу создавать новый запрос SSL для каждого отдельного созданного поддомена.

Любые идеи о том, как я могу это сделать, предпочтительно на основе исходного вопроса, были бы очень признательны.

Обновление (22.08.2018)

Таким образом, используя совет, данный Drifter в комментариях, я в конце концов придумал следующее для моих «виртуальных серверов с подстановочными знаками», IE: серверы, которые будут отвечать на все в домене, если для него нет более конкретной конфигурации поддомена.

server {

  listen 80;

  server_name
    example.com
    www.example.com
    *.example.com;

  location /.well-known {
    alias /var/www/html/letsencrypt;
  }

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://internal-default-web-server-for-wildcard;
    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_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;

    access_log /var/log/nginx/example.access.log;
    error_log /var/log/nginx/example.error.log error;

  }
}

server {

  listen 443 ssl;

  server_name
    example.com
    www.example.com
    *.example.com;

  include "example-cert.inc";

  ssl_stapling on;
  ssl_stapling_verify on;

  # maintain the .well-known directory alias for renewals
  location /.well-known {
    alias /var/www/html/letsencrypt;
  }

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://internal-default-web-server-for-wildcard;
    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_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;

    access_log /var/log/nginx/example.sslaccess.log;
    error_log /var/log/nginx/example.sslerror.log error;
  }
}

Как видите, серверный блок теперь дополняется серверным блоком, активирующим HTTPS, и вместо имени сертификатов сервера в файле есть

include "example-cert.inc"

В файле "example-cert" следующее

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Это заставляет Nginx загружать, которые включают в себя эти имена сертификатов, когда он загружает конфигурацию VS, обрабатывающую эти домены с подстановочными знаками.

Для всех других конфигураций для поддоменов, которые имеют свои собственные пункты назначения, Iv'e проделал то же самое, главное отличие в том, что маршрут ". Well-known" не включен, а пункты назначения прокси / сервера и имена файлов журнала разные.

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

Это фактически отвечает на мой вопрос, теперь мне просто нужно выяснить, как автоматизировать обновление сертификата с помощью Let's encrypt. Поскольку это шаблонный сертификат, который я использую, мне не разрешено использовать какой-либо метод проверки, кроме "DNS-01", и это можно сделать только вручную, если только вы не используете службу DNS, предоставляемую одним из поддерживаемых облачных провайдеров. плагином certbot.

Я нет, мой DNS - это просто стандартный DNS, поэтому для каждого обновления мне нужно регенерировать новую запись TXT и изменять свои записи DNS, прежде чем обновление будет работать. Я МОГУ полностью автоматизировать его, используя метод "webroot", но webroot не позволяет запрашивать сертификаты с подстановочными знаками, только фиксированный список из нескольких доменов.

Скиталец, если ты напишешь свои комментарии в качестве ответа, я дам тебе +10

nginxssllets-encryptproxypasswildcard