Как написать статью про выдачу квалифицированных сертификатов и ни разу не упомянуть это слово "сертификат" - делится Ведомости и автор мифа про СКЗИ и гостайну, профанатор простой электронной подписи Т-Банк.
Вся процедура занимает в среднем 15–20 минут. Клиент оставляет заявку, представитель банка приезжает по указанному адресу, оформляет все документы и передает готовый токен для работы.
"Готовый токен" - курьер привозит токен с уже записанным ключом ЭП и сертификатом? На каком этапе происходит генерация ключа ЭП и создание сертификата? Сертификат создаётся до идентификации при личном присутствии получателя сертификата или после?
мы предоставляем КЭП бесплатно
- понимает ли автор статьи, что такое вообще КЭП? Есть сомнения. Квалифицированный сертификат ЮЛ/ИП - бесплатный, т.к. в Порядке реализации функций УЦ ФНС России отсутствует пункт о стоимости услуг по выдаче сертификатов и через инспекции и через доверенных лиц.
Продолжаю мониторить деятельность CA/B Forum, пока там идёт дискуссия по бюллетеню SC-103, Let's Encrypt инициирует ещё одно важное голосование - SC-101v2.
Бюллетень конкретизирует алгоритм получения доменного имени авторизации (ADN) из заявленного FQDN (полного доменного имени) при выдаче сертификатов. Текущая формулировка правил допускает опасную лазейку, так как одна из интерпретаций позволяет УЦ "срезать" метки с домена, переходить по CNAME-записям и использовать полученный домен как ADN.
Например: если example.com имеет CNAME на example.org, оператор example.org (например, CDN-провайдер) теоретически может получить сертификат для blog.example.com, не имея фактического контроля над этим поддоменом.
Что предлагается регламентировать в SC-101v2:
🔹ADN выбирается после выбора метода валидации.
🔹Переход по CNAME разрешён только для определённых методов проверки (которые работают напрямую с именем, а не через поддомены).
🔹 Срез доменного имени слева разрешен только для методов, которые сейчас позволяют выдавать сертификаты для доменов, оканчивающихся на тот же суффикс.
🔹Если используются обе операции - сначала CNAME и только потом срезка.
В бюллетень добавлена отдельная дата вступления в силу для раздела 3.2.2.5.3 (до 15 ноября 2026 года), чтобы дать УЦ время подготовиться к изменениям.
Все методы проверки по факту валидируют контроль над ADN, а не над запрошенным FQDN. Это значит, что если два домена сводятся к одному ADN - одного подтверждения контроля достаточно для выдачи обоих сертификатов.
Голосование началось и продлится до 30 июня, на момент написания поста два УЦ уже проголосовали "За".
⚡ УЦ Let's Encrypt отозвал сертификат безопасности Мегафона
Сертификат отозван у домена 4-го уровня cdn2.shop.megafon.ru
Домен: cdn2.shop.megafon.ru
SAN: s93451.cdn.ngenix.net
УЦ: letsencrypt_yr2
Причина: Unspecified
Дата отзыва: 2026-06-23 22:19:03 UTC UTC
Причина - "Unspecified", т.е. не указана. GlobalSign, например, в качестве причины последних отзывов указывает "Privilege Withdrawn" (9), т.е. "привилегии отозваны".
Домен третьего уровня shop.megafon.ru 12.06.2026 получил Wildcard-сертификат сертификат от Let's Encrypt, его судьба пока неизвестна.
Let's Encrypt, как и обещали, вынесли на голосование CA/B Forum требование о закреплении расширения serverAuth EKU в кросс-сертификатах в Базовых требованиях (BR).
Попытка ужесточить требования для кросс-сертификатов сертификатов вызвала дискуссию участников CA/B Forum (кстати, степень открытости обсуждения поражает, это неподкапотное заочное голосование, а открытое обсуждение, нашим до такого далеко).
Обсуждение бюллетеня SC-103 началось 12.06.2026, представленная версия выявила разногласия CA/B Forum.
Предложение Let's Encrypt гармонизировать Базовые требования с политиками программ доверия к корням (Chrome, Mozilla, Apple, Microsoft) получило возражения, связанные с трактовкой правил CCADB и судьбой legacy-корней.
Бюллетень требует, чтобы все кросс-сертификаты обязательно содержали EKU и использовали только строго ограниченный набор OID (в основном id-kp-serverAuth и id-kp-clientAuth), ужесточает текущие правила:
🔹Позиция Let's Encrypt: правило CCADB зависит от того, является ли новый подчинённый УЦ многоцелевым. А все корневые программы уже требуют, чтобы новые SubCA были одноцелевыми, соответственно BR должны просто это зафиксировать.
🔹Контраргумент от УЦ HARICA: CCADB ограничивает новую иерархию, а не выпускающий корень. Для иерархий, не связанных с TLS (например, сертификаты подписи кода), правила CCADB не диктуют конкретные EKU - они лишь запрещают serverAuth, поэтому BR не должны копировать это требование.
Появилась новая проблема legacy-корней и не-TLS сценариев:
🔹Возражение от Sectigo: Предложенная формулировка препятствует legacy-корням выдавать кросс-сертификаты для целей, отличных от TLS, например, для подписания документов. Новый SubCA остаётся одноцелевым, но технически попадает под запрет.
🔹 Let's Encrypt предложили компромисс - они готов добавить OID Document Signing в разрешенный перечень, но предупреждает, что политика CCADB его не разрешает, поэтому участники её программ не смогут этим воспользоваться.
Период обсуждения уже завершился 19 июня, Let's Encrypt должен подготовить вторую версию бюллетеня с учётом замечаний - как минимум добавить Document Signing. Посмотрим, сможет вторая версия найти баланс между унификацией (которую поддерживают Mozilla и Google) и необходимой гибкостью для legacy-корней и не-TLS сценариев (на чём настаивают Sectigo и HARICA). Продолжаем наблюдение.