LINUX.ORG.RU
Форум — Admin  

В феврале Let's Encrypt перейдёт на 64-дневные сертификаты

 


0

1

Некоммерческий удостоверяющий центр Let’s Encrypt, контролируемый сообществом и предоставляющий сертификаты безвозмездно всем желающим, предупредил о сокращении срока действия TLS-сертификатов c 90 до 64 дней. С 10 февраля 2027 года все новые и обновляемые сертификаты будут выдаваться на 64 дня, а выданные до этой даты 90-дневные сертификаты продолжат своё действие. Помимо этого 10 февраля 2027 года с 30 до 10 дней будет сокращён период действия авторизации, т.е. времени после подтверждения своих прав на домен, в течение которого сертификат может быть выдан без прохождения повторных проверок. C 16 февраля 2028 года срок действия сертификатов намерены сократить с 64 до 45 дней, а авторизации - c 10 дней до 7 часов.

Причиной сокращения срока действия сертификатов стали новые требования ассоциации CA/Browser Forum, выработанные в ходе совместной работы производителей браузеров и удостоверяющих центров. Аналогичное сокращение срока действия будет внедрено всеми удостоверяющими центрами. CA/Browser Forum определил конечный срок завершения внедрения мартом 2029 года, а максимальное время действия сертификата - 47 днями. После марта 2029 года обработка в браузерах новых сертификатов, срок действия которых превышает 47 дней, будет приводить к выводу в ошибки «ERR_CERT_VALIDITY_TOO_LONG».

Переход на короткодействующие сертификаты сократит время внедрения новых криптоалгоритмов в случае выявления уязвимостей и помешает злоумышленникам длительное время контролировать трафик жертвы или использовать сертификаты для фишинга в случае утечки сертификата в результате взлома. Более частая проверка владения доменом и сокращение сроков действия сертификатов также уменьшат вероятность того, что сертификат продолжит действовать после потери актуальности содержащейся в нем информации и снизят риск распространения неправильно выпущенных сертификатов.

В феврале Let’s Encrypt перейдёт на 64-дневные сертификаты

Перемещено shell-script из security


Ответ на: комментарий от dynamic_cast

Лучше копипаста чем бредогенератор. Хотя, касательно опеннета, иногда (не тут) возникали подозрения что там он тоже имеет место.

Но лучше конечно самому писать.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)

Я и не знал что там есть какое-то «время авторизации». Проверили домен, выдали сертификат, забыли.

Что касается срока действия, если им хочется чтобы их в 2 (а потом в 3) раза чаще грузили запросами - их дело. А вот то что новые браузеры сертификаты с нормальным сроком перестанут принимать это конечно вредительтсво и наоборот удар по безопасности.

firkax ★★★★★
()
Ответ на: комментарий от bbc69

Обновлять сертификат «раз в сколько-то» это изначально дефективная стратегия. Надо проверять состояние текущего (срок действия, не отозван ли) и пытаться обновлять если осталось меньше чем сколько-то дней.

Впрочем, обновлять раз в сутки это явно большая глупость чем обновлять раз в месяц. Я думал LE банит за такое вообще, но видимо у них более короткий таймаут. И нигде не видел такого.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от ant1

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

Там самое неудобное - это валидация, но это мы автоматизировали, сделав соответствующий сервис: acme.p20.ru (могу предоставить бесплатный доступ).

estic
()
Ответ на: комментарий от bbc69

Например, Certbot по умолчанию раз в два месяца выпускает. Но вполне можно выпускать и раз в 2,5 месяца, например. Когда уменьшат срок действия до полутора месяцев, можно будет выпускать раз в месяц.

estic
()
Ответ на: комментарий от estic

это мы автоматизировали

Открою тебе секрет, это автоматизировано практически с момента появления letsencrypt, и совсем другими людьми. И никаких доп. сервисов (кроме самого LE) для этого не требуется.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Надо проверять состояние текущего (срок действия, не отозван ли) и пытаться обновлять если осталось меньше чем сколько-то дней.

Чтобы проверить состояние текущего, надо «раз в сколько-то» запускать программу, которая проверит.

Собственно, под «Практически все ставят в крон обновлять LE каждую ночь» комментатор выше, скорее всего, подразумевал «Практически все ставят в крон запускать Certbot каждую ночь». А Certbot при запуске проверяет срок действия сертификата, и если срок обновления ещё не наступил, тихо выходит.

Запускать такое раз в сутки вполне нормально.

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

Если так, то да, я тоже проверяю раз в сутки (но не этой блоатварью). Но он мне ответил на моё сообщение про повышение нагрузки на LE - а там речь была именно про перевыпуск.

firkax ★★★★★
()
Ответ на: комментарий от estic

Что значит «устанавливать»? Как минимум правило в nginx-е чтобы он на урл .well-known/acme-challenge правильно ответил, сделать придётся в любом случае. А именно «устанавливать» там особо нечего, просто le-клиент запустить. le-клиент запускать не обязательно на том же сервере, который обслуживает домен, но в любом случае там всё тривиально и места для аж дополнительных сервисов я там не вижу.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Что значит «устанавливать»?

Распространенный вариант, о котором предположительно вы говорили, подразумевает наличие софта на сервере, который будет принимать и сохранять проверочные данные в /.well-known/acme-challenge/. Наш сервис позволяет не устанавливать такой софт на свой сервер, т.е. он берет на себя функции этого софта.

estic
()
Ответ на: комментарий от estic

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

«Софт» может быть где угодно, главное чтобы созданные им файлы могли скачаться через обращение к проверяемому домену, в этом нет никаких высоких технологий и подобного. Крайне желательно (и в этом нет совершенно ничего сложного), чтобы этот «софт» находился под контролем владельца домена (на его железе), потому что в противном случае владелец домена дарит право себя митмить третьим лицам. Собственно, софт для того и нужен, чтобы владелец домена мог подтвердить что запустил его именно он, а не кто-то левый.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

в яндекс браузере нормальная функция пересказа другими словами, пару лет уже пользуюсь

stuzer
() автор топика
Ответ на: комментарий от unDEFER

ИМХО, 30 дней идеально. Достаточно много, чтобы какие-то разовые сбои не мешали, но достаточно мало, чтобы во-первых подолгу не было за злоумышлеником в случае какой-то компрометизации, а во-вторых, чтобы админу заморочиться и таки поставить скрипт, обновляющий серт автоматически. Тут человеческий фактор ведь, когда оно на полгода, условно, работает «ок, сейчас работает, через полгода как обновлять буду, так и автоматику настрою», и так каждый раз. Понятно, что не у всех, но достаточно у многих. Чем оно чаще, тем лучше чтобы просто потратить лишние 3–5 минут здесь и сейчас.

CrX ★★★★★
()
Ответ на: комментарий от firkax

Дело было давно, иду по памяти. Сама по себе идея проверять срок как будто бессмыслена. Ты ведь итак знаешь, когда он закончится. Делается в два раза чаще, чтобы если в первый раз что-то сломалось, сработало во второй раз.

ПС понял, что Вы имели в виду. Что я скажу: не было у нас тогда такого замечательно сотрудника.

bbc69
()
Ответ на: комментарий от firkax

Этим заниамется certbot и обновляет по мере надобности(когда подходит срок сертификата). Что за бред несут два товарища выше, я не знаю.

shell-script ★★★★★
()
Ответ на: комментарий от estic

Никто не заставляет держать certbot непосредственно на сервере. Точнее, даже наоборот. Не нужно ставить его на сервер. Его можно хоть на локалхосте запускать, хоть в виртуалке, хоть в докере. Вы какими-то костылями занимаетесь.

shell-script ★★★★★
()
Ответ на: комментарий от bbc69

Ты ведь итак знаешь, когда он закончится.

Что значит «итак знаешь»? У меня только личных домено штук 20, заведённых в разное время. Я должен помнить дату выпуска сертификата для каждого из них?

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Имеется в виду, черт дается га три месяца. Скрипт отработал, значит черт потухнет через три месяца. Значит следующий можно запустить через это время минус запас.

bbc69
()
Ответ на: комментарий от bbc69

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

Впрочем, обновлять раз в сутки это явно большая глупость чем обновлять раз в месяц. Я думал LE банит за такое вообще, но видимо у них более короткий таймаут. И нигде не видел такого.

Так оно вроде не перевыпускает, а проверяет сколько осталось само и просто закрывает соединение, если серт валиден еще более сколько-то дней. Так что сам ты глупость.

ant1
()
Ответ на: комментарий от firkax

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

Никто не изображает бурную деятельность. Просто удобно и безопасно выполнять валидацию отдельным сервисом для любых серверов. Никто не собирает чужие пароли. Наоборот предоставляется ключ к хранилищу сервиса, чтобы сохранять в нем данные для валидации, например по адресу в ветви //сервис/firkax/[префикс/].

estic
()
Последнее исправление: estic (всего исправлений: 1)
Ответ на: комментарий от shell-script

Никто не заставляет держать certbot непосредственно на сервере. Точнее, даже наоборот. Не нужно ставить его на сервер.

Я об этом и писал. Пусть ACME-клиент работает на каком-нибудь «клиенте», а не на серверах, где «припаркованы» домены.

estic
()
Ответ на: комментарий от shell-script

Никто. Но если вынести ACME-клиент на «клиент», то на сервере все равно обычно оставляют «валидатор». А наш сервис позволяет убрать с сервера и «валидатор». Естественно, тем, кто может организовать свой сервер валидации, наш сервис не нужен.

estic
()
Последнее исправление: estic (всего исправлений: 1)
Ответ на: комментарий от estic

то на сервере все равно обычно оставляют «валидатор».

Нет, никакого валидатора на сервере оставлять не надо. На сервере вообще ничего, связанного с работой certbot'а оставлять не надо. И никакого сервера валидации не нужно. Кто-нибудь вообще документацию к используемому софту читает?

shell-script ★★★★★
()
Последнее исправление: shell-script (всего исправлений: 1)
Ответ на: комментарий от estic

Вот тут ты пишешь

Но если вынести ACME-клиент на «клиент», то на сервере все равно обычно оставляют «валидатор». А наш сервис позволяет убрать с сервера и «валидатор».

А я в надцатый раз повторяю. При работе со штатным certbot, ничего на сервере для валидации оставлять не надо. И запускать клиент для создания/управления сертификатами можно где угодно. И не надо писать никаких велосипедов. Всё работает из коробки через DNS-валидацию.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Всё работает из коробки через DNS-валидацию.

Facepalm. Я писал про HTTP-01. У DNS-01 есть свои минусы. А «персистентная» DNS-валидация пока только в проекте.

estic
()
Ответ на: комментарий от estic

Никто не изображает бурную деятельность

Ты изображаешь.

отдельным сервисом

Смотри, как это происходит в норме:

владелец -> letsencrypt: я владелец домена example.org, могу доказать, дай мне сертификат на это
letsencrypt: смотрит доказательство
letsencrypt -> владелец: вот тебе сертификат

И вот как это предлагаешь сделать ты:

владелец -> ты: я владелец домена example.org, попроси для меня у letsencrypt сертификат, вот тебе доверенность от меня на это действие
ты -> letsencrypt: хочу получить сертификат для домена example.org, его владелец может подтвердить что выдал мне доверенность на это действие
letsencrypt: смотрит доверенность (обращаясь к сайту владельца)
letsecnrypt: смотрит вторую часть доказательства (обращаясь к твоему сайту)
letsecnrypt -> ты: вот тебе сертификат
ты -> владелец: вот тебе сертификат

Теперь объясни, каким боком и кому второй вариант может оказаться удобнее первого?

И скажи, ты правда не понимаешь, или только пытаешься скрыть, что второй сценарий, после выдачи тебе «доверенности», может случиться и без первого и последнего пунктов? (т.е. сертификат ты получаешь по своей инициативе и для себя, чтобы потом митмить тот сайт)

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от ant1

Серверов много. Держать на каждом из них ACME-клиент - усложнение обслуживания. Лучше в одном месте обновлять сертификаты и раскладывать их по серверам.

shell-script ★★★★★
()
Ответ на: комментарий от firkax

И вот как это предлагаешь сделать ты…

Вы придумали сценарий работы нашего сервиса. Пользователь сам выпускает сертификаты. Наш сервис предназначен только для автоматической валидации.

estic
()
Ответ на: комментарий от estic

Что значит автоматической валидации? Где она находится в трёхпунктовом сценарии который имеется в нормальном случае? И каким образом она может быть не автоматической?

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария