Кратко

  • 21 апреля 2026 года Geoff Huston отозвал тестовый сертификат Let’s Encrypt и проверил его серийный номер в списке отзыва издателя. Через 48 часов проверенные им версии трех браузеров всё еще принимали соединение.
  • В более позднем выступлении на APNIC 62 Firefox отклонил тот же сертификат спустя несколько недель, а Chrome и Safari по-прежнему принимали его в опыте Huston. Задержка между записью и исполнением отзыва стала главным результатом.

Сертификат числился отозванным, но у двери браузера предъявлял почти безупречный пропуск. Geoff Huston выпустил тестовый сертификат Let’s Encrypt, а через четыре часа, 21 апреля 2026 года, отозвал его. Серийный номер нашёлся в списке отзыва удостоверяющего центра. Запись была на месте. Оставалось выяснить, превратится ли она в отказ при следующем TLS-соединении.

В личном отчёте на сайте APNIC Huston указал версии: Firefox 148.0.2, Chrome 147.0.7727.117 и Safari 25.4 приняли соединение спустя 48 часов. Один сертификат в конкретной проверке не даёт вечного приговора всем браузерам. Зато он ясно показывает разрыв полномочий. Центр может опубликовать новый статус, а решение о доверии данному ключу принимает программа пользователя. Строка в списке не прерывает сеанс сама собой.

Когда Huston вернулся к опыту позже, ответ изменился лишь частично. На слайдах APNIC 62 он сообщил: спустя пару недель Firefox уже отклонял сертификат, тогда как Chrome и Safari в его проверке продолжали принимать его. Апрельская статья и сентябрьское выступление описывают разные моменты наблюдения. Их следует читать вместе, потому что именно интервал между ними показывает цену слова «отозван». Для издателя оно было истинным; для части клиентов соединение оставалось допустимым.

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

Сократить срок действия выглядит проще. Huston проходит путь от 90 дней к 45 и шести: окно риска уменьшается, но компрометация в первый день всё равно требует досрочной остановки. Сертификаты сроком на часы создали бы совсем другую нагрузку на выдачу и обновление. Поэтому в конце выступления он предлагает хранить сведения о ключе службы в DNS, защищать их DNSSEC и ограничивать давность ответа коротким TTL; цепочку проверки можно было бы передавать вместе с TLS-соединением. DANE здесь его архитектурное предложение, а не уже сложившаяся практика всего Web. Главный вопрос звучит без аббревиатур: насколько старым может быть ответ «этому ключу можно доверять» в момент входа?