Комментарии 96
НЛО прилетело и опубликовало эту надпись здесь
А зачем пересоздавать CSR при обновлении скртификата ?!?!!!
НЛО прилетело и опубликовало эту надпись здесь
плюньте вы на этот certbot (хотя наверняка в нем это настраивается).
в acme-tiny путь к csr и сертификату — параметры командной строки. засунули в cron и все.
Конфигурационные файлы для renew сертификата лежат в директории (актуально для Ubuntu, возможно в других дистрибутивах путь может быть другой) /etc/letsencrypt/renewal в них есть все параметры, которые указываются ключами для certbot ( и которые описаны в man'е)
Используйте шифры, дающие perfect forward secrecy, и не переживайте о ключах. От них никакого толка для желающих почитать трафик в случае использования DHE и ECDHE.
У Let's Encrypt есть проблема — отсутствие аналогов (бесплатный сертификат по acme).
imho certbot слишком перегружен, рекомендую acme-tiny.
или acme-client
Я бы отметил еще, что certboot пока не умеет idn, хоть и заявлен. Так что владельцы доменов.рф,.рус пока не могут получить для них сертификат. Хотя тот же https://github.com/Neilpang/acme.sh это делает отлично
Даже если указывать домен в Punycode?
Да. На гитхабе в issue обещали поправить в начале декабря, но так и не исправили. Пишет, что не знает доменную зону xn--p1ai. В acme.sh исправили оперативно
в гите есть ветка, где проверку на idn выпилили, но пока оно не в master
Я и ее пробовал — та же беда. Может за последние недели 2-3 чего поменяли
В certbot#3614 пишут что вот-вот всё это будет.
Вообще-т уже 16 дней как сделали, сам неделю назад накатил на рф, пруф.
А если вы освоили докер, то можно практически ничего не настраивать, если использовать
https://github.com/jwilder/nginx-proxy и
https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion
только указать имена хостов и мейл для регистрации сертификатов.
https://github.com/jwilder/nginx-proxy и
https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion
только указать имена хостов и мейл для регистрации сертификатов.
Для меня все восторги по поводу letsencrypt заканчиваются на необходимости поддерживать SSL не только на веб фронтах. Вы удивитесь, но в мире есть не только nginx и апач! Есть tomcat, винда с iis, exchange, микротики, разношерстное телекоммуникационное оборудование, iLo серваков, админки СХД и куча других сервисов и железок, куда сертификат можно поставить только вручную.
Приземлять HTTPS на nginx, а дальше http.
Под винду с iis есть клиент letsencrypt-win-simple, который прописывается в планировщик.
для «внутреннего» оборудования удобнее сделать свой CA, подписать сертификаты на 10 лет и добавить этот CA в браузеры сотрудников
Ну ок. И в чем проблема?
А в чем проблема-то? Http используется только для подтверждения владения доменом, где вы дальше используете полученный сертификат — ваше дело.
Мы mx'ы все letsencrypt'ом оtlsили, обновляется автоматом ессно.
Для интРАнет сервисов логичнее свой CA поднять
Есть непубличные сервисы доступные определённому списку ip-адресов и/или через IPSec-туннель. К ним не сможет доступчаться бот LE (его адреса зачем-то скрывают), а проверка через DNS не поддерживает наш NS и придётся делать это вручную.
Плюс всякие железки, вроде ASA с AnyConnect или контроллера Wi-Fi с captive-порталом, где тоже нужен нормальный сертификат, но нет встроенного клиента.
LE отличная штука для публичных сайтов, а для всего остального мне проще купить сертификат у GGSSL за $10 и забыть про это на 3 года.
Плюс всякие железки, вроде ASA с AnyConnect или контроллера Wi-Fi с captive-порталом, где тоже нужен нормальный сертификат, но нет встроенного клиента.
LE отличная штука для публичных сайтов, а для всего остального мне проще купить сертификат у GGSSL за $10 и забыть про это на 3 года.
> его адреса зачем-то скрывают
Правда что ли? А как можно скрыть от меня адреса с которых к моему веб-серверу обращаются?
Вы глупости говорите.
Интересно вам этот ггссл заплатил за рекламу или вы добровольно и бесплатно рекламируете какую-то сомнительную шарашку у которой и не факт, что ЦА в доверенных основных систем?
Правда что ли? А как можно скрыть от меня адреса с которых к моему веб-серверу обращаются?
Вы глупости говорите.
Интересно вам этот ггссл заплатил за рекламу или вы добровольно и бесплатно рекламируете какую-то сомнительную шарашку у которой и не факт, что ЦА в доверенных основных систем?
А как можно скрыть от меня адреса с которых к моему веб-серверу обращаются?
Вот только знать его надо перед подключением и не обязательно следующая попытка будет с того же адреса.
Интересно вам этот ггссл заплатил за рекламу или вы добровольно и бесплатно рекламируете какую-то сомнительную шарашку у которой и не факт, что ЦА в доверенных основных систем?
У них брендированные сертификаты от Comodo по самым низкий ценам. Ещё они рассказывают всякое интересное тут.
Чтобы заработал Forward Secrecy я ещё добавляю в конфиг nginx'a
Сгенерировать ключ можно так:
Заодно можно включить http2 (добавив опцию в директиву listen):
Ну и ещё можем добавить
Этим мы позволяем серверу прикреплять OCSP-ответы, тем самым уменьшая время загрузки страниц у пользователей.
Что бы не прописывать это каждый раз, можно поменять шаблон certbot'a в файле
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
Сгенерировать ключ можно так:
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048Заодно можно включить http2 (добавив опцию в директиву listen):
listen 443 ssl http2;
Ну и ещё можем добавить
ssl_stapling on;
Этим мы позволяем серверу прикреплять OCSP-ответы, тем самым уменьшая время загрузки страниц у пользователей.
Что бы не прописывать это каждый раз, можно поменять шаблон certbot'a в файле
/etc/letsencrypt/options-ssl-nginx.conf
Затем для каждого домена и поддомена, для которых нужно получить сертификаты, в блоке server перед всеми блоками location укажем
А что в случае, если используются автоподдомены, например языковые?
Они же указываются в директиве server_name, ведь так?
надо указывать весь список, wildcard сертификаты не выпускаются
Ууууу, ясно, большое спасибо, это реально по сути камушек в их огород)
у вас много языков на уровне автоподдоменов?
Видите ли-с в чем дело. Изначально в проекте предусматривали мультиязычность, и для простоты придумали систему, где все слова хранятся в простых текстовых файлах, которые очень легко переводить гугловским API, поэтому теперь в него можно с легкостью добавить любой язык, ибо для этого достаточно просто перевести языковой файл русского на любой другой язык, который поддерживает Google Translate. При таком раскладе стало очень интересно в числе прочих языков иметь всякие паджаби и латынь. Да это блажь, понимаю, однако лично я не вижу смысла урезать список всех языков до двух-трех только потому, что Let's Encrupt c какого-то перепугу не выдает Wildcard.
Не выдает, но почему вам это мешает? Так как одним сертификатом не обойтись (у Google Translate больше 100 языков), лучше, из соображений размера сертификата, сразу получить отдельные под каждый код языка.
for langcode in $(cat ISO_639-1.txt); do
certbot certonly -d $langcode.example.ru
doneДругой вопрос если вам нужно чтобы без SNI все работало. Только только $300 в год на *.example.ru или уход от идеи поддоменов решат вопрос.
Спасибо, интересно. Хотя с другой стороны на GoGetSSL можно взять полноценный Wildcard и за немногим больше 70$ кстати.
P. S. Кто бы мог подумать, что тема неожиданно превратится в настоящий Тостер) В таких ситуациях я нахожу весьма нужным возможность заносить комменты в избранное.
P. S. Кто бы мог подумать, что тема неожиданно превратится в настоящий Тостер) В таких ситуациях я нахожу весьма нужным возможность заносить комменты в избранное.
тогда настройте hook, который при запросе "нового" языка будет расширять сертификат, добавляя в него поддомен и потом уже осуществлять обычный ответ с сертификатом. Не думаю, что это будет слишком большой оверхед
в соседней ветке посоветовали вот это https://caddyserver.com/
Вы не поверите, как раз некоторое время назад рассматривал его, правда с с другой стороны (как замена Апачу, а лучше вообще NGINX), он действительно на удивление хорош, однако на англоязычном SO говорили, что пока он подойдет только для тестирования на локале, типа с нагрузкой в продакшене он не справится, поэтому и о замене им неншних решений говорить пока весьма рано. К сожалению не смог найти сходу ссыль на этот вопрос, однако очевидно, что фигни там не посоветуют, ибо за такое можно неслабо словить минусов (это, к тому же, практически единственная область, где их там можно словить).
P. S. Да и может у нас необходимость иметь десятки языков, может мы Красный Крест какой, почему нет?))
https://github.com/GUI/lua-resty-auto-ssl
И генерируйте на лету, при обращении к домену :)
И генерируйте на лету, при обращении к домену :)
Ого! Вкуснотища какая, у меня аж слюни потекли)
Приятного аппетита! Для Ubuntu 14.04 LTS у меня где-то ppa есть для openresty под это дело, вдруг понадобиться.
Ахах, ну да, спасибо) У меня (ну не у меня, конечно. На сервере) Дебиан (уже Джесси), однако я не знаю какой сюрприз может подготовить мне судьба, поэтому на решение для Убунты я бы тоже глянул бы… Да и для общественности можно оставить на сохранение.
Влепившему минус Вашему комменту я бы порекомендовал бы попытаться высказать Вам его претензии лично при встрече. Уверен, он даже из дома побоиться выйти, куда уж там что-либо высказывать…
Влепившему минус Вашему комменту я бы порекомендовал бы попытаться высказать Вам его претензии лично при встрече. Уверен, он даже из дома побоиться выйти, куда уж там что-либо высказывать…
https://launchpad.net/~ernillew/+archive/ubuntu/operesty-for-le
Ну собственно можете взять оттуда исходники пакета и собрать для Jessie себе, все будет попроще. Просто почему-то OpenResty не пакетят в дистрах, вот пришлось самому это сделать, пока было нужно.
А на минусы я внимания не обращаю, по моим комментам есть какой-то анонимный фанат, ходит и минусит, фиг бы с ним. Мои комментарии полезны коллегам, а остальное меня не волнует.
Ну собственно можете взять оттуда исходники пакета и собрать для Jessie себе, все будет попроще. Просто почему-то OpenResty не пакетят в дистрах, вот пришлось самому это сделать, пока было нужно.
А на минусы я внимания не обращаю, по моим комментам есть какой-то анонимный фанат, ходит и минусит, фиг бы с ним. Мои комментарии полезны коллегам, а остальное меня не волнует.
Ясно, благодарю!
А так да, и сам иногда попадаю под раздачу. Тут имеется большое количество таких людей, и очень жаль на самом деле, что так получилось, что самая большая концентрация во всем интернете находится как раз на Хабре/Гиктаймсе. Возможно, всему виной возможность отрицательного голосования за комментарии. Ни на каком другом ресурсе нет такой возможности по подленькому показать свое отношение к человеку, не показывая своего лица. Поэтому имеем что имеем. Я сам программист, и в таких ситуациях думаю только об одном: «Хоть бы этот человек не был программистом, дабы не очернять эту светлую профессию»)
А так да, и сам иногда попадаю под раздачу. Тут имеется большое количество таких людей, и очень жаль на самом деле, что так получилось, что самая большая концентрация во всем интернете находится как раз на Хабре/Гиктаймсе. Возможно, всему виной возможность отрицательного голосования за комментарии. Ни на каком другом ресурсе нет такой возможности по подленькому показать свое отношение к человеку, не показывая своего лица. Поэтому имеем что имеем. Я сам программист, и в таких ситуациях думаю только об одном: «Хоть бы этот человек не был программистом, дабы не очернять эту светлую профессию»)
Может кто уже такое делал (в принципе, не должно быть особо сложно — но я сейчас гриппую, не могу собрать мозги в кучку...):
1) есть nginx фронт на публичном IP
2) есть nginx back на публичном IP
3) есть amazon route53
4) основной трафик идет на 1 и с него проксируется на 2
5) если 1 упал, то route53 обновляет DNS и запросы идут уже на 2
Вопрос в том как правильно запрашивать сертификаты ведь нужно их иметь и на 1 и на 2.
Допустимо ли иметь разные сертификаты (и позволит ли LE) для одних и тех же доменов, причем если в нормальном режиме, то оба запроса будут проходить через 1 (с точки зрения LE).
Пока что обдумываю вариант с редиректами на hostname 1 и 2 чтобы гарантированно направлять ACME на них, но это не отвечает на вопрос позволит ли LE два (а если три?!) сертификата для одного и того же домена и не отзовет ли он предыдущий сразу после выдачи/обновления последнего…
1) есть nginx фронт на публичном IP
2) есть nginx back на публичном IP
3) есть amazon route53
4) основной трафик идет на 1 и с него проксируется на 2
5) если 1 упал, то route53 обновляет DNS и запросы идут уже на 2
Вопрос в том как правильно запрашивать сертификаты ведь нужно их иметь и на 1 и на 2.
Допустимо ли иметь разные сертификаты (и позволит ли LE) для одних и тех же доменов, причем если в нормальном режиме, то оба запроса будут проходить через 1 (с точки зрения LE).
Пока что обдумываю вариант с редиректами на hostname 1 и 2 чтобы гарантированно направлять ACME на них, но это не отвечает на вопрос позволит ли LE два (а если три?!) сертификата для одного и того же домена и не отзовет ли он предыдущий сразу после выдачи/обновления последнего…
Это Вам на Тостер надо. Серьезно. Вероятность получить ответ в комментах к статьям крайне мала. Она есть, конечно, однако это может быть только случайный прохожий, который сталкивался с этой проблемой. На Тостере же люди специально подписываются на теги конкретно по технологиям.
Емнип, при выпуске нового сертификата старый автоматически НЕ отзывается.
LE позволяет выпускать сертификаты совершенно спокойно.
У меня есть несколько фронтов с nginx'ами(RR DNS) на которых я таки на каждом получал сертификат отдельно, плюс на бэке с nginx'ом же свой сертификат для того же домена. Все прекрасно работает. При получении нового старый никто не отзывает автоматом, можете не беспокоится.
У меня есть несколько фронтов с nginx'ами(RR DNS) на которых я таки на каждом получал сертификат отдельно, плюс на бэке с nginx'ом же свой сертификат для того же домена. Все прекрасно работает. При получении нового старый никто не отзывает автоматом, можете не беспокоится.
Можно ещё просто скалдывать сертификаты в сетевую шару, откуда они будут доступны нужным серверам, а автоматизацию выдачи, соо-но, оставить только в одном месте.
А это только меня напрягает, что у нас появился центр, в котором будут хранится все private ключи и который, со временем, за счет бесплатности, перетащит к себе пол интернета?
он не хранит приватные ключи.
но «единая точка отказа» напрягает.
но «единая точка отказа» напрягает.
Может быть и такое развитие событий:
1) браузеры в 2017 году начинают считать небезопасным сайты без шифрования (это уже запланировано);
2) все, у кого нет возможности купить сертификат, соскакивают на letsencrypt;
3) через годик он меняет условия выдачи бесплатных сертификатов (срок действия, либо платность, либо вообще пропадает);
4) у продавцов сертификатов — profit
1) браузеры в 2017 году начинают считать небезопасным сайты без шифрования (это уже запланировано);
2) все, у кого нет возможности купить сертификат, соскакивают на letsencrypt;
3) через годик он меняет условия выдачи бесплатных сертификатов (срок действия, либо платность, либо вообще пропадает);
4) у продавцов сертификатов — profit
Про платность и пропажу вы просто бредите, потому что не соизволили почитать кто стоит за LE. А за LE стоит Mozilla, стоит Cisco, стоит Google, стоят OVH и Vultr, и так далее.
https://letsencrypt.org/sponsors/
https://letsencrypt.org/sponsors/
Конечно, прочитал еще до того, как сделал первый сертификат :)
Но это не отменяет вышесказанное.
Вот когда появится 2-3 таких CA, будет заметно интереснее.
IMHO целью стоит внедрить повсеместное шифрование, 1) чтобы не все спецслужбы заглядывали в трафик, 2) чтобы запустить http2.
Но это не отменяет вышесказанное.
Вот когда появится 2-3 таких CA, будет заметно интереснее.
IMHO целью стоит внедрить повсеместное шифрование, 1) чтобы не все спецслужбы заглядывали в трафик, 2) чтобы запустить http2.
Создать CA который попадет в доверенные в системах и браузерах сложно, а потому второй такой появится вряд ли. За LE стоят все крупные игроки рынка, каких только можно представить, некому встать за вторым таким же.
Безусловно целью был повсеместный переход на http/2 и соответственно https(как мы помним http/2 без ssl'а несуществует), такой переход лично я поддерживаю двумя руками и с момента, как LE вышел из беты я по умолчанию всем клиентам делаю https с сертификатом от LE.
Безусловно целью был повсеместный переход на http/2 и соответственно https(как мы помним http/2 без ssl'а несуществует), такой переход лично я поддерживаю двумя руками и с момента, как LE вышел из беты я по умолчанию всем клиентам делаю https с сертификатом от LE.
Есть надежда, что со временем допилят проверку через DNS aka DANE (rfc7671), тогда для простого https не нужен будет letsencrypt
Я в какой-то момент перестал верить, что DANE допилят, если честно. А LE реально стало спасением, автоматическое обновление сертификатов позволило мне просто забыть о том, что надо получать новые, тащить их на сервер, укладывать куда-то(не важно руками или оркестрацией какой-нибудь).
Единственное что, я считаю, что certbot странен и неудобен, использую https://github.com/hlandau/acme и очень доволен.
Единственное что, я считаю, что certbot странен и неудобен, использую https://github.com/hlandau/acme и очень доволен.
Чтобы спецслужбы не заглядывали вот так просто в ваш трафик, используйте DHE и ECDHE. Эта рекомендация верна для любых центров выдачи сертификатов.
Для Ubuntu 16.04 есть ppa, а то с сайта и с репозитория ставится только letsencrypt.
PPA Certbot
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install --upgrade letsencrypt
letsencrypt --version
У меня почему то на многих сайтах, где стоит сертификат от letsencrypt, доктор веб на некоторых компах блокируют сайты как ненадежный сертификат/ошибка сертификата, хотя сам сертификат установлен корректно и не имеет ошибок. проверял
Возможно не вся цепочка доверия установлена?
Возможно, доктор веб имеет своё личное хранилище доверенных корневых/промежуточных сертификатов, куда корневые сертификаты от Let's Encrypt ещё не попали. Если SSL Test на этих сайтах не ругается на Chain Issues, то надо пинать поддержку доктор веба.
А можно ли запустить chalange сервер не на 80м порту? У меня там бежит апач и при получении сертификатов раз в 3 месяца приходится останавливать апач, обновлять сертификаты, запускать апач. Было бы удобно если бы acme поддерживал альтернативные порты, например 81, 1880, 8080, 443
Запустить можно, но ACME сервер все равно пойдет смотреть на 80-й.
Ну в общем то я это имел ввиду. Можно ли заставить acme смотреть не 80.
Не нужно. Используйте webroot и так:
Alias /.well-known/acme-challenge /var/www/html/.well-known/acme-challenge
<Directory "/var/www/html/.well-known/acme-challenge">
Options None
AllowOverride None
Require all granted
AddDefaultCharset off
</Directory>В остальном все то же самое что в инструкциях в посте.
Жаль. Я хотел повесить nginx'овский редирект 301 на 81-й порт, но не вышло. Всё равно придётся отдавать 80-й порт под верфикацию.
Хотя фраза «Переадресация возможна даже на нестандартные порты, без ограничений по конечному протоколу HTTP или HTTPS.» очень обнадёжила.
P.S. Использую certbot 0.9.3 на Debian.
Может в 0.10.х можно переопределить порт, на который должен стучаться ACME?
Хотя фраза «Переадресация возможна даже на нестандартные порты, без ограничений по конечному протоколу HTTP или HTTPS.» очень обнадёжила.
P.S. Использую certbot 0.9.3 на Debian.
Может в 0.10.х можно переопределить порт, на который должен стучаться ACME?
С какой ошибкой не выходит?
Failed authorization procedure. ***.*** (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to validation-server.***.***:81
Если вешаю редирект на 80-й, всё ОК.
Вы сами можете файлы по этому порту получить через curl? Как здесь
А если не с locahost, а откуда-то из сети?
Да, могу. Запросы извне тоже нормально отрабатываются.
Думаю, что если порыбачить tcpdump'ом, то я увижу запросу от ACME-сервера на 80-м.
Думаю, что если порыбачить tcpdump'ом, то я увижу запросу от ACME-сервера на 80-м.
А вот сейчас не понял. После энной попытки верификация прошла. Более того, убрал редирект, погасил nginx на сервере проверки и всё равно работает. Ничего не понимаю.
ACME-сервер всегда сначала спрашивает на 80 порту. Куда вы его потом редиректите — ваше дело.
Думаю, закавыка в редиректе nginx.
Использовал два идентичных варианта:
Через curl запросы успешно доходят до validation-server, а от ACME болт.
Перевешиваю nginx на validation-server на 80-й (или standalone-режим на 80-й порт) и убираю ':81' из редиректа — всё работает.
Возможно, надо не редиректить, а проксировать запросы.
Использовал два идентичных варианта:
rewrite ^/.well-known/acme-challenge/(.*)$ http://validation-server.***.***:81$request_uri? permanent;
location ^~ /.well-known/acme-challenge/ {
return 301 http://validation-server.***.***:81$request_uri;
}
Через curl запросы успешно доходят до validation-server, а от ACME болт.
Перевешиваю nginx на validation-server на 80-й (или standalone-режим на 80-й порт) и убираю ':81' из редиректа — всё работает.
Возможно, надо не редиректить, а проксировать запросы.
А кто вам мешает использовать режим webroot?
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за полезную и понятную статью.
А нет ли возмоности параметризировать эти строки?
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
…
Чтобы вместо example.com подставлялся соответствующий домен?
А нет ли возмоности параметризировать эти строки?
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
…
Чтобы вместо example.com подставлялся соответствующий домен?
Если вы хотите чтобы это происходило динамически, для любых доменов, то нет — так не получится сделать в nginx.
nginx не принимает свою встроенную переменную $server_name в этих параметрах, так же, как не принимает ее в error_log(а вот в access_log принимает).
На самом деле очень не хватает такой возможности, но насколько я понимаю ее добавление утяжелит жизнь nginx'а(хотя лично на своих проектах я бы nginx с патчем дающим такую возможность поставил бы, это изрядно упростило бы жизнь).
На самом деле очень не хватает такой возможности, но насколько я понимаю ее добавление утяжелит жизнь nginx'а(хотя лично на своих проектах я бы nginx с патчем дающим такую возможность поставил бы, это изрядно упростило бы жизнь).
выше было как вариант
Если вы читаете этот текст из будущего, когда Certbot уже есть в Debian stable и Ubuntu без обиняков и оговорок, то всё просто
Похоже что debian 9 и есть то будущее которого мы ждали.
Спасибо за отличную статью!
Что бы Вы порекомендовали делать в 2023 году ?
Сильно процесс поменялся?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Let's Encrypt и nginx: настройка в Debian и Ubuntu