Comments 28
Правильно я понимаю, летс энкрипт может расшифровать 30% https трафика в интернете?
Перевыпустив ваш сертификат, да. Справедливости ради, стоит сказать, что по сути тоже самое может сделать любая структура которая имеет корневой сертификат.
Нет, не может — приватный ключ не покидает сервер клиента. Перевыпустить сертификат и сделать затем mitm — да, может. Частично от этого может защитить HPKP и CAA-записи в DNS.
Если во время генерации они сохраняли бы себе приватный ключ — то да, MITM осуществим с использованием оного. Однако в текущей ситуации даже при пере-выпуске сертификата MITM не осуществим до тех пор, пока ваш сайт не начнёт использовать новый сгенерированный сертификат. Корневой же сертификат используется для проверки «кто выдал», но никак не поможет в расшифровке траффика, зашифрованного уже выданным дочерним сертификатом. Поправьте те, кто знает спецификацию сертификации лучше меня.
добавлю ссылку на эту статью, подробно рассказывающую как это работает.
Forward Secrecy для того и придумали, чтобы нет? Если в tls сессии был использован DH, то имея ее полный дамп и закрытый ключ сервера, расшифровать ее не получится.
Возможно не-дилетанты в криптографии меня поправят.
Имел возможность получить опыт настройки сертификата у letsencrypt. Всегда хочется по-быстрому настроить, особенно если доменов несколько, лень ведь читать простыни текста.
Всё просто, скачал бота, поверил большей части настроек. Опа — сертификат готов, всё работает. Через время смотришь лог.
Чтобы настроить, нужно было прочитать все их простыни документации и форумы, общими знаниями не обошлось. После прочтения всё кажется логичным.
Читаешь их форум и 100500 людей наступают на теже самые грабли.
letsencrypt — очень хорошая и правильная инициатива.
Но за бесплатно нужно хорошенько разобраться, как работают механизмы. Лучше всего ещё потестировать весь цикл: сертификаты нагенерировать, отозвать, снова сгенерировать, проверить все логи сервера.
Всё просто, скачал бота, поверил большей части настроек. Опа — сертификат готов, всё работает. Через время смотришь лог.
- Сертификаты не хочет проверять, слишком много доменов за раз.
- Слишком частые запросы делаете, мы вас забанили на пару дней.
- Напортачил с правами, удалил сертификат, неотозвав — у вас много действующих сертификатов, теперь подождите ещё пару дней.
- Домен не проходит валидацию — неправильно настроена папка .well-known/acme-challenge.
- Для acme-challenge нужен порт 80, только 443 не пойдёт.
- Обновил ядро, питон законил и ещё его нужно подкрутить.
Чтобы настроить, нужно было прочитать все их простыни документации и форумы, общими знаниями не обошлось. После прочтения всё кажется логичным.
Читаешь их форум и 100500 людей наступают на теже самые грабли.
letsencrypt — очень хорошая и правильная инициатива.
Но за бесплатно нужно хорошенько разобраться, как работают механизмы. Лучше всего ещё потестировать весь цикл: сертификаты нагенерировать, отозвать, снова сгенерировать, проверить все логи сервера.
Как обычно говорят в таких случаях на Тостере — «наймите админа» :)
Мой ответ двухлетней давности всё ещё актуален и легко делается без docker compose. Сильно удивился, увидев ваш вариант с предложением выпускать сертификаты через certbot-auto (это инсталлятор certbot, если что).
Вы могли не ждать 3 месяца, а сначала оттестировать процесс получения и обновления сертификатов на тестовом эндпоинте, а затем уже переходить на боевой.
Просто пользуйтесь тестовыми серверами во время начальной настройки, там лимиты во много раз выше:
certbot --test-cert.
Лучше использовать acme.sh, и подтверждать через DNS.
Не нужен ни питон, ни 80-й порт, ни .well-known.
Не нужен ни питон, ни 80-й порт, ни .well-known.
Вроде никак. Специально задумано чтобы настраивали автообновление.
Прямо в статье же ссылка есть почему никак.
Интересно, много ли из 100-1000-летних сертификатов не самоподписанные? И кто их выдает?
Если всё настроено хорошо и правильно, то всё работает. Exim + Debian + Cisco ipv6, как перешли, так уже второй год само, даже без вмешательств.
Мне же достался криво настроенный Эксчендж, где обновляться не хотело ни в какую, внезапно, после полугода нормальной работы. Точнее обновилось, потом появилась ошибка — ждите, слишком много повторных запросов. Итогом была: возня в течении двух рабочих дней по 12 часов двух специалистов, простой внешней почты у всей организации всё это время, оплата из своего кармана работы второго специалиста и увольнение с испытательного срока. Купили Эксчендж, а на сертификате сэкономили. Заплатил бы столько-же денег из своих за платный сертификат, возможно работал бы дальше у них.
Мне же достался криво настроенный Эксчендж, где обновляться не хотело ни в какую, внезапно, после полугода нормальной работы. Точнее обновилось, потом появилась ошибка — ждите, слишком много повторных запросов. Итогом была: возня в течении двух рабочих дней по 12 часов двух специалистов, простой внешней почты у всей организации всё это время, оплата из своего кармана работы второго специалиста и увольнение с испытательного срока. Купили Эксчендж, а на сертификате сэкономили. Заплатил бы столько-же денег из своих за платный сертификат, возможно работал бы дальше у них.
Так может не в letsencrypt или платности дело, а в том, что серитфикат пошли обновлять сразу перед/после его истечения? Почему с платным было бы по другому? Тот же letsencrypt рекомендует обновлять сертификат за месяц, и в этом случае у вас есть месяц на решение возможных проблем.
Дело в том что он и обновился заранее. Но в итоге с новым сертификатом потребовалась работа полностью по ipv6 и обнаружилось это тогда когда старый истёк, а новый отказался работать. Разумеется, генерация нового сертификата ругалась что он уже выполнен. А по коду ошибок на форумах было несколько решений, которые надо было попробовать последовательно пока не выяснится в чём-же дело. У продавцов платных решений на этот счёт есть как минимум техподдержка и ответственность. В частности потеря времени на перебор и поиск решения заняла фатальное (для меня) время, в то время как правило о том что работать будет всё это только по ipv6 инициировала Letsencrypt. Возможно моему предшественнику приходили какие-то сообщения, но он о них умолчал или забыл/забил. А я ранее не сталкивался т.к. на прежнем месте всё по умолчанию было настроено через ipv6 и данная проблема не имела прецедента.
С другой стороны может даже лучше что сразу увольнение, чем мучаться с таким отношением и влетететь позже но на более большой проблеме.
В данном случае справедливо. Но только в организациях, где всё настроено не ванильно-красиво, по канонам, замечаешь массу подводных камней, которые идут в копилку опыта.
Вопрос не про то как как оно настроено, а в отношении руководства к остановкам по задачам. Если образовалась проблема, то нужно определить по чьей вине. Ошибки админа или ошибки кривого софта — это разные вещи. За второе админ не отвечает, не он писал этот софт. Ошибки админа — тоже допускаю, но если ему не была выдана подробная инструкция «как это делать» — то какой смысл с него спрашивать правильное выполнение и увольнять за неправильное? В РФ часто забивают болт на инструкции и обучение сотрудника, но при этом требуют чтобы знал и умел, в противном случае угрозы увольнения.
Sign up to leave a comment.
Let's Encrypt обслуживает почти 30% доменов