Hacker News Digest

• Этот домен показывает отозванный сертификат, подписанный корнем ISRG Root X1.
• Увидеть отзыв удаётся не во всех браузерах — проверка отзыва работает по-разному.
• Let's Encrypt — бесплатный удостоверяющий центр; страница создана для демонстрации механизма отзыва.

Как участвовать

• Код ЦС: github.com/letsencrypt/boulder
• Форум: community.letsencrypt.org
• Стать спонсором: letsencrypt.org/become-a-sponsor

• Обсуждается проблема неработоспособности механизмов отзыва сертификатов (revocation) в WebPKI, на примере сайта с отозванным сертификатом, который браузеры не блокируют.
• Пользователи тестируют различные браузеры (Chrome, Firefox, Safari, Edge) и констатируют, что ни один из них не распознает сертификат как отозванный.
• Причины: разные подходы к проверке (OCSP, CRL), отсутствие единого централизованного авторитета по отзыву и то, что многие браузеры вообще не выполняют live-проверки из-за проблем с производительностью и приватностью.
• Отмечается, что индустрия движется в сторону сертификатов с коротким сроком жизни (short-lived), что делает проблему отзова менее актуальной, так как такой сертификат быстро сам истекает.
• Упоминается, что Let's Encrypt прекратил поддержку OCSP и предлагает 6-дневные сертификаты, что еще больше снижает важность механизмов отзыва.

OCSP-сервис Let's Encrypt отключён

С 6 августа 2025 года Let's Encrypt полностью выключил OCSP-ресурдер.
Все выпущенные после марта сертификаты уже не содержали ссылок на OCSP, и старые истекли. Отныне отзывы публикуются только через CRL.

Причины отказа

• Конфиденциальность: OCSP раскрывает посещаемые сайты и IP-адрес запрашивающего.
• Простота: CRL теперь полноценно поддерживаются, а OCSP требовал значительных ресурсов.

Факты

• Пик нагрузки: 340 млрд запросов/мес (~140 000 зап/с).
• CDN предоставлял Akamai безвозмездно последние 10 лет.

Что дальше
Клиенты, требующие проверки отзыва, должны использовать CRL.

• Участники обсуждают отказ от OCSP и переход на CRL: оба механизма называют «костылями» — CRL слишком тяжёлые и медленно обновляются, OCSP требует онлайна и уязвима к MITM/DoS.
• Chrome вообще не проверяет ни OCSP, ни CRL, а пользуется собственным CRLSets-фильтром от Google; большинства пользователей это не знают.
• Проблема OCSP в «fail-open»-режиме: если ответ заблокирован, сертификат считается валидным, что делает систему бесполезной против активной атаки.
• Предложенные замены — stapling и короткоживущие (24-часовые) сертификаты — тоже критикуют: stapling почти никто не делает, а массовый выпуск 24-часовых certs перегрузит CT-логи и превратит любые проблемы валидации в немедленный аутейдж.
• Итог: отзыв по-прежнему нерешённая проблема; сообщество склоняется к «просто живём с короткими сертами» и считает OCSP/CRL устаревшими.

NGINX теперь с ACME
12 авг. NGINX официально добавил встроенный модуль ngx_http_acme (на Rust), который сам получает и продлевает сертификаты Let’s Encrypt.

Зачем

• никаких внешних клиентов;
• работает из коробки: от домашнего лаба до кластеров Kubernetes;
• меньше рутины, больше шифрования.

Кто ещё
Traefik, Caddy, Apache уже умеют; теперь к ним присоединился самый популярный веб-сервер и прокси.

Разработчикам
Протокол ACME, библиотеки и обсуждение — на форуме Let’s Encrypt.

• Кто-то рад встроенному ACME в nginx, кто-то считает, что «сертификат должен получать отдельный клиент», а не каждый сервис в отдельности.
• Спор о безопасности: модуль на Rust, но в нём много unsafe-блоков для взаимодействия с Си-ядром nginx.
• Вопрос «зачем ждать столько лет?» — ответ: корпоративные заказчики F5/medленный релиз-цикл.
• Практика: можно отключить встроенный ACME и продолжать использовать certbot/cert-manager.

Сертификаты для onion-сервисов

Onion-сервисы изначально не нуждаются в TLS-сертификатах, так как Tor уже обеспечивает шифрование и аутентификацию. Однако при доступе через HTTPS-прокси или при желании показать «зелёный замок» можно выпустить сертификат.

Возможные варианты

1. DV от публичного CA

   • Let’s Encrypt, DigiCert и др. поддерживают домены .onion.
   • Потребуется подтвердить владение onion-доменом через ACME (HTTP-01 или DNS-01).

2. Собственный CA

   • Генерируем корневой сертификат и подписываем им конечные.
   • Подходит для внутренних или тестовых сервисов; клиенты должны добавить корень в доверенные.

3. Self-signed

   • Быстро, но вызывает предупреждение браузера.
   • Использовать только для разработки.

Практика с Onionspray

• Встроенный модуль onionspray-cert автоматизирует выпуск Let’s Encrypt.
• Для собственного CA:

  onionspray root-ca init
  onionspray cert issue <onion-address>
  

• Готовые сертификаты складываются в ./certs/.

Проверка

• Публичный DV: открыть onion-сайт в Tor Browser — замок зелёный.
• Свой CA: импортировать rootCA.pem в браузер/ОС.

Кратко

• Для публичных проектов — Let’s Encrypt.
• Для частных — собственный CA.
• Self-signed только для тестов.

• Участники спорят, нужны ли onion-сайтам сертификаты CA, ведь адрес .onion уже криптографически привязан к публичному ключу.
• Основной аргумент «за» — совместимость: браузеры и стандарты (HTTP/2, платежи) требуют TLS-сертификат, чтобы включить расширенные функции.
• RFC 9799 описывает расширения ACME для выдачи таких сертификатов, включая возможность связывать обычные домены и .onion-адреса одним ключом.
• Критики считают это «политическим» требованием: шифрование уже есть, но из-за «TLS повсюду» приходится накладывать лишний слой.
• Практический вывод: для публичных сервисов сертификат нужен, чтобы «вписаться» в экосистему; для приватных каналов достаточно TOFU или ручной проверки.