Comments 42
До сих пор доверие к сертификатам Let's Encrypt обеспечивалось благодаря промежуточному сертификату, перекрестно подписанному как корневым сертификатом Let's Encrypt, так и корневым сертификатом организации IdenTrust
Мне показалось, что сначала Let's Encrypt напрасно упомянула кросс-сертификацию, а при переводе усугубилась ситуация.
Могли бы подсказать, где там кросс-сертфикация? Обычный Intermediate CA на вид у LE сейчас, с Path Length Constraint =0.
Я так понимаю ситуацию, что, даже оказавшись во всех списках корневых доверенных, они не могут уйти от кросс, поскольку сначала эти списки должны распространиться по миру. А это, как практика показывает, не быстро делается. В Windows 10 и прочих ОС, где «нельзя не обновиться самому, иначе обновят за тебя» процесс более-менее еще идет, а где вопрос упирается в желание юзера — там тяжко. Думаю, LE в результате выжидают распространения.
Но о факте новости, конечно, грех было не рассказать.
Но о факте новости, конечно, грех было не рассказать.
- А есть российские/ белорусские сертификаты платные/ бесплатные? которые признавались хотя бы яндекс. браузером ?
- На сколько тяжело создать российский аналог Let's Encrypt, я так понимаю это т проект с открытым исходным кодом ?
- можно ли на 1 домен прикрепить 2 сертификата от 2х разных центров сертификации? Если можно то как будет выбираться основной сертификат и резервный/ дополнительный?
и очередным контраргументом против приобретения сертификатов у ЦС, занимающихся выпуском DV-сертификатов за деньги
ИМХО, главным контраргументом станет то событие, когда бесплатные сертификаты Let's Encrypt будут действовать год, а не три месяца.
В чем проблема? Желаете ручками обновлять?
Ручное обноление — зло. Например, владелец сайта bitmessage.ch забыл в этом году обновить сертификат, в результате чего на его сайт зайти было невозможно — он сам настроил всё таким образом, что браузеры не могли проигнорировать просроченный сертификат.
Никогда они не будут год действовать — и это хорошо, так как:
- Уменьшает ущерб в случае компрометации сертификата
- Дополнительно стимулирует ленивых технарей автоматизировать перевыпуск
Зачем?
Как раз очень удобно, что срок короткий — потому что это заставляет автоматизировать установку сертификатов (а это настолько просто и безопасно, что странно этим не пользоваться), тем самым уменьшая число ошибок при ручном деплое.
acme.sh с его stateless режимом:
А чем вам «раз в 3 месяца» не нравится?
Как раз очень удобно, что срок короткий — потому что это заставляет автоматизировать установку сертификатов (а это настолько просто и безопасно, что странно этим не пользоваться), тем самым уменьшая число ошибок при ручном деплое.
acme.sh с его stateless режимом:
acme.sh --issue -d example.com -d www.domain.com --stateless
acme.sh --install-cert -d example.com -d www.domain.com \
--key-file /path/to/keyfile/in/nginx/key.pem \
--fullchain-file /path/to/fullchain/nginx/cert.pem \
--reloadcmd "service nginx reload"А чем вам «раз в 3 месяца» не нравится?
Этот самый acme.sh становится черным ящиком и потенциальным вектором атаки.
Ничего, что вы apt upgrade делаете (только не говорите, что не обновляетесь), а ведь там могут быть и строки вроде:
(я про пробел).
Но вы впраче не верить, хотя acme.sh — это шелл-скрипт, его проверить легко. Не верите ему 9или certbot-у, или еще десятку альтернатив), так напилите такой же, протокол-то открыт.
Или, кто мешает, платите завоздух платные сертификаты.
rm -rf / var/lib/software/tmp(я про пробел).
Но вы впраче не верить, хотя acme.sh — это шелл-скрипт, его проверить легко. Не верите ему 9или certbot-у, или еще десятку альтернатив), так напилите такой же, протокол-то открыт.
Или, кто мешает, платите за
Я про то, что когда товарищу neilpang ломанут гитхаб (или придут товарищи китайские майоры с криптопаяльником), половина интернета может внезапно оказаться с закладками.
В промышленных дистрах (рх, дебиан) контроля всё-таки больше, хотя и туда закладки пропихивают.
В промышленных дистрах (рх, дебиан) контроля всё-таки больше, хотя и туда закладки пропихивают.
Т.е. слом репы с другими сотнями пакетов, равно как и кривые руки разработчиков (да, тот пробел как пример) вас смущают меньше, чем риск не туда и не так положить при деплое серта руками, но не рисковать работой темной лошадки скрипта обновления.
А чем плох вариант, если лично вами написанный скрипт будет делать то же, по тому же протоколу, но — без риска взлома гитхабабольшого друга Советского Союза тов. neilpang? Какие тогда у вас препятствия все делать автоматом и единообразно?
Вы же ротацию логов на сервере делаете не руками?
А чем плох вариант, если лично вами написанный скрипт будет делать то же, по тому же протоколу, но — без риска взлома гитхаба
Вы же ротацию логов на сервере делаете не руками?
ПО — не железное колесо, которое будет ездить и через 200 лет.
Если что-то может изменится — оно изменится. И рано или поздно это продление сломается. Да, может пройти 20 лет, но произойдет это точно.
Вы сравниваете контролируемый результат и неконтролируемый. Даже если rm -rf пройдет в релиз то после выполнения можно сразу убедиться что что-то пошло не так, чего не скажешь о продлении.
Имхо, пол года было бы самое то.
Если что-то может изменится — оно изменится. И рано или поздно это продление сломается. Да, может пройти 20 лет, но произойдет это точно.
Вы сравниваете контролируемый результат и неконтролируемый. Даже если rm -rf пройдет в релиз то после выполнения можно сразу убедиться что что-то пошло не так, чего не скажешь о продлении.
Имхо, пол года было бы самое то.
Ручками оно всегда надёжнее. Если люди рукастые, и если дел не очень много, и если все задокументировано.
Я не сомневаюсь в ваших навыках и памяти. Но вот вы заболели или уволились, и кто-то другой будет всю ручную рутину делать — наверное, тоже хорошо, но вдруг не так, как вы?
И уж я не поверю, что, делай они серты на полгода, вы бы без оглядки, а на 3 мес — увы, нет.
Написать скрипт плюс поставить мониторинг на серты (и то, и другое — просто must have), и живите себе. Платные ЦС, вообще говоря, не устраняют необходимость в этом.
Жду появления конкурента LE. Тогда уж точно конец торговле воздухом!
Это в линухе просто, а в винде что-то не очень. А если у меня апплаинс проприетарный наружу торчит, там вообще сначала нужно DNS поменять на машину с клиентом ACME, перевыписать, установить сертификат в апплаинс, а потом обратно DNS поменять. Сервис в это время недоступен, сами понимаете.
А там ещё многое «не очень».
Зачем? А проверку через днс сделать, уж в днс нужное вписать можно без остановки сервиса?
Поищите, есть примеры, как на тот Микротик впихивпют серты — прямо ваша ситуация )
Или вот, github.com/Neilpang/acme.sh/wiki/DNS-alias-mode ещё интереснее, DNS alias используется.
В общем, было бы желание )
Поищите, есть примеры, как на тот Микротик впихивпют серты — прямо ваша ситуация )
Или вот, github.com/Neilpang/acme.sh/wiki/DNS-alias-mode ещё интереснее, DNS alias используется.
В общем, было бы желание )
Есть один нюанс — у некоторых пользователей на компьютере не включена синхронизация времени, и если их системные часы прилично отстают, то после обновления сертификата они некоторое время не могут попасть на сайт из-за того, что их браузер считает, что сертификат еще не начал действовать. Соответственно, при обновлении сертификата раз в три месяца такие ситуации возникают в четыре раза чаще, чем при обновлении раз в год.
Кстати, хотел узнать ваше мнение. Если ли смысл в Organization validated сертификатах для крупных компаний? Гребли с ними много из-за неизбежных бюрократических задержек при покупке, а для конечного пользователя они ничем не отличаются от DV. Тут смысл в том, что с переходом на letsencrypt можно будет быстро поднимать нужные домены и не грузить поддержку оформлением закупок и всем прочим.
Я смысла для веба не вижу. На моей памяти никто из юзеров не сказал ничего в стиле "о, эта компаний купила серт не того уровня проверки, я ей не верю". Даже зелёные EV сертификаты есть и есть, а вот что на них написано название компании — прикол, не более, разве что узнать можно, что магазином с громким именем владеет компания ООО Пупкин.
Сертификат всего лишь показывает, кто его покупает и кто управляет доменом. Доп. проверки тут просто бюрократия, за которую юзеры даже спасибо не скажут (не поймут потому что разницы).
Есть небольшая разница: защищенный — не значит не идентичный, в смысле именно тот сайт.
С названием компании в строке сомнений быть не может.
С названием компании в строке сомнений быть не может.
Ой ли. Сколько угодно (в т.ч. и по https) есть фишинговых (грубо) sderbanck или mikrosofl. И все механизмы уверены, что все ок.
Получаем, что самое важное — чтобы человек проверял, куда зашёл. Проблема в прокладке, так сказать, и ее OV не решает.
Думаете что mikrosofl пропустят сюда?
Не могу утверждать, но что-то подсказывает что никогда не пропустят. Почитайте ответственность за ошибки в сертефикате и что за это грозит.
Не могу утверждать, но что-то подсказывает что никогда не пропустят. Почитайте ответственность за ошибки в сертефикате и что за это грозит.
EV — это хорошо. А вот OV, о котором речь — как бы ниочем. Бюрократии много, а юзеры не будут смотреть, что там за серт.
Ну и второе: какие есть критерии, чтобы мой сайт (условно) hadr.com не снабдили сертификатом, ссылаясь, что уже есть в природе habr.com. Домен мой (условно говоря), никаких ошибок.
Ну и второе: какие есть критерии, чтобы мой сайт (условно) hadr.com не снабдили сертификатом, ссылаясь, что уже есть в природе habr.com. Домен мой (условно говоря), никаких ошибок.
Никаких, речь шла о крупных площадках. Хотя проверка все равно наверняка есть.
Собственно и думаем о целесообразности перехода на Let's Encrypt. Просто в любой большой компании такое воспринимается сразу как нечто несолидное. Бесплатно? Явно что-то не то. Но тут именно вопрос оперативности выдачи, а не экономии.
OV нет. Её убил сначала DV, а потом и Let's Encrypt. Именно поэтому убирают зеленый замочек из адресной строки, что оно теперь вообще ничего не говорит.
EV — ваш выбор. Вы же крупная организация, можете себе и wildcard EV купить)
EV — ваш выбор. Вы же крупная организация, можете себе и wildcard EV купить)
Sign up to leave a comment.
Теперь все основные списки корневых сертификатов доверяют Let's Encrypt