Минусы Let's Encrypt

Быстро заканчиваются, надо писать скрипты для автоматизации процесса обновления сертификатов. И нет wildcard.

А в плане безопасности?

Ну, я не вижу проблем безопасности.

ХЗ, мне норм. Главный минус пожалуй — необходимость перебрать несколько отмороженных ACME-клиентов что-бы найти dehydrated. Штатный клиент — наркоманское нечто.
Необходимость автоматизировать реновацию сертификатов это скорее багофича. Заставляет адекватно продумать процедуру которая будет адекватно работать без ручного вмешательства.

Lets Encrypt запросто может подписать сертификат с CN твоего сайта для каких-нибудь внутренних органов, например. Причём никто и никогда не выкинет Lets Encrypt за это из списков CA, как это уже не раз было с китайскими конторами которые были пойманы на раздаче левых сертификатов.

Lets Encrypt запросто может подписать сертификат с CN твоего сайта

Каким образом?

Тем-же самым образом которым это может сделать любой другой СА. Сабж выделяется тут только тем что его (как и некоторых других игроков) очень трудно выкинуть из списков доверенных.

Кроме тех соображений которые справедливы для всей сложившейся системы CA в целом (думаю гуглинг чего-то вроде ssl in brocken может многое рассказать на эту тему)?
Ну, там нужен клиент который будет иметь доступ как минимум к сертификату и закрытому ключу (и немного к сайту, но там всё можно сильно огородить), как максимум клиент может иметь доступ ко всему серверу (если ты упоришся запустишь его от рута). Некоторые клиенты достаточно просты что-бы провести аудит их безопасности, но понятно что 99.9999% процентов этого не сделают.

Тем-же самым образом которым это может сделать любой другой СА.

Я думал, мне сейчас расскажут о чём-нибудь типа man-in-the-midle для acme. Понятно, что в теории любой центр сертификации может выпустить любой сертификат. И Let's Encrypt тут не отличается от других.

Так же, как этим занимался и занимается CNNIC. За деньги или по приказу, например. CNNIC fake certificate в гуглях набери. А потом загляни в список CA браузера, например.

Поэтому вся эта херня с централизованными CA - вообще ничего не значит в плане безопасности и нужна только для того, чтобы совместно с браузерописателями вытягивать бабло из тех, кто хочет чтобы их сайтеги открывались без предупреждения и с зелёненьким замочком.

А вот это кстати интересно, про это надо посмотреть.
Вообще, как я понял, запросы к ACME-серверу подписываются закрытым ключём клиента (отличным от ключа сертификата), но:
1) Я это вообще-то не проверял.
2) Первичная передача публичного ключа серверу защищена в лучшем случае только https.

И похоже что обмен открытыми ключами однонаправленный (клиент регистрируется на сервере), так-что сообщения клиента не шифруются, а ответы сервера не подписываются (кроме того что используется https). Так с ходу решета (кроме подмены публичного ключа клиента при первичной регистрации использую решетовость https) я тут не вижу.

И для защиты от мамкиных какиров

И для защиты от мамкиных какиров

Зависит от того, кто мама и папа у мамкиного хакера и сколько у них денег и возможностей.

Собственно вся система CA тотально облажалась с китайцами. Если бы CNNIC был выкинут из списков CA немедленно и безвозвратно, причём на уровне личностей сотрудников, т.е. появился бывший сотрудник CNNIC в другом CA - этот CA тоже немедленно выкидывается - тогда вся эта система заработала бы себе хорошую репутацию и доверие. Но всё было мгновенно просрано при первом же фэйле, поэтому никакого доверия к этой системе уже нет и никогда не будет, а у участников оной развязаны руки на предмет раздачи левых сертификатов кому угодно. Поэтому получить мамкиному хакеру левый сертификат от фэйсбучека, чтобы отMiTMить соседа - вопрос только бабла и/или связей папы и мамы.

надо писать скрипты для автоматизации процесса обновления

Дык в certbot же есть обновление — надо только в крон или systemd правильно добавить.

https://freessl.mustlife.ru/ еще для удобство есть такая штука.

надо писать скрипты для автоматизации процесса обновления сертификатов

certbot renew в crontab.

…указать данные для подключения по SSH/FTP и наш сервис сам загрузит на ваш сервер…

Лол, что?

ТС ведь просил минусы.
Минус: надо добавлять в крон нечто для обновления сертификата.
Плюс: достаточно добавить одну комменду/срипт в крон что-бы не париться об обновлении сертификатов.

Wildcards нету.

И вот это почитай https://community.letsencrypt.org/t/which-browsers-and-operating-systems-supp...

Wildcards нету

Компенсируется возможностью создать кучу сертификатов. Правда еть какой-то там временной лимит, так-что разом создать сертификаты на всю ЖЖшечку например не получится.

Я в курсе. Человек спрашивал про минусы.

Дык в certbot же есть обновление — надо только в крон или systemd правильно добавить.

Нужно сервисы пинать, чтобы использовали новый сертификат.

Минусы Let's Encrypt (комментарий)

слишком монополисты на своей нише и врятли это просто изменится (слишком крутые инвесторы типа гугла и мозилы). В плане безопасности - не отличается от дефолтных платных

У меня скрипт обновления сертификата занимает девять строк. Из них три пустых, одна #!/bin/bash, одна для отладки (пишет в лог время и то что сейчас будем обновлять сертификат), две выставляют нужные мне права на сертификат (dehydrated выставляет их согласно своим представлениям о прекрасном). Для каждого сайта такой скрипт генерится и суётся в /etc/cron.monthly автоматически, при добавлении сайта на сервер.
В общем ерунда, просто нужно почесаться на эту тему, подумать и один раз настроить и протестировать всё. Кому-то приятнее раз в год тыкать в веб-интерфейс CA.

В общем ерунда, просто нужно почесаться на эту тему, подумать и один раз настроить и протестировать всё

Ну да, я об этом и говорю. Ничего сложного нет, но требуются некоторые телодвижения при первоначальной настройке.

А как ты будешь получать сертификат у любого платного сервиса? Точно также зайдешь на их сайт через https, залогинишься (паролем или своим сертификатом) и т. д. Ты же не пойдешь лично в центр выдачи сертификатов с флешкой. Опять же у утилит let's encrypt вполне может быть что-то типа pinned сертификатов, так что MiTM будет не так уж прост.

Вобщем, уязвимости те же, что и в случае с платными сертификатами. Отличие только в отсутствии wildcard.

В общем-то да. Разве-что с ACME-сервером взаимодействие чаще происходит, но ведь основная проблема это первичное взаимодействие.
Хорошо-бы добавить что-то вроде пининга ключей в сам протокол ACME, что-бы утилите надо было скармливать не только URLы сервера и лицензии, но и отпечаток ключа сервера.

Дык в certbot же есть обновление — надо только в крон или

Он ужасно реализован, кстати. Недавно у меня отвалился, когда запустился по крону обновить сертификаты. Но сперва он решил и себя обновить. Начал пересоздавать свой virtualenv и обломился, пожаловавшись на нехватку памяти для компиляции чего-то. И это несмотря на ключ --no-self-upgrade. Хорошо что мне выхлоп с крона на почту приходит, а то бы узнал только когда сайт отвалился бы. Проблему с компиляцией решил включением свопа. Хотя перед этим пробовал сгенерировать его свежий virtualenv на другой машине, но почему-то при запуске certbot его удалял и пытался создать новый, с компиляцией зависимостей (он на питоне, pip качает и компилит какие-то модули). Жесть вобщем.

EV нет и не будет.
От остальных минусов спасает manuale.

Питон? venv? Зачем? Им родина дала dehydrated на bash, пользуйся. Не хотят! Питоном обмазываться хотят

Питон? venv? Зачем? Им родина дала dehydrated на bash, пользуйся. Не хотят! Питоном обмазываться хотят

После этого я конечно посмотрел на альтернативные acme клиенты. Но естественно сперва я начал с их официального клиента. Так-то в питоне нет ничего плохого, если нормально реализовать. На питоне тоже есть альтернативные клиенты попроще, например acme-tiny.

Официальный клиент тоже на ещё дрянь. Вообще я не понял в честь чего они решили что впихнуть сертификаты в конфиг вебсервера это самая сложная для пользователей часть, и её надо непременно автоматизировать.

Так-то в питоне нет ничего плохого

Да. Только при условии что разраб понимает что со скриптом на сотню строк не надо тащить целый отдельный энваермент и компиляторы что-бы его собрать. К сожалению питонисты (и не они одни) в последнее время забывают об этом и радостно превращают свои поделки в блобы способные выжрать всю память на то с чем bash-скрипт справляется используя 9Мб памяти

Только при условии что разраб понимает что со скриптом на сотню строк не надо тащить целый отдельный энваермент и компиляторы что-бы его собрать. К сожалению питонисты (и не они одни) в последнее время забывают об этом и радостно превращают свои поделки в блобы способные выжрать всю память

Это всё они сделали ради того чтобы их клиент работал даже в debian wheezy (как раз мой случай), например. Так-то если использовать клиент из реп (в современных дистрах уже есть), этих проблем нет.

Я правда не стал доверять их скрипту автоматическую правку конфигов сервера, предпочёл руками. Могли бы хотя бы дать свой клиент без всех этих лишних плагинов.

dehydrated тоже работает на wheezy (наверное), и в зависимостях у него только curl, openssl, sed, grep, mktemp.
1123 строк кода, один файл, 9 Мб RAM.

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

Какие в анус монополисты? Во первых, доля letencrypt пока невелика. Во вторых, ACME - открытый протокол, массовый переход на него будет способствовать появлению новых CA. Если у тебя есть деньги, можешь даже сам открыть. Нужно будет заплатить существующему CA и пройти аудит.

А он предлагает какую-то дефолтную структуру папок в etc для ключей? Просто ключики иногда надо нескольким сервисам нужны, волохать их по куче папок не хочется.

массовый переход на него будет способствовать появлению новых CA

Речь про рост количества CA, поддерживающих протокол. Деньги же будут зарабатывать на EV, которые требуют подтверждения факта существования компании.

…чтобы даже домохозяйка справилась

Вот так взял и плюнул в душу с разбега. Я со стандартным клиентом не справился.

Не в /etc но предлагает.

Сами файлы:
${BASE_DIR}/certs/${FIRST_DOMAIN}/{cert,chain,fullchain,privkey}-${TIMESTAMP}.{pem,csr}
TIMESTAMP — время создание этого файла, старые версии файлов не удаляются.

Симлинки на актуальные версии файлов:
${BASE_DIR}/certs/${FIRST_DOMAIN}/{cert,chain,fullchain,privkey}.{pem,csr}

В моём случае для каждого сайта используется своя BASE_DIR (/var/www/${FIRST_DOMAIN}/letsencrypt), в ней-же лежит конфиг dehydrated, файл со списком доменов (domain.tld и www.domain.tld в 99% случаев), ключ аккаунта используемый для работы с ACME сервером, лог скрипта который запускается кроном и обновляет сертификат, и директория well-known/acme-challenges с которой работает dehydrated и которую nginx впиливает в сайт директивой alias (нех всяким скриптам трогать настоящий webroot, в котором в общем-то что угодно может быть).

Можно использовать одну BASE_DIR на все сертификаты, но в моём случае это неудобно.

Можно указать скрипт который dehydrated будет выполнять после получения/обновления сертификата, ему передаются пути к сертификату и ключу, имя домена. Этот скрипт может класть сертификат куда тебе надо, релоадить nginx, постить приватный ключ в твиттер… в общем что накодишь то и будет.
Но думаю что если тебе неудобно указывать ${BASE_DIR}/certs/${FIRST_DOMAIN}/cert.csr в конфигах всех твоих сервисов то можно просто создать симлинки на ${BASE_DIR}/certs/${FIRST_DOMAIN}/cert.csr в нужных местах. Или я неправильно понял твою проблему?

Вот так взял и плюнул в душу с разбега. Я со стандартным клиентом не справился.

Ну это часто так. То что заточено под ламеров, опытным пользователям зачастую неудобно.

Поэтому получить мамкиному хакеру левый сертификат от фэйсбучека, чтобы отMiTMить соседа - вопрос только бабла и/или связей папы и мамы.

HTTP Public Key Pinning

HTTP Public Key Pinning

Оно перпендикулярно вопросу о нужности CA. HPKP точно так же и с тем же успехом можно использовать и с самоподписанными сертификатами, впрочем, нужность этого костыля в случае самоподписанного сертификата сомнительна - ведь ключ которым подписан самоподписанный сертификат есть только у владельца сайта, и никто кроме самого владельца сайта липовый валидный сертификат выпустить не может. А на совсем левый самоподписанный сертификат браузер и без всякого HPKP ругаться будет по-полной.

И оно никак не решает проблему фейковых сертификатов, совершенно валидных, например, для свежеустановленного браузера, который ещё никаких хэшей ниоткуда не получил.

И оно никак не решает проблему фейковых сертификатов, совершенно валидных, например, для свежеустановленного браузера, который ещё никаких хэшей ниоткуда не получил.

Существует примерно ноль сайтов, состоящих из одной странички без скриптов, css, картинок. Попытка подгрузить их как минимум приведёт к угасанию зелёного замочка, а может и к непрогрузке сайта целиком (я пока не проверял, надо будет поглядеть завтра).

Ну, там нужен клиент

Есть, например, certbot упакованный в docker. Запускаешь в отдельном контейнере, экспортируешь том из этого контейнера в контейнер сайта и настраиваешь веб-сервер, что бы акми челендж ввел туда, все. Достаточно настроить один раз. К сайту и самой машине клиент доступов не имеет.

Конечно, он имеет доступ к сертификатам и приватным ключам (потому что он их пишет, как минимум, да CSR нужно чем-то подписывать).

HPKP никак не решает проблему Trust on First Use. Вообще. Это костыль предназначенный для того, чтобы хоть как-то заткнуть дыру в виде системы коммерческих CA, которая в случае самоподписанных сертификатов вообще не существует.

Т.к. система коммерческих CA полностью скомпроментирована (одной только ситуацией с CNNIC выше крыши), то вот понадобились эти сраные костыли в виде HPKP чтобы хоть как-то попытаться сохранить лицо и продолжить доить сайтовладельцев.

HPKP никак не решает проблему Trust on First Use.

Все знают, успокойтесь. Была проблема вообще. Её сократили до first use. Для начала неплохо.

Это костыль

Это не костыль, а начало работ над стандартом. На HPKP дело не кончится.

Т.к. система коммерческих CA полностью скомпроментирована

белки_истерички.jpg. Всё, отключайте tls, скомпрометировано.

продолжить доить сайтовладельцев.

Не доитесь, используйте Let's Encrypt. А деньги будут платить компании, которым нужен сертификат выданный не домену, а конкретной ЗАО/ООО/НКО/ОПГ/etc... А это сейчас всё равно не обеспечить без доверяемого лица. Потому что введение всепланетарного блокчейн-реестра всё равно невозможно вот так в один момент, просто по желанию чьей-то левой пятки.

которая в случае самоподписанных сертификатов вообще не существует

Не вопрос, используйте самоподписанные. :trollface:

Да я вот думал, что серитификаты разумно хранить где-то в /etc/dehydrated/certs/...

Или я не прав и так делать не стоит? У меня помимо www еще nntp есть как минимум, и вроде как в /var/www не очень логично получается сертификаты пихать.