Техническое: возможности Let’s Encrypt по блокированию сертификатов

11. June 2026, 17:09 TLS, Безопасность, Интернет

Кстати, в продолжение предыдущей записки про новые санкционные правила Let’s Encrypt. Что и как этот УЦ мог бы сделать для того, чтобы соблюдение правил реализовать технически? Дело в том, что ACME – это автоматический протокол, у него есть особенности (отсутствие строгого подтверждения аккаунта, отсутствие подтверждения заявки пользователем-человеком и т.д.).

Во-первых, понятно, можно сортировать заявки на выпуск сертификатов по именам доменов, отсекая .RU и др. Но это не помагает в других доменных зонах, и не помогает с сертификатами на IP-адреса.

Во-вторых, можно отказывать в заказах, поступающих по ACME со стороны IP-адресов, которые принадлежат “подсанкционным блокам”, например, по автономной системе. Но автономная система для ACME-клиента легко может быть из совсем другой страны. Более того, точность подобной геопривязки вообще не так высока, как считается.

В-третьих, можно было бы отслеживать принадлежность IP-адресов, относящихся к целевым объектам заказа: это адреса авторитативных серверов DNS-зоны, адреса веб-узлов и др. Это несколько лучше предыдущих пунктов, но тоже – так себе точность: всё может быть вынесено на “чужие” IP-префиксы и придётся доказывать, что администратор этих префиксов “знал и способствовал”, чем нарушил правила.

Самый эффективный вариант – использовать все три перечисленных способа сразу. Вот только автоматизируется это довольно плохо. А ACME – автоматический протокол. Хотя, строгая привязка регистраций .RU к ЕСИА тут как раз может быть интерпретирована УЦ так, что имена в зоне – подсанкционны все, поэтому для всех имён и нужно заблочить заказы сертификатов.

Адрес записки: https://dxdt.blog/2026/06/11/18420/

Похожие записки:



Далее - мнения и дискуссии

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

Комментарии читателей блога: 5

  • 1 <t> // 11th June 2026, 19:07 // Читатель Petabyte написал:

    Я тоже думал над технической стороной вопроса. На мой взгляд, массовая реализация таких ограничений через ACME выглядит довольно сложной.

    С блокировкой по доменным зонам прецеденты уже есть: например, ZeroSSL давно не выдаёт сертификаты для .ru и .su. То есть вариант с фильтрацией по TLD вполне реален и технически прост.

    Дальше начинаются проблемы. ACME изначально подтверждает контроль над доменом или IP, но не личность владельца. Поэтому определять, кто именно стоит за конкретным доменом, довольно сложно. RDAP сейчас в большинстве случаев скрыт за Privacy Service, инфраструктура может быть вынесена в другие страны, а ACME-клиент вообще может работать с любой VPS.

    При этом, насколько я смог найти, практика Let’s Encrypt в этой части существует уже давно и не новая. Например, в обсуждении на форуме Let’s Encrypt в 2024 году прямо указывалось, что сертификаты не выдаются субъектам из списка OFAC SDN, а также действуют ограничения для некоторых государственных структур санкционных стран: https://community.letsencrypt.org/t/russia-other-any-restricitons/226348

    Поэтому мне кажется, что новые пункты в соглашении скорее формализуют уже существовавшую практику соблюдения санкционных требований, чем вводят какой-то принципиально новый механизм блокировок. По крайней мере, из комментариев Let’s Encrypt следует, что работа с санкционными субъектами велась и раньше.

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

    ИМХО, для тех, кто действительно находится в санкционных списках и на кого эти ограничения реально распространяются (привет Сбербанк), эта проблема возникла далеко не вчера, а 4 года назад. Такие организации уже тогда были вынуждены искать альтернативы, использовать других УЦ вроде GlobalSign или переходить на “суверенные” сертификаты от Минцифры. Поэтому для пользователей основной вопрос сейчас скорее в том, насколько новые формулировки расширяют существующую практику, а не в самом факте наличия санкционных ограничений.

    Впрочем, вся эта история лишний раз напоминает нам о довольно старом инфраструктурном правиле: не стоит зависеть от одного-единственного УЦ. Не потому что завтра обязательно что-то случится, а потому что понимание доступных альтернатив и возможность относительно быстро переключиться на другой УЦ просто хорошая практика для любой более-менее критичной инфраструктуры.

  • 2 <t> // 11th June 2026, 20:06 // Александр Венедюхин:

    > При этом всё вышесказанное, на мой взгляд, не является аргументом в пользу срочного переезда с одного УЦ на другой.

    Согласен. Они там и так – либо уже заблочили, либо поторопятся следом за LE, как только тот начнёт отключать.

    > использовать других УЦ вроде GlobalSign

    Тоже так себе вариант: эти УЦ либо подтянутся к “общей марке”, то есть, отзовут/заблокируют сертификаты, либо их самих повыкидывают из списка доверенных в браузерах.

  • 3 <t> // 11th June 2026, 23:16 // Читатель Petabyte написал:

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

  • 4 <t> // 13th June 2026, 15:10 // Читатель Petabyte написал:

    В принципе, вот ещё вам в догонку. Для новой заметки

    https://www.rbc.ru/technology_and_media/13/06/2026/6a2d12da9a7947f7d5334aa0

  • 5 <t> // 13th June 2026, 18:42 // Александр Венедюхин:

    Ну, да, GlobalSign так и поступили, предсказуемо.

Написать комментарий

Ваш комментарий:

Введите ключевое слово "423W4" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

Если видите "капчу", то решите её. Это необходимо для отправки комментария ("капча" не применяется для зарегистрированных пользователей). Обычно, комментарии поступают на премодерацию, которая нередко занимает продолжительное время.