Re: 400 Bad Request The plain HTTP request was sent to HTTPS port
Maxim Dounin Wrote:
---
> У вас явно некорректная конфигурация, использующая "ssl on;".
> Основное правило при использовании "ssl on;" очень простое: SSL и
> не-SSL listen-сокеты должны использоваться строго в разных блоках
> server{}. Любые попытки совместить - чреваты. Ибо если вдруг у
> вас в сервере по умолчанию для не-SSL listen-сокета окажется "ssl
> on;", то сокет станет SSL-сокетом.
>
> Скорее всего "раньше всегда работало" потому, что в сервера по
> умолчанию для не-SSL listen-сокетов стояли корректные, а сейчас
> из-за каких-то минимальных изменений конфига (скажем, кто-то
> добавил блок server с несколькими listen-сокетами и "ssl on;") -
> ситуация поменялась.
>
> Если по каким-то причинам хочется исправить конфигурацию, не
> переходя на "listen ... ssl" - показывайте полную конфигурацию,
> поможем найти источник проблем.
>
> Но проще и правильнее сразу переделать всё на использование
> "listen ... ssl", благо это тривиально: "ssl on;" из конфига
> убрать, а у listen-сокетов, которые должны использовать SSL,
> добавить флаг "ssl" (как минимум один раз, например, в сервере по
> умолчанию, но можно во всех директивах listen).
>
Вот конфиг, я его постил в самом начале, как видите разнесено по разным
блокам server{}
server {
listen 80;
server_name .local.map;
rewrite ^(.*) https://$host$1 permanent;
#return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2 default_server;
ssl_certificate /etc/letsencrypt/live/local.map/fullchain.pem;
ssl_trusted_certificate /etc/letsencrypt/live/local.map/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/local.map/privkey.pem;
server_name .local.map;
set $root /var/www/msk/data/local.map;
root $root;
access_log off; .
есть второй сайт, у которого конфиг такой-же, только пути разные плюс убрал
на другой айпи сокет и убрал default_server после чего заработало.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,294635,294657#msg-294657
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: certbot
Использую команду certbot certonly и конфиги nginx не меняются, работает хорошо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294635,294658#msg-294658 ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: certbot
ср, 6 июл. 2022 г. в 02:53, Maxim Dounin : > Hello! > > On Tue, Jul 05, 2022 at 10:09:33PM +0300, Gena Makhomed wrote: > > > On 05.07.2022 15:55, Maxim Dounin wrote: > > > > > Отмечу, что если сертификаты обновлялись с помощью Certbot, то он > > > при обновлении модифицирует конфиги nginx'а (а потом возвращает > > > всё "как было"). Это может заканчиваться, скажем так, неожиданно. > > > Лично я рекомендую для выпуска сертификатов использовать > > > Dehydrated и необходимые дополнения в конфиг прописывать руками. > > > > certbot так криво себя ведет только в дефолтовой конфигурации. > > Этого достаточно, чтобы им не пользоваться. И уж тем более не > рекомендовать другим, ибо они с вероятностью, близкой к 100%, > будут использовать его именно в конфигурации по умолчанию. > > Тем более, что есть Dehydrated, который подобным идиотизмом по > умолчанию не страдает, да и представляет из себя вполне читаемый > bash-скрипт без дополнительных зависимостей. > там весьма запутанная ситуация с "официальным" клиентом LetsEncrypt. с одной стороны, есть ACME и к нему примерно миллион реализаций, среди которых и certbot. с другой стороны http://github.com/letsencrypt/letsencrypt --> https://github.com/certbot/certbot dehydrated и acme.sh - отличные примеры программирования на shell. без шуток. > > -- > Maxim Dounin > http://mdounin.ru/ > ___ > nginx-ru mailing list -- nginx-ru@nginx.org > To unsubscribe send an email to nginx-ru-le...@nginx.org > ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: certbot
Hello! On Wed, Jul 06, 2022 at 09:00:05AM +0300, Gena Makhomed wrote: > On 06.07.2022 0:52, Maxim Dounin wrote: > > >>> Отмечу, что если сертификаты обновлялись с помощью Certbot, то он > >>> при обновлении модифицирует конфиги nginx'а (а потом возвращает > >>> всё "как было"). Это может заканчиваться, скажем так, неожиданно. > >>> Лично я рекомендую для выпуска сертификатов использовать > >>> Dehydrated и необходимые дополнения в конфиг прописывать руками. > > >> certbot так криво себя ведет только в дефолтовой конфигурации. > > > Этого достаточно, чтобы им не пользоваться. И уж тем более не > > рекомендовать другим, ибо они с вероятностью, близкой к 100%, > > будут использовать его именно в конфигурации по умолчанию. > > Если быть уж совсем точным, то при установке пакета certbot > пакет python3-certbot-nginx не устанавливается. python3-certbot-nginx - > это Plugin for certbot that allows for automatic configuration of nginx. > > Поэтому при выполнении команды certbot run -d example.com он выдает ошибку: > > Certbot doesn't know how to automatically configure the web server on > this system. However, it can still get a certificate for you. Please run > "certbot certonly" to do so. You'll need to manually configure your web > server to use the resulting certificate. > > Поэтому единственным рабочим вариантом получения сертификата > для nginx является только команда certbot certonly -d example.com > которая никаких автоматических изменений в конфиги nginx не вносит. > > certbot - это очень хорошо продуманный и качественно сделанный софт. Я наблюдал Certbot с Apache, где все приседания с изменением конфигурации на работающем сервере используются по умолчанию. Точнее, помогал разобраться, почему оно не работает. Мне хватило, чтобы не считать Certbot "хорошо продуманным и качественно сделанным". > > Тем более, что есть Dehydrated, который подобным идиотизмом по > > умолчанию не страдает, да и представляет из себя вполне читаемый > > bash-скрипт без дополнительных зависимостей. > > этот bash-скрипт имеет серьезные проблемы даже с парсингом json: > > https://www.opennet.ru/opennews/art.shtml?num=53279 > > тем более, что разработчик dehydrated - это всего лишь студент: > > https://www.opennet.ru/opennews/art.shtml?num=52294 Каждый выбирает приоритеты для себя. Кому-то не нравится парсинг json'а, возвращаемого конкретным сервисом, с помощью регулярных выражений, чтобы не тащить зависимости, а кому-то - переписывание конфига работающего сервера (с помощью тех же регулярных выражений, если продраться через зависимости) с непредсказуемыми последствиями. Я могу рекомендовать Dehydrated, он сделан хорошо и просто работает. И не могу рекомендовать Certbot, там проблема дизайна: конфиг сервера нельзя менять, не понимая всех аспектов работы этого конфига (и тем более нельзя менять в фоне и не говоря об этом пользователю), а авторы Certbot'а этого явного не понимают. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: long deprecated directives
Hello! On Wed, Jul 06, 2022 at 08:15:43AM +0300, Gena Makhomed wrote: > On 06.07.2022 4:52, Maxim Dounin wrote: > > > Возможность задавать конфигурацию с помощью "listen ... ssl" > > появилась в nginx 0.7.14. > > > У вас явно некорректная конфигурация, использующая "ssl on;". > > Кстати, директива "ssl on;" находится в состоянии deprecated > начиная с версии 1.15.0, вышедшей 05 Jun 2018, более 4 лет тому назад. > > Может быть имеет смысл превратить warning в error, удалив > эту директиву из nginx и оставив только возможность "listen ... ssl" ? > > Тогда у пользователей будет меньше возможностей для создания > конфигураций, которые будут приводить к ошибкам такого вида: > 400 Bad Request The plain HTTP request was sent to HTTPS port > > Аналогичный вопрос и по остальным deprecated директивам: > > proxy_downstream_buffer > proxy_upstream_buffer > http2_idle_timeout > http2_max_field_size > http2_max_header_size > http2_max_requests > http2_recv_timeout > > - может быть имеет смысл их удалить из nginx? Удалить и заменить warning на фатальную ошибку - это два разных действия. Удаление директив позволяет избавиться от лишнего кода и больше об этом не думать. Обычно это делается, когда про существование директив забывают практически все, и/или наличие соответствующего кода начинает раздражать/мешать. Для упомянутых директив такой момент, кажется, ещё не наступил. Заменить warning на фатальную ошибку - как показала практика, не имеет смысла примерно никогда. Пока директива реально встречается в конфигах - warning даёт возможность переписать их в удобном администратору темпе, и соответственно предпочтительнее. А когда встречаться перестаёт - наступает момент для удаления директивы. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: 400 Bad Request The plain HTTP request was sent to HTTPS port
Hello!
On Wed, Jul 06, 2022 at 04:44:41AM -0400, milov wrote:
> Maxim Dounin Wrote:
> ---
> > У вас явно некорректная конфигурация, использующая "ssl on;".
> > Основное правило при использовании "ssl on;" очень простое: SSL и
> > не-SSL listen-сокеты должны использоваться строго в разных блоках
> > server{}. Любые попытки совместить - чреваты. Ибо если вдруг у
> > вас в сервере по умолчанию для не-SSL listen-сокета окажется "ssl
> > on;", то сокет станет SSL-сокетом.
> >
> > Скорее всего "раньше всегда работало" потому, что в сервера по
> > умолчанию для не-SSL listen-сокетов стояли корректные, а сейчас
> > из-за каких-то минимальных изменений конфига (скажем, кто-то
> > добавил блок server с несколькими listen-сокетами и "ssl on;") -
> > ситуация поменялась.
> >
> > Если по каким-то причинам хочется исправить конфигурацию, не
> > переходя на "listen ... ssl" - показывайте полную конфигурацию,
> > поможем найти источник проблем.
> >
> > Но проще и правильнее сразу переделать всё на использование
> > "listen ... ssl", благо это тривиально: "ssl on;" из конфига
> > убрать, а у listen-сокетов, которые должны использовать SSL,
> > добавить флаг "ssl" (как минимум один раз, например, в сервере по
> > умолчанию, но можно во всех директивах listen).
> >
>
> Вот конфиг, я его постил в самом начале, как видите разнесено по разным
> блокам server{}
>
> server {
> listen 80;
> server_name .local.map;
> rewrite ^(.*) https://$host$1 permanent;
> #return 301 https://$host$request_uri;
> }
>
> server {
> listen 443 ssl http2 default_server;
>
> ssl_certificate /etc/letsencrypt/live/local.map/fullchain.pem;
> ssl_trusted_certificate /etc/letsencrypt/live/local.map/fullchain.pem;
> ssl_certificate_key /etc/letsencrypt/live/local.map/privkey.pem;
>
> server_name .local.map;
> set $root /var/www/msk/data/local.map;
> root $root;
> access_log off; .
>
> есть второй сайт, у которого конфиг такой-же, только пути разные плюс убрал
> на другой айпи сокет и убрал default_server после чего заработало.
Покажите полную конфигурацию - вывод "nginx -T". Как уже сказано
выше, судя по симптомам у вас в конфиге где-то "ssl on;", и от
этого проблемы.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: certbot
On 06.07.2022 22:00, Maxim Dounin wrote: Отмечу, что если сертификаты обновлялись с помощью Certbot, то он при обновлении модифицирует конфиги nginx'а (а потом возвращает всё "как было"). Это может заканчиваться, скажем так, неожиданно. Лично я рекомендую для выпуска сертификатов использовать Dehydrated и необходимые дополнения в конфиг прописывать руками. certbot так криво себя ведет только в дефолтовой конфигурации. Этого достаточно, чтобы им не пользоваться. И уж тем более не рекомендовать другим, ибо они с вероятностью, близкой к 100%, будут использовать его именно в конфигурации по умолчанию. Максим, я ошибся. В дефолтовой конфигурации он себя ведет несколько иначе. При установке пакета certbot и в RHEL-дистрибутивах и в Ubuntu плагины для модификации конфигов nginx и apache не устанавливаются. Если кто-то хочет их использовать - они устанавливаются отдельно, с помощью пакетов python3-certbot-nginx и python3-certbot-apache И даже в том случае, если эти плагины установлены - они по умолчанию, насколько я понимаю, не активируются - необходимо в командной строке задать соответствующий параметр активации плагина: --nginx или --apache Cлучайно испортить с certbot конфиг nginx или apache не получится - каждый пользователь делает это вполне осознанно и целенаправленно, вручную устанавливая на сервер и активируя соответствующий плагин. Я могу рекомендовать Dehydrated, он сделан хорошо и просто работает. И не могу рекомендовать Certbot, там проблема дизайна: конфиг сервера нельзя менять, не понимая всех аспектов работы этого конфига (и тем более нельзя менять в фоне и не говоря об этом пользователю), а авторы Certbot'а этого явного не понимают. Проблема дизайна, о которой Вы говорите, есть только у двух плагинов: nginx и apache. Остальные плагины (standalone, manual, webroot, dns-*) работают очень даже хорошо, и к ним ведь у Вас нет никаких претензий? -- Best regards, Gena ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: certbot
Hello! On Wed, Jul 06, 2022 at 11:38:52PM +0300, Gena Makhomed wrote: > On 06.07.2022 22:00, Maxim Dounin wrote: > > > Отмечу, что если сертификаты обновлялись с помощью Certbot, то он > > при обновлении модифицирует конфиги nginx'а (а потом возвращает > > всё "как было"). Это может заканчиваться, скажем так, неожиданно. > > Лично я рекомендую для выпуска сертификатов использовать > > Dehydrated и необходимые дополнения в конфиг прописывать руками. > >> > certbot так криво себя ведет только в дефолтовой конфигурации. > >> > >>> Этого достаточно, чтобы им не пользоваться. И уж тем более не > >>> рекомендовать другим, ибо они с вероятностью, близкой к 100%, > >>> будут использовать его именно в конфигурации по умолчанию. > > Максим, я ошибся. > В дефолтовой конфигурации он себя ведет несколько иначе. > > При установке пакета certbot и в RHEL-дистрибутивах и в Ubuntu > плагины для модификации конфигов nginx и apache не устанавливаются. > > Если кто-то хочет их использовать - они устанавливаются отдельно, > с помощью пакетов python3-certbot-nginx и python3-certbot-apache > > И даже в том случае, если эти плагины установлены - они по умолчанию, > насколько я понимаю, не активируются - необходимо в командной строке > задать соответствующий параметр активации плагина: --nginx или --apache > > Cлучайно испортить с certbot конфиг nginx или apache не получится - > каждый пользователь делает это вполне осознанно и целенаправленно, > вручную устанавливая на сервер и активируя соответствующий плагин. > > > Я могу рекомендовать Dehydrated, он сделан хорошо и просто > > работает. И не могу рекомендовать Certbot, там проблема дизайна: > > конфиг сервера нельзя менять, не понимая всех аспектов работы > > этого конфига (и тем более нельзя менять в фоне и не говоря об > > этом пользователю), а авторы Certbot'а этого явного не понимают. > > Проблема дизайна, о которой Вы говорите, есть только у двух плагинов: > nginx и apache. Остальные плагины (standalone, manual, webroot, dns-*) > работают очень даже хорошо, и к ним ведь у Вас нет никаких претензий? Документация на сайте предлагает "certbot --apache" в качестве основного варианта использования (например, тут: https://certbot.eff.org/instructions?ws=apache&os=ubuntufocal), и дальше уже не важно, какие ещё варианты есть: заметный процент пользователей будет делать именно то, что сказали. И получать предсказуемый (точнее, непредсказуемый) результат. И нет, наличие проблемы "авторы считают возможным менять конфиги" в одном из вариантов использования - не означает, что в других вариантах использования проблем нет. Наличие такой проблемы означает, что авторы не понимают проблему, и что там ещё и где разложено или будет разложено в будущем - неизвестно. И лично я предпочитаю пользоваться тем, что работает, и рекомендовать его же. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
