Как в nginx подключать ssl если файл сертификата присутствует?

Question

[BloodVIRUS]

Здравствуйте. У меня на сервер привязаны все домены 3 уровня. Т.е если перейти dev1.site.ru или alex.site.ru все будет вести ко мне на сервер. Nginx конфиг для этого простой:

server {
listen 80;
server_name ~^(www\.)?(?.+)$;
root /var/www/users/$domain;

}

Данная конструкция отлично работает. Но появилась необходимость проверять папку с ssl сертификатами, и если для домена там есть сертификаты - подключать их. Для тестов использовал бесплатный сертификат letsencrypt.

Идея такова, делаю два таких конфига, один на 80 порт, второй на 443 ssl
во втором подключаю сертификат, а в первом проверяю есть ли файл сертификата. Если есть - редирект.

if (-f /var/ssl/$domain/privkey.pem) {
rewrite ^/(.*)$ https://$domain/$1 permanent;
}

Отрабатывает все на ура. Но..

ssl_certificate /etc/letsencrypt/live/$domain/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/$domain/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

Браузер говорит мне:
Этот сайт не может обеспечить безопасное соединение Сайт dev1.site.ru отправил недействительный ответ.
ERR_SSL_PROTOCOL_ERROR

Но если я подключаю сертификат по прямому пути, все работает:

ssl_certificate /etc/letsencrypt/live/dev1.site.ru/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/dev1.site.ru/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

Магия какая то..

Answer 1

[Александр Черных]

непонимаю, зачем такие заморочки
не лучше ли сделать себе wildcard от ЛЕ и не парится?

Answer 2

[ТыжСисАдмин]

LetsEncrypt умеет в Wildcard

Браузер говорит мне:

Ну так и смотрите что за сертификат вам отдаёт сервер, так-же про логи не забываем.
В браузере ну или curl в помощь
curl -vvI https://site.ru

* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* 	subject: CN=*.sysalex.com <-- раз
* 	start date: May 27 05:07:30 2019 GMT
* 	expire date: Aug 25 05:07:30 2019 GMT
* 	common name: *.sysalex.com <-- два
* 	issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US

Comments

[BloodVIRUS]

Спасибо! Пойду гуглить что ему не нравится.

* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS alert, Server hello (2):
* error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
* stopped the pause stream!
* Closing connection 0
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

[ТыжСисАдмин]

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

[BloodVIRUS]

ТыжСисАдмин, Да, пользователи сами будут загружать сертификаты. Если б не это, я конечно не парился бы.

[ТыжСисАдмин]

BloodVIRUS,
На сколько помню, ssl_certificate и т.п. обрабатывается только во время загрузки и такой фингт ушами не проходит, в результате строка

ssl_certificate /etc/letsencrypt/live/$domain/fullchain.pem; # managed by Certbot

станет у вас

ssl_certificate /etc/letsencrypt/live//fullchain.pem; # managed by Certbot

но это должно быть видно в логах.

Вообще для "хостинга" такие конфиги это решение так себе.
Разделяйте конфиги юзеров и сразу проблемы не будет и гибкость настройки под "хочушки" юзера появятся.

Answer 3

[Виктор Таран]

server_name ~^(www\.)?(?.+)$; - это что за самодеятельность ? это ваще зачем?
Во первых вы нарушаете философию самого nginx - сам создатель nginx не один раз говорил что !!!
НАМЕРЕННО не вводил нормальное использование переменных в файлах конфигурации, поскольку куда как правельней 10 раз скопировать кусок файла нежеле забивать ее переменной, не обломится админ скопировать две строчки .
И я вам могу сказать что он прав.
2. Вы при генерации сайта все-равно какими-то средствами это делаете, ВЫ ЖЕ НЕ ПИШИТЕ ВСЕ РУКАМИ, ПРИ НАЛИЧИЕ МИЛЛИОНОВ ВЕБ ИНТЕРФЕЙСОВ?
3. Если вам прям так не имется с проблеммой ввв, сделайте банально линку на папку c www,и не нужно изголяться.
4. Работа с сертификатом и без него принципиально отличается, КАК МИНИМУМ тем что при обращению по http вначале получается имя домена а потом работа.
ПО HTTPS вначале работают ключи а только после этого в этом канале можно получить хоть байт информации, включая имя сайта. так что не выдумывайте велосипед.
Генерируйте конфиги для каждого сайта, а я бы еще рекомендовал отдельно для http и https в таком случае ошибка в одном из них не приводит к падению второго интерфейса.
ну а дефолтный конфин нужно назвать 000-default... - где 000 говорит о том что он будет первым при выдачи ( посколкуь как я вам расписывал в пункте4 если сайт не имеет https о этом он физически может узнать только получив ключи, как следствие веб сервер возьмет " ближайшие" а сортировка у него именно по буквам ;) 00 просто первые ;)
Ну и банальное удобство, разные сайты требуют доп изменений в конфигах.
А следовательно куда в вашей модели их писать?

Comments

[BloodVIRUS]

Я это все затеял так как пользователи сами будут подключать к своим доменам сертификаты.
Для всех доменов единый конфиг файл, а значит при создании нового домена не нужно создавать конфиг и перезагружать nginx. Т.е все работает так сказать из коробки. Создали в папке /var/www/site200.ru, в него можно грузить файлы, и все будет работать.
Сколько по итогу будет сайтов представить даже не могу. Может 10, а может за пару тройку лет там наберется 20-40 тысяч сайтов. И все с идентичным nginx конфигом. Так зачем тогда плодить 40 000 одинаковых файлов? Ну и работа ведется через php, а значит нужно как-то еще вебсервер перезагружать. Просто так конфиг файл создать не получится.
Для ssl та же проблема. Если пользователь захочет подключить https, нужно конфиг файл отредактировать, и перезагрузить веб сервер.

Исходя из всего выше написанного, был придуман универсальный конфиг nginx под все сайты, что позволит не создавать огромное количество дублирующихся конфигов.
А вот с ssl затык вышел...

[Виктор Таран]

1. ну и че плодятся и плодятся, и да каждый пользователь может внести в nginx свои изменения, а маски никогда не работали быстрее жестко заданных переменных
2. nginx reload не рестартует демона а просто применяет
3. никто не мешает вам так же в каждом файле применять общие ключи а если сертификат подгружает клиент то заменять пути для симлирков на пути к сертификату клиента.
4. если много сайтов то почему не взял веб морду готовую? и не допилил ее ?
5. исходя из опыта ( лет 8 назад я какраз и делал как вы) но в реалиях жизни вначале пришлось делать конфиги для сайтов клиентов потом вовсе отказываться от дефолтного конфига, а потом и вовсе его запрещать явно заводя в 444 ответ.

Answer 4

[Константин]

server {
  listen 80;
  server_name ~^(www\.)?(?<domain>.+)$;
  root /var/www/users/$domain;
}

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