dxdt.blog: занимательный интернет-журнал

Всё это блокирование выдачи сертификатов TLS и, особенно, отзыв уже выданных, имеет забавный аспект, показывающий, как различные околотехнические рассуждения, – обычно, наивные, – оказываются далеки от технологической реальности и коммерческих интерпретаций “этих интернетов”.

Вообще-то, изначально, в наивной интерпретации, применительно к TLS для веба, единственная фундаментальная роль Удостоверяющего Центра (УЦ) – это подтверждение соответствия открытого ключа сетевому имени (ну или IP-адресу). То есть, УЦ должен убедиться, что заявитель, который запрашивает выпуск сертификата для данного открытого ключа, не только владеет секретным ключом, но и управляет именем, которое просит вписать в сертификат.

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

Только что описанная схема касается DV-сертификатов – сертификатов с проверкой права управления доменным именем (Domain Validation). Заметьте, тут даже не было важно, что заявитель является администратором доменной зоны с точки зрения соответствующего реестра: если проверка происходит при помощи размещения подтверждающего кода, то достаточно иметь возможность размещения кода, чтобы получить сертификат. То есть, для DNS-проверки, DV-сертификаты может выпускать оператор авторитативных серверов имён. Этот момент, исторически, практически никого не смущает: например, крупные провайдеры CDN спокойно себе выпускают TLS-сертификаты для доменов своих клиентов, а клиенты, являющиеся администраторами доменного имени, даже и знать-то об этом не хотят.

И как этот момент технически может быть связан с “санкционным отзывом” сертификата? Да никак – имя из DNS никуда не девается, а подтверждение для имени – точно так же можно получить от заявителя, который запрашивает сертификат, потому что имя в глобальной (пока что) DNS у заявителя никто не отбирает (тоже – пока что).

Формально, DV-сертификаты могли бы сохраняться. Однако вот уже и Let’s Encrypt, – который УЦ для DV-сертификатов, прежде всего, – вносит в правила пользования очень широкие запреты для подсанкционных территорий и организаций: там, как бы, нет запрета на прохождение валидации имени или адреса, но запрещено вообще пользоваться ACME-сервисами для заказа сертификатов, что, понятно, отменяет и валидацию – если она и прошла, то всё равно были нарушены правила предоставления сервиса.

Так что, похоже, имя – ещё не отбирают, а сертификат для имени – уже отбирают. Хотя, технически, DV-валидация – вообще никак не касается административной части. И УЦ, по старой наивной логике, должен бы проверять, что заявитель управляет DNS-зоной, но не более того.

Естественно, на практике – всё давно не так, наивный технический подход не работает. Потому что сертификаты нынче – это не для подтверждения соответствия ключей именам, не для “Зашифрования для всех” (Encryption for Everybody), а для подтверждения возможности доступа – токен для браузеров и других приложений.

Буквально. Насаждаемая наивная трактовка сильно замылила современную роль сертификата; в реальности, браузер спрашивает: “Можно ли подключиться к сайту под данным именем?”, а УЦ, при помощи подписи на сертификате, отвечает: “Да, пока что можно, но уточни ещё статус разрешения позже”. Или, если действующего сертификата с валидной подписью нет, то это означает, что УЦ ответил: “Нет, подключаться не следует”.

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

Это – что касается DV. Но совсем иначе выглядит ситуация с сертификатами, подтверждающими название организации-администратора имени. Это OV-, EV-сертификаты, что называется – “с расширенной проверкой”. Здесь, действительно, в дополнение к технической проверке DNS, должна выполняться административная проверка существования организации, которая запрашивает сертификат. То есть, проверка связи этой организации с парой ключей, подтверждение владения секретным ключом, проверка административного управления доменным именем и, кроме прочего, подлинности желания и возможности для организации выпускать сертификат для данного имени и ключа. Процесс, если его проводить по всем правилам, сильно сложнее, чем DV. Но зато прямо подтверждает существование организации, как административной структуры, и её намерений по выпуску сертификатов.

Понятно, что если выдача TLS-сертификатов веб-узлам – это не про подтверждение соответствия ключей именам в вебе, а про разрешение доступа пользователей, то и нахождение организации в санкционных списках не только подтверждает её существование (сюрприз: таков забавный побочный эффект), но и уверенно блокирует доступ для широкой публики интернет-пользователей, уже без разбора. Такой вот стоп-лист, принятый УЦ, как инструментом выдачи доступов.

Ну а уж стоп-листы есть сейчас самые разные: расставленные по ту и другую сторону, заметные и не очень, применяемые для IP-адресов и для сетевых имён, для протоколов, в разных сетях, на разных уровнях – это, думаю, уже все в интернетах замечают, особенно, когда почти ничего не работает. Что уж тут удивляться про “проверку организации” УЦ. Другое дело, что данный аспект, даже если его трактовать максимально строго, не относится к DV-сертификатам, в которых организаций, – кроме УЦ, – просто нет. Впрочем, эти наивные технические детали сейчас мало кого беспокоят.

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