Выписки из ЕГРЮЛ и проверка КЭП
Сервис проверки квалифицированной электронной подписи от Головного УЦ снова проверяет действительность КЭП выписок из ЕГРЮЛ.
Более года выписки ЕГРЮЛ не проходили проверку, так как были сформированы в устаревшем формате - PKCS#7, сейчас формат стал CAdES-BES (да, пока без метки доверенного времени) и проверки проходят успешно:
Возможно драйвером для доработки стало решение Якутского УФАС, которое касалось проверки электронной подписи выписки из ЕГРЮЛ.
Сам сервис проверки ГУЦ также был доработан и при проверке мартовских выписок со старым форматом теперь сообщает:
Ранее сообщение выглядело как:
✍️ "Об ЭП и УЦ"
Сервис проверки квалифицированной электронной подписи от Головного УЦ снова проверяет действительность КЭП выписок из ЕГРЮЛ.
Более года выписки ЕГРЮЛ не проходили проверку, так как были сформированы в устаревшем формате - PKCS#7, сейчас формат стал CAdES-BES (да, пока без метки доверенного времени) и проверки проходят успешно:
Электронная подпись верна (CAdES-BES)
Возможно драйвером для доработки стало решение Якутского УФАС, которое касалось проверки электронной подписи выписки из ЕГРЮЛ.
Сам сервис проверки ГУЦ также был доработан и при проверке мартовских выписок со старым форматом теперь сообщает:
Электронная подпись неверна
Подписанных атрибутов в CMS нет - считаем это ошибкой
Ранее сообщение выглядело как:
Эта подпись не CAdES (id_aa_signingCertificate или id_aa_signingCertificateV2 - отсутствуют)
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Яндекс Банк не умеет проверять PKCS#7
Читаем свежий отзыв на банки.ру:
Что же могло пойти не так, ведь для создания автоподписи для выписок ЕГРЮЛ и для выписок из сервиса "Мой налог" используется один и тот же ключ с сертификатом от 05.03.2025 (истекает 29.05.2026).
Ответ простой - ЕГРЮЛ под CAdES доработали, а сервис "Мой налог" нет, поэтому при проверке сформированных документов с использованием ГУЦ получаем ответ:
✍️ "Об ЭП и УЦ"
Читаем свежий отзыв на банки.ру:
Сегодня 07.05.2026 в ходе переписки на эл. почте со специалистом поддержки, банк запросил справку о доходе 2-ндфл (3-ндфл) для проверки возможности оформления кредитных каникул. По скольку я как физ. лицо являюсь официально самозанятым, отправил автоматически формируемые справки из приложения ФНС "Мой налог" о постановке на учёт, о доходах за 2025 и 2026 годы. На что получил ответ: "Банком вам отказано в предоставлении кредитных каникул, поскольку ваши документы не прошли проверку. При проверке электронной подписи выявили, что она является недействительной на всех документах".
Что же могло пойти не так, ведь для создания автоподписи для выписок ЕГРЮЛ и для выписок из сервиса "Мой налог" используется один и тот же ключ с сертификатом от 05.03.2025 (истекает 29.05.2026).
Ответ простой - ЕГРЮЛ под CAdES доработали, а сервис "Мой налог" нет, поэтому при проверке сформированных документов с использованием ГУЦ получаем ответ:
Электронная подпись неверна. Подписанных атрибутов в CMS нет - считаем это ошибкойСможет ли Яндекс Банк разобраться в этом вопросе? Ранее сам Яндекс не смог проверить КЭП и был оштрафован, да и компетенция их публичных спикеров по вопросам электронной подписи оставляет желать лучшего.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❌Взлом Госуслуг - причины, последствия и что делать
Довольно часто такие вопросы появляются в сети. Взломали Госуслуги - потому что сами и сообщили код из смс. Тотальное непонимание населением технологии электронной подписи, поэтому и получаем вопросы "прислали ген доверенность с моей электронной подписью" - её там нет, а есть только картинка, при этом нотариус Петровский ранее уже "засветился в подделке доверенностей".
Что в первую очередь нужно сделать:
🔹восстановить доступ к Госуслугам, например, через приложение Сбербанк Онлайн - Все сервисы - Госуслуги - Восстановить.
🔹сменить пароль доступа и проверить последние операции.
Что не нужно делать - спрашивать так называемых юристов, которые советуют бежать к нотариусам и "блокировать электронную подпись", в схеме мошенничества не задействованы ни нотариус, ни электронная подпись.
Взломанные Госуслуги - это уже вторая фазы атаки в многоуровневой схеме мошенничества, поэтому важно не поддаваться эмоциям и прекратить любые контакты с мошенниками.
✍️ "Об ЭП и УЦ"
меня взломали мошенники, выгрузили мои данные с госуслуг, прислали ген доверенность с моей электронной подписью, заверил нотариус Петровский И.В, подскажите надо ли идти к нотариусу теперь
Довольно часто такие вопросы появляются в сети. Взломали Госуслуги - потому что сами и сообщили код из смс. Тотальное непонимание населением технологии электронной подписи, поэтому и получаем вопросы "прислали ген доверенность с моей электронной подписью" - её там нет, а есть только картинка, при этом нотариус Петровский ранее уже "засветился в подделке доверенностей".
Что в первую очередь нужно сделать:
🔹восстановить доступ к Госуслугам, например, через приложение Сбербанк Онлайн - Все сервисы - Госуслуги - Восстановить.
🔹сменить пароль доступа и проверить последние операции.
Что не нужно делать - спрашивать так называемых юристов, которые советуют бежать к нотариусам и "блокировать электронную подпись", в схеме мошенничества не задействованы ни нотариус, ни электронная подпись.
Взломанные Госуслуги - это уже вторая фазы атаки в многоуровневой схеме мошенничества, поэтому важно не поддаваться эмоциям и прекратить любые контакты с мошенниками.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🚨 Let's Encrypt: инцидент с кросс-сертификатами Gen Y
На прошлой неделе Let's Encrypt пришлось экстренно приостанавливать выдачу сертификатов. Причина - ошибка конфигурации кросс-сертификатов, связывающих новые корневые сертификаты поколения Gen Y с действующими корневыми X1 и X2.
🔹8 мая 2026 года Let's Encrypt опубликовал предварительный отчет об инциденте. В нарушение политики CCADB, вступившей в силу 15.06.2025, ни один из кросс-сертификатов (1, 2), созданных 03.09.2025, не содержит расширения Extended Key Usage с критически важным значением serverAuth, предназначенным для TLS.
🔹проблема была обнаружена сторонними исследователями 08.05.2026. Let's Encrypt немедленно останавливает выдачу новых сертификатов, спустя примерно 2,5 часа изменил конфигурацию, временно переведя выдачу на иерархию Gen X, и возобновил выдачу сертификатов в штатном режиме.
❌ Под вопросом валидность конечных сертификатов. Сейчас в сообществе (ветка на Bugzilla) разгорается дискуссия: представители сообщества настаивают, что проблема серьезнее, чем просто "неправильные промежуточные сертификаты". Аргумент следующий: если выпущенные кросс-сертификаты технически не совпадают с профилем, описанным в CPS Let's Encrypt (там прямо прописано наличие serverAuth EKU), то и все конечные сертификаты (LEAF) этой иерархии, выданы с нарушением регламента (CP/CPS). А это триггер для раздела 4.9.1.1(12) Базовых требований (BR), который обязывает УЦ отозвать такие конечные сертификаты.
🔹Let's Encrypt признал инцидент и готовят полный отчет в течение недели. Но пока нет ответа на вопрос, коснется ли отзыв конечных пользовательских сертификатов. Если ответ будет положительным и потребуется массовая смена, то это может стать самым масштабным инцидентом в мировом PKI.
Let's Encrypt - лидер по объему выданных сертификатов безопасности для сайтов Рунета, более 85% по итогам 2025 года.
P.S. В комментариях упоминается вторая ошибка: поле Organization в Subject содержит не эталонное для LE значение "Let's Encrypt", что является дополнительным нарушением CPS.
✍️ "Об ЭП и УЦ"
На прошлой неделе Let's Encrypt пришлось экстренно приостанавливать выдачу сертификатов. Причина - ошибка конфигурации кросс-сертификатов, связывающих новые корневые сертификаты поколения Gen Y с действующими корневыми X1 и X2.
🔹8 мая 2026 года Let's Encrypt опубликовал предварительный отчет об инциденте. В нарушение политики CCADB, вступившей в силу 15.06.2025, ни один из кросс-сертификатов (1, 2), созданных 03.09.2025, не содержит расширения Extended Key Usage с критически важным значением serverAuth, предназначенным для TLS.
Gen Y - новое поколение корневых и промежуточных сертификатов Let's Encrypt. Чтобы старые устройства доверяли этим сертификатам, используется кросс-сертификация: корневой сертификат Gen Y (YE или YR) подписывается действующим старым корнем (X1 или X2), который уже есть в хранилищах ОС. Без serverAuth EKU такая кросс-подпись технически не предназначена для аутентификации веб-серверов, поэтому это прямое нарушение отраслевых требований.
🔹проблема была обнаружена сторонними исследователями 08.05.2026. Let's Encrypt немедленно останавливает выдачу новых сертификатов, спустя примерно 2,5 часа изменил конфигурацию, временно переведя выдачу на иерархию Gen X, и возобновил выдачу сертификатов в штатном режиме.
🔹Let's Encrypt признал инцидент и готовят полный отчет в течение недели. Но пока нет ответа на вопрос, коснется ли отзыв конечных пользовательских сертификатов. Если ответ будет положительным и потребуется массовая смена, то это может стать самым масштабным инцидентом в мировом PKI.
Let's Encrypt - лидер по объему выданных сертификатов безопасности для сайтов Рунета, более 85% по итогам 2025 года.
P.S. В комментариях упоминается вторая ошибка: поле Organization в Subject содержит не эталонное для LE значение "Let's Encrypt", что является дополнительным нарушением CPS.
Please open Telegram to view this post
VIEW IN TELEGRAM
Об ЭП и УЦ
🚨 Let's Encrypt: инцидент с кросс-сертификатами Gen Y На прошлой неделе Let's Encrypt пришлось экстренно приостанавливать выдачу сертификатов. Причина - ошибка конфигурации кросс-сертификатов, связывающих новые корневые сертификаты поколения Gen Y с действующими…
Час назад представитель Let's Encrypt Аарон Гейбл сообщил, что сертификаты пользователей не были выданы ошибочно, их не будут отзывать в рамках реагирования на данный инцидент. Let's Encrypt предоставит полные ответы на вопросы одновременно с публикацией полного отчета об инциденте.
Давайте подумаем, почему это произошло, почему в кросс-сертификатах Gen Y, созданных 03.09.2025, расширение отсутствовало.
Чтобы понять причину нужно разделять:
🔹промежуточные сертификаты Gen Y - непосредственно участвуют в выдаче TLS-сертификатов для сайтов. У них в EKU корректно указан только serverAuth. Именно это позволило запустить профиль tlsserver без clientAuth.
🔹кросс-сертификаты - сертификаты совместимости, созданы подписанием публичного ключа нового корня Gen Y старым корнем. Именно в них расширение EKU ошибочно отсутствовало.
Кажется, что ошибка выглядит как сбой валидации профиля: проверялось отсутствие "лишнего" (clientAuth), но не проконтролировали обязательное наличие "нужного" (serverAuth). С точки зрения логики Gen Y курс на "очистку" EKU соблюден, а с точки зрения CCADB - критическое нарушение.
Из-за этого инцидента были отложены три важных обновления, запланированных на 13 мая:
🔹сокращение срока действия сертификатов для профиля tlsserver с 90 до 45 дней.
🔹прекращение поддержки профиля tlsclient с 8 июля 2026 года.
🔹перевод профиля classic на использование промежуточных сертификатов Gen Y.
Соответствующий комментарий
The switch to Generation Y intermediaries announced here will be delayed.
появился в ветке обсуждения на community.letsencrypt.org.
Ошибку обнаружили эксперты из организаций Mozilla, DigiCert, Sectigo, которые участвуют в разработке и развитии стандартов WebPKI.
Отдельно отмечу, как оперативно сотрудники Let's Encrypt сработали по внешнему сигналу, получив информацию немедленно отреагировали - остановили выдачу, подтвердили проблему и опубликовали предварительный отчёт. Вот бы ответственные лица за Головной УЦ также быстро бы реагировали.
Please open Telegram to view this post
VIEW IN TELEGRAM
1