Где определить SSL конфигурацию для нескольких блоков серверов nginx

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение

Вопрос или проблема

Я хочу перенаправить http на https и naked на www.

Итак, моя конфигурация:

# http naked -> https www
# http www -> https www
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://www.example.com$request-uri;
}


# https naked -> https www
server {
  listen 443 ssl http2;
  server_name example.com;
  #ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem     # <--- ??
  #ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem   # <--- ??
  return 301 https://www.$host$request-uri;
}


# https www
server {
  listen 443 ssl http2;
  server_name www.example.com;
  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem
}

Нужно ли мне повторять строки SSL, отмеченные как ?? в среднем блоке?

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

Таким образом, в случае Nginx, если у вас есть listen ... ssl, вы обязательно должны добавить также строки ssl_certificate.

Вы можете использовать алиасы, если ваша пара ключ/сертификат в /etc/letsencrypt/live/example.com действительна как для example.com, так и для www.example.com. Это позволит вам обслуживать одно и то же содержимое для обоих имен без перенаправления, используя единственный SSL виртуальный хост в Nginx: server_name example.com www.example.com;.

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

Ответ или решение

Определение параметров конфигурации SSL для нескольких серверных блоков Nginx — это важный этап в обеспечении безопасности и корректной работы веб-сервера. Рассмотрим шаг за шагом, как и где следует указать настройки SSL в случае, когда требуется перенаправлять HTTP-запросы на HTTPS и используемые домены с «голой» версией на «www»-версию.

Теория

Nginx требует наличия SSL-сертификата и ключа для каждого серверного блока, который принимает HTTPS-запросы. Эти параметры обеспечивают корректную установку TLS-сессии между клиентом и сервером. Без этого невозможно гарантировать защиту данных, передаваемых по сети, а также защиту от атак «человек-посередине» (MitM). TLS-сессия обрабатывается до выполнения любого перенаправления, поскольку её наличие предполагает первоначальное установление защищённого соединения. Таким образом, даже если серверный блок исключительно выполняет перенаправление, наличие сертификата и ключа обязательно.

Пример

Рассмотрим ваш конфигурационный файл:

# http naked -> https www
# http www -> https www
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://www.example.com$request_uri;
}

# https naked -> https www
server {
  listen 443 ssl http2;
  server_name example.com;
  #ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem     # <--- ??
  #ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem   # <--- ??
  return 301 https://www.$host$request_uri;
}

# https www
server {
  listen 443 ssl http2;
  server_name www.example.com;
  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

В данном примере у вас имеются три серверных блока:

Блок для HTTP-запросов на порту 80, перенаправляющий все запросы на HTTPS с добавлением «www».
Блок для HTTPS-запросов без «www», перенаправляющий их на адрес с «www».
Блок для HTTPS-запросов с «www», который обрабатывает конечные запросы.

В блоке для HTTPS-запросов без «www» (server_name example.com;), который выполняет только перенаправление, также должны быть указаны ssl_certificate и ssl_certificate_key, поскольку:

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

Применение

Обновим конфигурацию так, чтобы включить необходимые параметры SSL во втором серверном блоке:

# https naked -> https www
server {
  listen 443 ssl http2;
  server_name example.com;
  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
  return 301 https://www.$host$request_uri;
}

Таким образом, каждый серверный блок, обрабатывающий HTTPS-запросы, содержит необходимые атрибуты ssl_certificate и ssl_certificate_key. Это позволяет Nginx корректно устанавливать безопасные соединения и выполнять перенаправления.

В заключение, важно отметить возможность использования одного и того же ключа и сертификата для нескольких имен серверов (server_name), если сертификат поддерживает эти имена (например, с использованием Wildcard-сертификатов или сертификатов с альтернативными именами субъекта — SAN). Это упрощает администрирование и снижает количество сертификатов, которые вам необходимо будет управлять.

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