СОС корневого удостоверяющего центра — это список отозванных сертификатов (CRL), который корневой УЦ издаёт на подчинённые ему промежуточные центры, и у этого файла есть поле nextUpdate, после которого список считается просроченным. Когда СОС истёк, ломается не подпись и не сертификат, а проверка статуса отзыва: цепочка Минцифры — УЦ — пользователь перестаёт достраиваться, и приложение возвращает ошибку вида 0x80092013 или сообщение о том, что статус отзыва проверить не удалось. Лечится это скачиванием актуального файла .crl по адресу из поля CRL Distribution Points, установкой его в хранилище «Промежуточные центры сертификации» и очисткой кэша. Главное различие: при просроченном СОС документ проходит проверку сразу после обновления списка, а при реально отозванном сертификате обновление ничего не изменит — подпись останется недействительной.
Дальше разберём, как отличить просроченный СОС от отозванного сертификата и от разорванной цепочки доверия, что означает каждый код ошибки и в каком порядке чинить рабочее место и сервер. Отдельно — что делать с документами, которые уже подписаны и лежат в архиве, и почему штамп времени снимает этот вопрос на годы вперёд. Таблица кодов ошибок, пошаговое обновление списка отзыва на Windows и Linux, образцы протокола проверки и письма контрагенту, тарифы на 2026 год и ответы на частые вопросы — во второй половине статьи.
Что такое СОС корневого УЦ и почему его просрочка останавливает проверку
Список отозванных сертификатов — это подписанный удостоверяющим центром файл, в котором перечислены серийные номера сертификатов, аннулированных досрочно, до окончания их срока действия. Внутри файла два ключевых поля: thisUpdate (когда список издан) и nextUpdate (до какого момента он считается актуальным). После nextUpdate список не становится «неправильным», он становится устаревшим: программа больше не может утверждать, что за прошедшее время интересующий её сертификат не отозвали.
Корневой УЦ подписывает не только сертификаты, но и списки отзыва на своих подчинённых. В российской инфраструктуре типовая цепочка выглядит как Минцифры России — удостоверяющий центр — сертификат пользователя. Собственный сертификат корневого центра самоподписан, его статус отзыва не проверяется в принципе: проверять некому. А вот сертификат промежуточного УЦ проверяется по СОС, изданному корнем. Просрочился этот СОС — и промежуточный сертификат повисает в статусе «статус отзыва неизвестен», а вместе с ним и любой пользовательский сертификат, выданный этим УЦ.
Отсюда типовая картина инцидента: подписи, которые вчера проверялись, сегодня перестали, при этом ни один сертификат не менялся, срок действия у всех в порядке, файлы не повреждены. Проверка ломается не на криптографии, а на политике доверия.
Факт: сертификаты соответствия на релизы КриптоПро CSP 5.0 R1, 5.0 R2 и 5.0 R3 действуют до 1 мая 2027 года, а сертификат на версию 4.0 был заявлен до 15 января 2026 года. Версия криптопровайдера определяет, какие носители и алгоритмы вообще доступны рабочему месту.
Ещё одна причина, по которой инцидент выглядит внезапным: рабочая станция кэширует скачанные списки отзыва. Пока кэшированный СОС жив, обращений к точке распространения нет, и недоступность адреса CDP никак себя не проявляет. Проблема всплывает ровно в момент, когда истекает кэш, а новый файл скачать не получается — из-за прокси, фильтрации исходящего трафика по HTTP, закрытого порта или изменившегося адреса публикации.
Диагностика: отличить просроченный СОС от отозванного сертификата
Первое действие — не переустанавливать криптопровайдер, а прочитать код ошибки. Коды у CryptoAPI и КриптоПро общие, и они однозначно разделяют четыре разных инцидента, которые внешне выглядят одинаково: «подпись недействительна».
| Код | Что говорит система | Что это значит на практике |
|---|---|---|
| 0x80092013 | Сервер отзыва сертификатов недоступен | Кэш СОС истёк, новый файл не скачивается. Смотреть сеть, прокси и адрес CDP |
| 0x80092012 | Не удалось проверить отзыв для сертификата | Данных о статусе нет вообще: СОС не установлен либо в сертификате нет точки распространения |
| 0x80092010 | Сертификат отозван | Сертификат есть в актуальном списке. Обновление СОС положение не исправит |
| 0x800B010A | Цепочка до доверенного корневого центра не строится | Не установлен корневой или промежуточный сертификат, либо они лежат не в тех хранилищах |
| 0x800B0101 | Сертификат вне срока действия | Истёк сам сертификат, а не список отзыва. Нужен перевыпуск, а не обновление СОС |
Разделение по кодам экономит основное время инцидента: 0x80092013 и 0x80092012 закрываются администратором за несколько минут, 0x80092010 не закрывается вовсе и требует перевыпуска подписи, а 0x800B010A почти всегда означает ошибку установки сертификатов в хранилища.
Второй шаг — открыть сам сертификат и посмотреть вкладку с путём сертификации. Корректная цепочка выглядит как «Минцифры — удостоверяющий центр — пользователь». Там же, в составе сертификата, лежит поле «Точки распространения списков отзыва» с конкретным адресом .crl и, если УЦ его поддерживает, адрес службы актуальных статусов OCSP. Эти два адреса — и есть то, куда рабочее место ходит за статусом.
Проверьте файл подписи отдельно от своего рабочего места
Пока идёт разбор с локальными хранилищами, полезно получить независимый результат по тому же файлу: если внешняя проверка показывает действующий сертификат и корректный статус, проблема в рабочей станции, а не в документе.
Добыто · Проверка подписи
Что за файл пришёл с документом
Пожалуйста, подпишитесь на нас в мессенджерах
Канал для кадровиков и HR: изменения в законах, практика проверок, шаблоны документов, инструменты подбора и оценки.
Загрузите файл — определим по расширению и содержимому: присоединённая это подпись или откреплённая, чем открыть и куда идти дальше. Архивы раскрываем и смотрим, что внутри.
Файл остаётся на вашем устройстве — мы его не получаем и не хранимНет файла под рукой? Выберите расширение вручную:
Мы не храним ваши файлы и не имеем к ним доступа. Файл читается только в памяти вашего браузера, на сервер Добыто он не передаётся, копий не остаётся. Закройте страницу — и от файла не останется следов.
В практике Добыто разбор такого обращения начинается с одного вопроса: воспроизводится ли ошибка на другой машине с тем же файлом. Если воспроизводится, причина в сертификатах или в сети, если нет — в состоянии конкретной станции и её кэша. Этот шаг отсекает половину гипотез до того, как кто-то откроет настройки криптопровайдера.
Важный нюанс из практики: корневой сертификат Минцифры России и сертификат УЦ ФНС России устанавливаются в разные хранилища — первый в «Доверенные корневые центры сертификации», второй в «Промежуточные центры сертификации». Оба файла публикуются на странице корневых сертификатов УЦ ФНС в виде guc_22.cert и CA_FNS_Russia_2022_01.cert. Установка обоих в одно хранилище даёт ровно ту же ошибку построения цепочки, что и просроченный СОС, поэтому порядок установки проверяется до того, как начинается поиск сетевых причин.
Как обновить СОС корневого УЦ: порядок действий
Списки отзыва всегда устанавливаются в системное хранилище «Промежуточные центры сертификации»: инфраструктура открытых ключей работает с СОС именно оттуда. Установка в «Доверенные корневые» или в личное хранилище результата не даст, хотя импорт формально пройдёт без ошибок.
Как обновить список отзыва: пошаговая инструкция
- Шаг 1. Откройте проблемный сертификат, вкладка «Состав», поле «Точки распространения списков отзыва». Скопируйте адрес, который заканчивается на .crl. Если точек несколько, берите все: УЦ часто публикует зеркала.
- Шаг 2. Скачайте файл по адресу вручную, браузером или curl. Если файл не отдаётся, причина инцидента сетевая: фильтрация исходящего HTTP, прокси без исключения для CDP, закрытый порт. Дальше чинить нужно сеть, а не криптографию.
- Шаг 3. Откройте скачанный .crl и посмотрите поля «Действует с» и «Следующее обновление». Если nextUpdate у свежего файла всё ещё в прошлом, УЦ не опубликовал новый список, и вопрос решается только через его техподдержку.
- Шаг 4. Установите список: контекстное меню файла, пункт установки списка отзыва, целевое хранилище — «Промежуточные центры сертификации». На Linux с КриптоПро CSP то же самое делает утилита certmgr из каталога /opt/cprocsp/bin в режиме -inst с ключом -crl.
- Шаг 5. Очистите кэш загруженных списков: certutil -urlcache crl delete. Пока в кэше лежит старый файл, приложение будет опираться на него, а не на только что установленный.
- Шаг 6. Перезапустите приложение, которое проверяет подпись, и повторите проверку. Часть кэша живёт в памяти процесса, и без перезапуска результат не изменится.
- Шаг 7. Запишите дату nextUpdate нового файла в реестр сертификатов и поставьте напоминание за неделю до неё. Это единственный шаг, который превращает разовый ремонт в профилактику.
Лайфхак: для проверки электронной подписи КриптоАРМ ГОСТ не требует установки лицензии — программу можно поставить и использовать в режиме проверки. Удобно, когда нужен второй независимый результат по спорному файлу.
Пожалуйста, подпишитесь на нас в мессенджерах
Канал для кадровиков и HR: изменения в законах, практика проверок, шаблоны документов, инструменты подбора и оценки.
Про адреса публикации есть деталь, которая экономит время: сведения об аккредитованных удостоверяющих центрах и сертификаты головного удостоверяющего центра публикуются на портале уполномоченного федерального органа в области электронной подписи. Там же проверяется, действует ли аккредитация того УЦ, который выдал сертификат: если центр прекратил деятельность, обновление СОС не поможет и вопрос переходит в плоскость перевыпуска подписи.
Мария Ж, специалист по цифровой подписи и КЭДО: «Мы сначала проверяем не сеть, а хранилища. Корневой сертификат Минцифры должен лежать в доверенных корневых, сертификат выдавшего УЦ — в промежуточных, туда же ставится список отзыва. Заметная часть обращений закрывается именно перекладыванием сертификатов по правильным хранилищам, и сетевые правила при этом ни при чём.»
Когда обновление СОС не помогает
Обновление списка закрывает только один сценарий: статус отзыва неизвестен, потому что данные устарели. Ситуации, в которых этот путь бесполезен, стоит отсечь заранее.
- Сертификат действительно отозван. Код 0x80092010, в свежем списке есть его серийный номер. Дальше только перевыпуск, а документы, подписанные после даты отзыва, придётся переподписывать.
- Истёк сам сертификат подписи. Код 0x800B0101. Список отзыва тут ни при чём, вопрос решается выпуском нового сертификата.
- УЦ прекратил аккредитацию. Центр больше не публикует актуальные списки, и восстановить проверку локальными действиями невозможно.
- Проверка идёт на чужой стороне. Если подпись не принимает портал или площадка контрагента, ваши локальные хранилища на результат не влияют: обновлять СОС нужно там, где выполняется проверка.
- В сертификате нет точки распространения. Такое встречается у тестовых сертификатов. Проверять статус отзыва просто нечем, и в продуктивном контуре такой сертификат использовать нельзя.
Отдельный сценарий — когда чинить вообще не нужно. Если задача разовая и вам требуется убедиться в действительности одной конкретной подписи, поднимать инфраструктуру ради этого нецелесообразно: достаточно проверить документ во внешнем сервисе, где статус отзыва проверяется на стороне сервиса. Полноценный разбор с хранилищами и кэшем нужен там, где проверка встроена в процесс: приёмка документов, шлюз ЭДО, автоматическая проверка входящих файлов.
Как разные контуры реагируют на просроченный СОС
Поведение зависит от того, где именно выполняется проверка и есть ли у подписи собственные доказательства момента подписания.
| Контур проверки | Что происходит при просроченном СОС | Где чинить |
|---|---|---|
| Рабочее место с КриптоПро CSP | Ошибка статуса отзыва у конкретного пользователя, у соседа всё работает, пока жив его кэш | Хранилища и кэш на этой станции |
| Сервер автоматической проверки входящих | Пакетная проверка отбраковывает поток целиком, в отчётах о проверке массовая ошибка одного типа | Хранилища сервера, затем перепроверка пачки |
| Портал или площадка контрагента | Отказ приёма документа без деталей ошибки | На стороне владельца площадки |
| Архив с подписями CAdES-BES | Проверка опирается на внешние данные, поэтому зависит от доступности СОС в момент проверки | Обновление СОС, затем усовершенствование подписей |
| Архив с подписями CAdES-X Long или CAdES-A | Штамп времени и ответ OCSP вшиты в подпись, внешние обращения для оценки момента подписания не нужны | Чинить нечего, работает как есть |
Последние две строки объясняют, почему один и тот же инцидент в одной компании останавливает приёмку документов, а в другой проходит незамеченным: разница не в криптопровайдере, а в формате подписи, выбранном при внедрении.
Что делать с документами, которые уже подписаны
Юридическая сторона вопроса устроена не так, как техническая. По статье 11 Федерального закона от 06.04.2011 № 63-ФЗ «Об электронной подписи» квалифицированный сертификат должен быть действителен на момент подписания документа при наличии достоверной информации об этом моменте, либо на день проверки действительности сертификата, если момент подписания не определён. Отсюда практический вывод: если у подписи нет доказательства момента подписания, её судьба каждый раз зависит от того, что покажет проверка сегодня.
Достоверную информацию о моменте подписания даёт штамп времени от службы TSP. Подпись со штампом — это формат CAdES-T. Если к ней добавить ответ службы OCSP о статусе сертификата на момент создания подписи, получается CAdES-X Long Type 1, а архивная метка поверх них даёт CAdES-A с периодическим переподписанием. Эти доказательства позволяют проверять подпись после того, как срок действия сертификата истёк.
Полезно знать: сертификаты электронной подписи сейчас выдаются не только на короткий срок, но и на периоды до 12 лет, тогда как кадровые и финансовые документы хранятся до 50 лет и дольше. Разрыв между сроком жизни сертификата и сроком хранения закрывается усовершенствованными форматами подписи, а не продлением сертификата.
Мария Ж, юрист со стажем более 20 лет: «Инцидент с просроченным списком отзыва обычно вскрывает не сетевую проблему, а решение, принятое при внедрении: документы подписали базовым форматом и отправили в архив. Пока сертификаты живы и УЦ публикует списки, это незаметно. Посмотрите, какой формат подписи стоит по умолчанию в вашей системе, и, если это вариант без штампа времени, планируйте усовершенствование архива, а не разовое обновление СОС.»
Практическая часть работы с уже подписанным массивом сводится к трём действиям. Первое: сформировать протокол проверки по каждому спорному документу и сохранить его, это фиксация результата на конкретную дату. Второе: усовершенствовать подписи в архиве до формата со штампом времени, чтобы вопрос не возвращался. Третье: по документам, где переподписание невозможно, оформить письмо контрагенту о переподписании или акт о невозможности переподписания.
Важный нюанс из практики: в сервисах автоматической проверки подписи результаты сохраняются не только в базе, но и отдельным отчётом в формате PDF. Когда СОС корневого УЦ просрочен, такие отчёты становятся доказательством того, что до инцидента документы проверялись успешно. Там, где протоколы не сохранялись, картину восстанавливают по логам, и разбор растягивается с часов на дни.
Образцы документов для разбора инцидента с подписью
Комплект собран под сценарий «подпись перестала проверяться»: начинать стоит с чек-листа диагностики, протокол и письма нужны, когда результат проверки требуется зафиксировать письменно.
| Документ | Скачать |
|---|---|
| Чек-лист диагностики «Подпись не валидна» | Скачать |
| Протокол проверки электронной подписи (образец) | Скачать |
| Письмо контрагенту о переподписании (образец) | Скачать |
| Акт о невозможности переподписания (образец) | Скачать |
| Реестр сертификатов сотрудников (XLSX) | Скачать |
Сколько стоит ошибка и что проверить заранее
Прямых денежных потерь у инцидента с СОС обычно нет, а стоимость складывается из простоя процессов. Останавливается всё, что упирается в проверку подписи: приёмка входящих документов, отправка отчётности, подписание кадровых документов, работа шлюза ЭДО. Пока администратор разбирается с хранилищами и кэшем, документы либо копятся в очереди, либо уходят в статус ошибочных и требуют ручной перепроверки после восстановления.
Вторая часть цены — разбор массива. Если автоматическая проверка успела отбраковать поток, после ремонта нужно перепроверить всю пачку и отделить документы, где ошибка была ложной, от тех, где сертификат действительно отозван. На объёме в несколько тысяч файлов без сохранённых протоколов проверки это отдельная задача на несколько дней.
Что проверить до того, как инцидент случится
- Состав хранилищ. Корневой сертификат в доверенных корневых, сертификат выдавшего УЦ и списки отзыва — в промежуточных, на всех рабочих местах и серверах проверки.
- Доступность точек распространения. Адреса .crl и OCSP из сертификатов должны открываться с той машины, которая выполняет проверку, а не только с ноутбука администратора.
- Даты nextUpdate. Ведите их в реестре сертификатов рядом со сроками действия самих сертификатов и сроками жизни носителей.
- Версия криптопровайдера. Часть информационных систем работает только с новыми версиями КриптоПро CSP, и устаревшая версия на рабочем месте даёт ошибки, которые легко спутать с проблемой статуса отзыва.
- Формат подписи по умолчанию. Если документы уходят в долгосрочное хранение, базового формата без штампа времени недостаточно.
В проектах Добыто даты nextUpdate ведутся в одном реестре со сроками действия сертификатов и носителей: две разные просрочки закрываются одной таблицей и одним напоминанием, а не двумя параллельными процессами.
Мария Ж, соучредитель сервиса КЭДО Добыто: «Мы закладываем пилотную группу до раскатки на всю компанию, и первое, что она вскрывает, — это состояние рабочих мест: разные версии криптопровайдера, разные наборы установленных сертификатов, у кого-то список отзыва не обновлялся ни разу. Прогоните пилот на 10-15 сотрудниках из разных подразделений, и вы увидите весь набор проблем до того, как в систему зайдут тысячи человек.»
В КЭДО эта задача снимается архитектурно: проверка выполняется на стороне платформы, а не на компьютере каждого сотрудника. В сервисе Добыто сотруднику не нужны ни криптопровайдер на рабочем месте, ни установка корневых сертификатов, ни ручное обновление списков отзыва — подписание и проверка идут из браузера, а состояние сертификатов ведётся централизованно.
Стоимость подключения КЭДО и электронных подписей
Стоимость зависит от численности сотрудников и набора функций: интеграции, электронного архива и уровня поддержки. Электронные подписи для сотрудников входят в тариф.
| Услуга | Стоимость | Сроки |
|---|---|---|
| Тариф «Старт»: до 25 сотрудников, ПЭП и УНЭП, базовые шаблоны | от 30 ₽ за сотрудника / мес | подключение за 5 минут |
| Тариф «Бизнес»: без ограничения по численности, ПЭП, УНЭП и УКЭП | от 50 ₽ за сотрудника / мес | подключение за 5 минут |
| Минимальная оплата по тарифу «Бизнес» | 50 сотрудников за 30 000 ₽ в год | период — год |
| Тариф «Корпорация»: выделенный сервер, SLA 99.9%, API и кастомные интеграции | по запросу | по запросу |
| Выпуск ПЭП и УНЭП для сотрудников | входит в тариф | по запросу |
| УКЭП через партнёров-удостоверяющих центров | по запросу | по запросу |
| Модуль интеграции с 1С:ЗУП (тариф «Бизнес») | входит в тариф | установка и настройка за один день |
| Электронный архив (тариф «Бизнес») | входит в тариф | по запросу |
Итоговая сумма определяется тарифом и численностью: по «Старту» ограничение — 25 сотрудников, по «Бизнесу» численность не ограничена, но действует минимальная оплата. Полный состав функций по каждому тарифу и условия перехода между ними указаны на странице тарифов ДОБЫТО КЭДО: тариф можно повысить или понизить в любое время, при повышении разница пересчитывается пропорционально оставшемуся периоду.
Выводы
Просроченный СОС корневого удостоверяющего центра выводит из строя не подпись, а механизм проверки статуса отзыва, поэтому ремонт начинается с чтения кода ошибки, а не с переустановки программ. Ключевая развилка проходит между «статус неизвестен» и «сертификат отозван»: первое закрывается обновлением списка и очисткой кэша за несколько минут, второе требует перевыпуска сертификата и переподписания документов. Для архивов вопрос решается не оперативно, а архитектурно, через форматы подписи со штампом времени и ответом службы статусов.
Мы в Добыто ведём эту часть на стороне платформы: сотрудник подписывает документ из браузера, а состояние сертификатов, списков отзыва и форматов подписи поддерживается централизованно, без установки криптографии на каждое рабочее место. Компаниям, которые переходят на КЭДО с бумажного или гибридного документооборота, это снимает целый класс инцидентов ещё до внедрения.
Частые вопросы
Можно ли отключить проверку статуса отзыва, чтобы подпись прошла прямо сейчас?
Технически такая настройка есть в параметрах проверки сертификатов, но она превращает проверку в формальность: отозванный сертификат при отключённой проверке отзыва выглядит действительным. Для разового просмотра документа это допустимо, для приёмки документов и юридически значимого документооборота — нет. Если результат проверки нужен как доказательство, отключение проверки отзыва обесценивает протокол.
Чем OCSP лучше списка отзыва в этой ситуации?
Служба актуальных статусов OCSP отвечает по одному конкретному сертификату в момент запроса, а не отдаёт весь список целиком, поэтому у неё нет поля nextUpdate и нет самого понятия «просроченный файл». Адрес службы, если УЦ её поддерживает, указан в составе сертификата рядом с точками распространения списков отзыва. Ограничение симметричное: при недоступности службы проверка тоже не выполнится, просто ошибка будет другой.
Ломается ли из-за просроченного СОС проверка машиночитаемой доверенности?
МЧД — это XML-файл, подписанный квалифицированной подписью руководителя или предпринимателя, и проверяется он теми же средствами, что и любой другой подписанный документ. Если статус сертификата подписанта проверить нельзя, вопросы возникнут и к самой доверенности, и к комплекту «документ плюс МЧД». Отдельно проверяется содержание доверенности: полномочия считываются алгоритмами по кодам классификатора, а не человеком.
Что делать, если сертификат выдан УЦ, который уже прекратил работу?
Проверьте сведения о центре на портале уполномоченного федерального органа. Если аккредитация прекращена, актуальных списков отзыва центр больше не публикует, и восстановить проверку локальными действиями нельзя. Подпись нужно перевыпускать в действующем аккредитованном удостоверяющем центре, а по уже подписанным документам опираться на сохранённые протоколы проверки и на подписи, у которых есть штамп времени.
Влияет ли тип носителя ключа на проблему со списком отзыва?
Нет. Носитель отвечает за хранение закрытого ключа и режим работы с ним: пассивные носители хранят извлекаемые ключи, активные формируют подпись на борту и ключ наружу не отдают. Статус отзыва проверяется по сертификату и не связан с тем, лежит ключ на Рутокене, JaCarta, eSmart или в облаке. Зависимость обратная: модель носителя определяет минимально необходимую версию криптопровайдера.
Нужно ли обновлять СОС на всех рабочих местах вручную?
При штатной работе списки скачиваются автоматически по адресу из сертификата, и ручная установка нужна только там, где автоматическое обновление невозможно: изолированный контур, жёсткая фильтрация исходящего трафика, сервер без доступа в интернет. Для таких машин удобнее поднять внутреннее зеркало списков и обновлять его по расписанию, ориентируясь на nextUpdate, а не раздавать файлы по станциям руками.
Как понять, что подпись в архиве переживёт истечение сертификата?
Откройте свойства подписи и посмотрите её формат. Базовый вариант без дополнительных доказательств зависит от внешних данных в момент проверки. Форматы со штампом времени и вложенным ответом о статусе сертификата содержат доказательства внутри самой подписи, а архивный формат с периодическим переподписанием рассчитан на сроки хранения, сопоставимые с кадровыми и финансовыми документами.
