Comments 15
Текст длинноват, чтобы переделывать что-то с уже работающего certbot...
Проблема непродленных сертификатов должна мониторингом купироваться, любое решение может дать сбой.
люди забыли принцип "утилита должна выполнять только одну задачу, но делать это хорошо"
алсо, на мой взгляд в статье не хватает ответа на вопрос: а в чём преимущество? способов автоматически получать/обновлять сертификаты нынче много, от банального bash скрипта на пару строчек и всем известного certbot до вот таких вот решений встроенных в приложение для которого сертификат нужен, и говоря о своём решении стоит сказать чем оно лучше.
В конце статьи есть ответ на вопрос чем лучше. Самое банальное - не нужно поддерживать список доменов в двух разных местах. Из небанального, что никогда в принципе не сможет скрипт на bash делать, так это выполнять ALPN-челендж, поддержку которого уже в ближайших версиях добавим.
люди забыли принцип "утилита должна выполнять только одну задачу, но делать это хорошо"
Сколько я работаю в индустрии, то постоянно сталкиваюсь, что реальные пользователи чаще всего хотят обратного, а именно, чтобы всё работало из коробки и желательно тратить на это как можно меньше сил. И в целом, в этом нет ничего плохого... есть в индустрии другие задачи, чем как сопряжение отдельных разрозненных компонентов между собой каждый раз.
Так для чего повторять когда-то десятилетия назад выдвинутую догму, когда задачи и масштабы были совсем другие, снова и снова? Тем более, что тут возникает коллизия в том, а что есть утилита в части веб-сервера... должен ли он хорошо обрабатывать HTTPS трафик? Современному веб-серверу без этого никуда, а если да, то входит ли в эту задачу работа с сертификатами? Ведь если он не сможет обновлять сертификаты, то хорошо обрабатывать HTTPS трафик тоже не получится. Какая-то неполноценная утилита тогда выходит, не справляющаяся со свой задачей.
не сочтите за троллинг, но:
поддержку которого уже в ближайших версиях добавим
рановато заявлять о плюсе который ещё не в проде..
реальные пользователи чаще всего хотят обратного
ну nginx/angie это всё же не для пользователей а для тех кто делает этим пользователям сервисы.
пользователям свойственно ошибаться, если вы утверждаете что так лучше для пользователя то снова вопрос: "чем?".
чтобы всё работало из коробки и желательно тратить на это как можно меньше сил
не вижу почему бы из коробки у меня бы не заработал lego/certbot/acme.sh/etc.
меньше сил это когда ты добавляешь в свой ansible/puppet/etc проект ещё один хост с его варсами и запускаешь сто раз проверенный плейбук и уже и не помнишь какой там под капотом юзается acme.. а когда нужно копать новый инструмент это уже исследование, да оно может быть полезным и профитным, но чтобы это выяснить для начала надо чтобы появился на то интерес и причина.
Так для чего повторять когда-то десятилетия назад выдвинутую догму
потому что она провереная временем, эта догма строится на базе того что человек не всесилен и ему свойственно допускать ошибки, и на том как уменьшить возможное кол-во ошибок не более.
Ведь если он не сможет обновлять сертификаты, то хорошо обрабатывать HTTPS трафик тоже не получится. Какая-то неполноценная утилита тогда выходит, не справляющаяся со свой задачей.
ну не надо смешивать две задачи в одну всё же использовать сертификат и обслуживать его это независимые задачи. вообще если уж на то пошло хорошим тоном является выдавать на сертификаты такие права чтобы приложение могло их только читать, но не писать, а с вашим решением так не получится..
рановато заявлять о плюсе который ещё не в проде..
Тут я скорее о том, что в принципе технически нормально не реализовать в случае отдельной утилиты, т.к. требует вмешательства в сам процесс TLS-хендшейка.
ну nginx/angie это всё же не для пользователей а для тех кто делает этим пользователям сервисы.
Мы пользователями привыкли называть тех, кто пользуется нашим ПО, т.е. устанавливает и занимается его настройкой. =)
пользователям свойственно ошибаться, если вы утверждаете что так лучше для пользователя то снова вопрос: "чем?"
Они по этой причине уходят на кадди, и не ощущают, что ошиблись. Опять же, кому не нужно и кто считает это ошибкой - может просто не пользоваться данным модулем и вообще его не собирать. Тем не менее, отставание от конкурентов в этом плане приводит только к потере пользователей. Кажется, это весомый аргумент, чтобы не отставать, если хочешь разрабатывать действительно популярное решение, а не что-то сугубо нишевое.
не вижу почему бы из коробки у меня бы не заработал lego/certbot/acme.sh/etc.
меньше сил это когда ты добавляешь в свой ansible/puppet/etc проект ещё один хост с его варсами и запускаешь сто раз проверенный плейбук
Значит у вас уже есть какой-то плейбук, вы в этом однажды разобрались и его написали. Это не из коробки. Это не поставил apt install angie, а дальше добавил две директивы и всё работает, причем добавил в парадигме конфигурационного файла, который и так нужно изучать, чтобы пользоваться nginx/Angie.
потому что она провереная временем, эта догма строится на базе того что человек не всесилен и ему свойственно допускать ошибки, и на том как уменьшить возможное кол-во ошибок не более.
Да, и ошибки он допускает при настройке двух разных инструментов. Тратит время на изучение дополнительного инструмента, написание плейбука и пр. пр. Зачем этим заниматься, если можно воспользоваться встроенным решением, которое уже раз разработали те, кто разобрались в вопросе глубже, чем просто настройка Certbot и реализовали это автоматически.
Тут нужно понимать, что в статье рассмотрен довольно комплексный и сложный случай настройки. В простейшем виде вся настройка заключается в добавлении пары директив в конфиг из документации:
acme_client example https://acme-v02.api.letsencrypt.org/directory;
server {
acme example;
...
При этом обновление сертификатов происходит без перезагрузки процессов веб-сервера. Для тех, у кого доменов и сертификатов очень много, необходимость чаще перезапускать процессы - становится отдельной проблемой.
Вот вы спорите, а мы регулярно получаем благодарность от пользователей, которые пишут, что поддержка ACME в Angie - это стало для них одним из ключевых факторов, чтобы перейти с nginx и они очень довольны, благодарят за эту функциональность чаще, чем за многую другую.
Это же не вот вдруг нам заняться было нечем. Это был нескончаемый поток просьб встроить поддержку ACME в веб-сервер, т.к. по той или иной причине пользователи не хотят возиться с отдельным Certbot/Acme.sh и др., предпочитая вместо этого даже сменить веб-сервер на такой, где поддержка ACME уже встроена. Можно конечно сидеть и заявлять, что такие пользователи ошибаются, не должен этим заниматься веб-сервер, но это странный способ кому-то что-то доказать, весьма не конструктивный в плане развития и популяризации проекта.
Выглядит так, как будто это должен быть доклад с презентацией. А теническая часть отдельно. За большим количеством контента сложно поймать основную тему. Но то, что вы сделали наконец авто сертификаты, это круто. Я в свое время из-за этого на Caddy перетащил мелкие проекты, чтобы скрипты не плодить.
Так чем простейший пример в документации плох: https://angie.software/angie/docs/configuration/acme/#http - зачем ждать, пока где-то в каком-то блоге появится какая-то заметка, цитирующая документацию? =)
У меня вот есть такая задача (которая как-то с трудом вкорячивается в концепцию unix-way с одной функцией на утилиту): Представим сервис для хранения статических файлов (типа хабрастораджа). Клиенты регаются, настраивают DNS запись и клиент cocacola.com получает (на нашем сервере) виртуальный хост static.cocacola.com. Потом регается intel и у нас сразу же (на том же сервере, с тем же IP) появляется static.intel.com.
Традиционный путь - это держать где-то список доменов, и иногда перестраивать конфиги вебсервера из списк и запрашивать сертификаты. Но мне кажеся, это каким-то сложным, кривым путем. Вроде бы Caddy умеет так делать. Про Angie не знаю, я вот о нем только услышал.
Еще, почему-то веб-сервера не умеют сами подбирать сертификаты. Мне кажется немного тупостью, что нужно для каждого виртхоста прописывать, где ему искать файлы с сертификатом и ключам - лишние хлопоты, громоздкий конфиг, лишние ошибки. Какой-то анахронизм, рудимент с тех времен, когда сертификат покупался за $100/год и это было редкостью. Гораздо проще было бы просто один раз в конфиге указать пути, где у нас лежат сертификаты, и веб-сервер по запросу к example.com сам сможет найти свежий сертификат для example.com.
Традиционный путь - это держать где-то список доменов, и иногда перестраивать конфиги вебсервера из списк и запрашивать сертификаты. Но мне кажеся, это каким-то сложным, кривым путем. Вроде бы Caddy умеет так делать. Про Angie не знаю, я вот о нем только услышал.
Не очень понял. Вы хотите чтобы, условно, папка с сертификатами была динамическим конфигом для сервера? Так себе идея, ибо кроме сертификатов там много ещё чего.
Так что список доменов всё равно надо где-то держать. Меня бы устроило если бы nginx просто умел динамически перечитывать сертификаты по команде.
Но он только умеет тушить старые процессы и запускать новые. Что приводит иногда к OOM если часто это делать т.к. старые ещё не закрылись (держим их 10 минут например чтобы клиенты успели всё доделать), а новых наоткрывали кучу уже.
Традиционный путь - это держать где-то список доменов, и иногда перестраивать конфиги вебсервера из списк и запрашивать сертификаты. Но мне кажеся, это каким-то сложным, кривым путем. Вроде бы Caddy умеет так делать. Про Angie не знаю, я вот о нем только услышал.
Вам в любом случае придется хранить список доменов и проверять по нему, прежде чем выпустить сертификат. Попробую объяснить почему.
Представим, что такого списка нигде нет. В SNI, как и в заголовке Host, клиент может указать вообще всё, что угодно, абсолютно любой домен. Таким образом злоумышленник сможет вывести ваш сервер из строя, начав запрашивать произвольные домены. Попытка выпустить сертификат на такой произвольный домен не увенчается успехом, однако вы попадете в черный список у ACME-сервера и не сможете получить сертификат для реального нужного домена.
Ок, вы скажите, что ACME клиент должен перед тем, как идти получать сертификат на новый домен - сам попытаться его отрезолвить. А я отвечу, что ничего не мешает злоумышленнику зарегистрировать какой-то домен и прописать для него IP-адрес вашего сервера. И ваш сервер даже получит на него сертификат, но при определенном количестве таких запросов у того же Let's Encrypt сработает лимит и получение новых сертификатов на какое-то время будет далее невозможно, что опять приведет к DoS.
Т.е. так или иначе, перед тем, как идти получать сертификат на какой-то домен с которым пришел клиент - неплохо бы проверить его по списку.
Те, кто использует Caddy таким образом в проде, сильно рискуют, если они не поставили перед ним ещё какой-то прокси, который умеет фильтровать TLS-подключения по SNI и таким образом фильтруют их по списку, либо используют механизм проверки домена внешним запросом к хранилищу, который предоставляет Caddy. Т.е. так или иначе, список доменов где-то есть и по нему происходит сверка.
Потенциально такой режим можно добавить и в Angie с соответствующими предупреждениями и инструкциями, как это безопасно настроить. Но какая-то проверка по списку доменов все равно будет, просто этот список будет храниться вне конфигурации сервера.
Еще, почему-то веб-сервера не умеют сами подбирать сертификаты. Мне кажется немного тупостью, что нужно для каждого виртхоста прописывать, где ему искать файлы с сертификатом и ключам - лишние хлопоты, громоздкий конфиг, лишние ошибки.
Абсолютно с вами согласен. Поэтому в свое время в NGINX Unit я реализовал это иначе. Там сертификат и ключ автоматически выбирается по SNI исходя из тех доменов, что прописаны в сертификате.
nginx и многие сервера появились задолго до того, как появился SNI, отсюда и такая настройка. Можно подумать над тем, как это переделать в Angie, чтобы было проще и удобнее чем механизм, унаследованный от nginx, но это уже отдельная задача.
99% статьи — про то, что такое ssl, wildcard-сертификаты и как их получить.
ещё и написано чатботом. : (
зашёл узнать, насколько удобнее angie, чем связка nginx+dehydrated именно для получения сертификатов с http-авторизацией (т.е., условно говоря, я добавляю новый server {}, а сертификаты для него получаю автоматически).
вместо этого вода-вода-вода CF, OctoDNS, что угодно — только не Angie.
Ну, хоть про OctoDNS узнал, тоже плюс.
P.S. используйте в системном промпте что-нибудь вроде "не нужно слишком подробно, рассказывай для администраторов линукс среднего уровня", а то получилось молоко с водкой — вроде и тема IaC поднимается, которая начинающим скорее вредна, а вроде и разжёвано на уровне apt install… (чего тогда не "чтобы включить компьютер, воткните вилку в розетку"?)
зашёл узнать, насколько удобнее angie, чем связка nginx+dehydrated именно для получения сертификатов с http-авторизацией (т.е., условно говоря, я добавляю новый server {}, а сертификаты для него получаю автоматически).
А чем в таком случае не устроила официальная документация?
потому что документация описывает как настроить, так?
а мне был интересен опыт практической эксплуатации. В духе "у нас был certbot, мы поставили angie, стало удобнее, потому что…"
статьи на хабре тем и ценны. Иначе зачем они, есть же документация?
Такие сообщения регулярно в телеграм чате поддержки и комментариях в разных местах. Там просто не о чем писать: "поставили Angie, добавили пару директив, все работает автоматически, спасибо большое" - в таком духе. Пример: https://t.me/angie_support/7987 Если вдруг не работает, то обращаются за помощью и помогаем разобраться почему не работает.
Как поддержку добавили, я сам у себя на сервере удалил Certbot, добавил пару директив и работает с тех пор. Какой плюс? Избавился от лишнего компонента, которым забываешь как пользоваться через несколько месяцев и приходится вспоминать, когда нужно очередной домен завести. В конфиге веб-сервера его так или иначе нужно прописывать и теперь для этого достаточно просто добавить домен в server_name, сделать релоад конфига и всё. Не знаю как из этого выжать целую статью.
А тут коллега детально описал самый комплексный случай настройки, который только можно придумать, разобрался с OctoDNS и другими инструментами, которыми может кто-то захотеть воспользоваться, всё протестировал, написал скрипт и AFAIK никаких промптов. Людям теперь везде ИИ мерещатся. =)
Автоматический HTTPS для ленивых: ACME + Angie один раз и навсегда