Разберем ситуацию на конкретном примере. УПД датирован 31.07.2026, поставщик подписал его 06.08.2026, сертификат электронной подписи и указанный в нем срок действия ключа действовали до 12.08.2026, а получатель фактически получил документ через 1С-ЭДО только 19.08.2026. При попытке утвердить документ 1С сообщает: «Документ не обработан, т.к. содержит невалидные подписи».
На первый взгляд причина кажется очевидной: к моменту получения УПД сертификат поставщика уже закончился. Но именно здесь важно не делать поспешный вывод. Сам по себе факт, что сертификат истек после подписания документа, еще не означает, что подпись должна считаться недействительной. Сначала выясним дату, на которую 1С проверяет сертификат, наличие достоверного времени подписания и конкретную причину, по которой механизм проверки присвоил подписи статус «Не верна».
Проанализируем даты. В рассматриваемой ситуации последовательность событий выглядит так:
УПД сформирован датой 31.07.2026.
Поставщик подписал электронный документ 06.08.2026.
Сертификат подписанта и срок действия ключа действовали до 12.08.2026.
Документ поступил получателю 19.08.2026.
Таким образом, на дату 06.08.2026 сертификат еще был действующим. Документ подписан за несколько дней до окончания срока действия сертификата.
Рассмотрим подробнее правовую сторону. Статья 11 Федерального закона № 63-ФЗ «Об электронной подписи» предусматривает, что квалифицированная электронная подпись признается действительной, если квалифицированный сертификат был действителен на момент подписания электронного документа при наличии достоверной информации о моменте подписания. Аналогичный принцип применяется к сроку действия ключа электронной подписи. Если же достоверный момент подписания определить невозможно, проверка выполняется исходя из состояния сертификата и ключа на день проверки.
Отсюда получаем важный практический вывод: если 1С может достоверно установить, что УПД подписан 06.08.2026, а сертификат и ключ в этот день действовали, получение документа 19.08.2026 после истечения сертификата само по себе не должно превращать корректную подпись в неверную.
Обратим внимание на слово «достоверно». Дата, которую мы просто видим рядом с подписью, и криптографически подтвержденное время подписания — не всегда одно и то же. Для подтверждения момента подписания может использоваться метка доверенного времени. В технологиях электронной подписи это специальная информация о дате и времени, сформированная доверенной стороной, удостоверяющим центром или оператором информационной системы. 1С также поддерживает работу с метками доверенного времени и усовершенствованными подписями.
Поэтому не будем считать срок сертификата единственной причиной ошибки. В нашем случае необходимо определить, что именно не понравилось проверке 1С.
Начнем с самого полезного действия. Не будем сразу устанавливать сертификаты, переустанавливать КриптоПро или просить поставщика прислать УПД заново. Сначала получим подробный результат проверки.
Откроем рабочее место «Текущие дела ЭДО».
Найдем проблемный УПД.
Откроем электронный документ и перейдем к сведениям о подписях.
Найдем подпись поставщика со статусом «Не верна».
Выполним для нее команду «Проверить электронные подписи».
Если используется расширенный интерфейс, дополнительно откроем «Текущие дела ЭДО» → «Еще» → «Проверить подписи».
Посмотрим текст в колонке или поле комментария к результату проверки.
Последний пункт особенно важен. В официальной документации 1С указано, что механизм массовой проверки показывает документы, электронная подпись которых не прошла проверку, а в комментарии можно увидеть причину возникновения ошибки. Массовая проверка доступна начиная с Модуля ЭДО 1.9.9.17.
Разберем, что может оказаться в результате. Ошибка может быть связана не только со сроком действия сертификата. 1С перечисляет среди возможных причин отсутствие корневого или промежуточного сертификата, невозможность проверить сертификат по списку отозванных сертификатов, проблемы средства электронной подписи и другие ошибки проверки.
Поэтому нам нужно получить не только общий статус «Не верна», но и конкретную формулировку. Например:
истек срок действия сертификата;
не удалось построить цепочку сертификатов;
корневой сертификат не является доверенным;
не удалось проверить сертификат по списку отозванных;
хеш-значение неправильное;
сертификат отозван;
не удалось выполнить операцию проверки ЭП;
ошибка проверки МЧД или полномочий подписанта.
Именно от этой формулировки выбираем дальнейшее решение.
Теперь рассмотрим наиболее интересную часть конкретно для 1С:Фреш. В истории изменений Библиотеки электронных документов 1С есть исправление, практически дословно соответствующее рассматриваемой ситуации.
В исправлениях Библиотеки электронных документов версии 1.9.15.21 фирма «1С» указывала, что при проверке подписи электронного документа в 1С:Фреш в случае, когда у сертификата подписанта уже закончился срок действия, могла возникать ошибка проверки. Поведение было скорректировано: после исправления текст причины заполняется, а подпись проходит проверку.
Это очень важная информация. Она подтверждает, что сценарий «документ был подписан действующим сертификатом, но сертификат закончился до момента последующей проверки в 1С:Фреш» действительно учитывался разработчиками 1С и отдельно исправлялся.
Теперь посмотрим на версию из рассматриваемого примера. Для конфигурации «Бухгалтерия предприятия» 3.0.203.24 в составе поставки используется БиблиотекаЭлектронныхДокументов версии 1.9.16.66. Это значительно новее версии 1.9.15.21, в которой указанное исправление уже присутствовало.
Следовательно, для 1С:Бухгалтерии 3.0.203.24 с БЭД 1.9.16.66 объяснение «сертификат просто закончился 12 августа, поэтому 19 августа подпись стала неверной» выглядит недостаточным.
Иными словами, в этой версии сначала ищем дополнительную причину проверки, а не требуем от поставщика немедленно перевыпускать и повторно отправлять УПД.
Несмотря на номер конфигурации, обязательно проверим фактически используемую версию Модуля ЭДО. Особенно это важно в 1С:Фреш, где прикладное решение, сервисные компоненты и обновления могут обслуживаться централизованно.
Перейдем в «Текущие дела ЭДО» и воспользуемся командой «Поддержка» или «Помощь» → «О Модуле ЭДО». Название команды зависит от используемого интерфейса и версии библиотеки. Именно такой способ проверки версии Модуля ЭДО приводит официальный справочник 1С.
Сравним полученный номер с версией 1.9.15.21. Если по какой-либо причине фактический модуль окажется старее, сначала решим вопрос с его обновлением.
Если используется 1С:Фреш, не будем самостоятельно заменять общие модули или встраивать свежую Библиотеку электронных документов в типовую облачную конфигурацию. Обновления в модели сервиса выполняются централизованно. Зафиксируем версию приложения и Модуля ЭДО и передадим эти сведения в поддержку 1С:Фреш или 1С-ЭДО.
Если фактически установлена БЭД 1.9.16.66, как должна быть в рассматриваемой конфигурации, будем считать известную старую ошибку с истекшим сертификатом уже исправленной и продолжим диагностику.
В обсуждении на форуме уже выполнено разумное действие: сертификат подписанта сохранен и просмотрена его цепочка. Пользователь видит в цепочке сертификаты Минцифры и удостоверяющего центра. Это полезная проверка, но здесь есть важная тонкость.
Не требуется помещать сам сертификат контрагента в хранилище доверенных корневых центров. Доверять необходимо корректному корневому удостоверяющему центру, а промежуточные сертификаты должны находиться в соответствующем хранилище промежуточных центров сертификации.
Разберем нормальную цепочку условно:
сертификат физического лица или руководителя, которым непосредственно подписан УПД;
сертификат удостоверяющего центра, выпустившего сертификат подписанта;
при необходимости промежуточные сертификаты;
доверенный корневой сертификат соответствующей инфраструктуры удостоверяющих центров.
Официальная инструкция 1С для ошибки «Документ не обработан, так как содержит невалидные подписи» действительно предлагает проверить наличие корневого сертификата ГУЦ и корневого сертификата удостоверяющего центра контрагента или оператора ЭДО. После установки сертификатов 1С рекомендует повторно выполнить команду «Проверить электронные подписи».
Но в нашем случае автор уже сообщает, что цепочка отображается полностью и доверие настроено. Поэтому не будем бесконечно переустанавливать один и тот же сертификат. Проверим следующую группу причин.
Отдельно обратим внимание на фразу «сам сертификат добавляла в доверенные». Такой прием часто используют в качестве попытки исправления, но он не является правильным универсальным решением.
Если сертификат контрагента вручную сделать доверенным, мы фактически обходим нормальную модель построения цепочки. При этом остаются нерешенными вопросы:
каким удостоверяющим центром сертификат был выдан;
действовала ли аккредитация удостоверяющего центра;
не был ли сертификат отозван;
действовал ли сертификат и ключ на необходимую дату;
соответствует ли электронная подпись подписанному файлу;
можно ли установить достоверный момент подписания.
Поэтому вернемся к стандартной цепочке доверия и анализу результата криптографической проверки. Если вся цепочка корректна, следующий кандидат — проверка отзыва и даты.
Сертификат может выглядеть корректным, вся цепочка может строиться, но электронная подпись все равно может не пройти проверку, если программе не удалось определить статус отзыва сертификата.
Посмотрим на типичный сценарий. У удостоверяющего центра публикуется список отозванных сертификатов. Криптопровайдер или механизм проверки 1С должен получить актуальные сведения и выяснить, не был ли сертификат прекращен досрочно.
Проблемы возникают, например, когда:
ресурс удостоверяющего центра временно недоступен;
сервер или рабочая станция не имеет доступа к адресу списка отзыва;
прокси-сервер или межсетевой экран блокирует обращение;
загруженный список отзыва устарел;
не удается проверить историческое состояние сертификата на требуемую дату;
возникает ошибка проверки цепочки одного из промежуточных сертификатов.
Официальный справочник 1С прямо относит невозможность проверить сертификат контрагента по спискам отозванных сертификатов к причинам получения статуса «Подпись неверна».
Поэтому, если комментарий содержит слова «список отозванных», CRL, offline, не удалось проверить сертификат», будем устранять именно доступ к инфраструктуре проверки, а не срок сертификата.
После устранения доступа обязательно повторно запустим проверку. Старый статус документа не всегда исчезает автоматически только потому, что внешняя причина уже устранена.
Теперь вернемся к ключевому вопросу: почему 1С должна проверять сертификат на 06.08.2026, а не на 19.08.2026?
Рассмотрим подробнее. Обычная электронная подпись может содержать сведения о времени, сформированные на стороне компьютера подписанта. Но системные часы компьютера сами по себе не всегда дают требуемую достоверность. Более сильным доказательством является метка доверенного времени.
Если в подписи присутствует такая метка, проверяющая сторона получает независимое подтверждение того, что подпись существовала в определенный момент. Это особенно важно после окончания действия сертификата.
В современных версиях Библиотеки стандартных подсистем 1С для работы с такими сценариями предусмотрены средства проверки сертификата на определенную дату. В программном интерфейсе используются, в частности, методы ЭлектроннаяПодпись.ПроверитьСертификат и ЭлектроннаяПодписьКлиент.ПроверитьСертификат. Для проверки на дату метки времени предусмотрены параметры, позволяющие указать дату проверки и признак использования даты метки времени. Кроме того, процедура ЭлектроннаяПодписьКлиент.ПроверитьПодпись может возвращать расширенные сведения о результате проверки подписи.
Эти методы полезны прежде всего разработчикам и специалистам сопровождения. Обычному пользователю 1С:Фреш не требуется писать код или изменять конфигурацию. Но понимание механизма помогает правильно сформулировать обращение в поддержку: попросим проверить, на какую дату выполняется валидация сертификата и определяется ли достоверный момент подписания 06.08.2026.
В рассматриваемом случае отдельно указано, что не только сертификат, но и закрытый ключ действовал до 12.08.2026. Это важная деталь.
С 5 августа 2024 года статья 11 Федерального закона № 63-ФЗ отдельно учитывает срок действия ключа электронной подписи. Если достоверный момент подписания известен, ключ должен быть действующим именно на этот момент. Если момент подписания определить нельзя, применяется дата проверки.
В нашем примере ключ действовал 06.08.2026. Поэтому при достоверно установленной дате подписания это условие также выполняется.
Не будем при этом искать закрытый ключ поставщика у получателя. Закрытый ключ контрагента получателю не нужен и передаваться не должен. Для проверки используется открытый ключ, содержащийся в сертификате. Указанный в сертификате срок действия ключа — характеристика, которую учитывает механизм проверки.
Следующий принципиально другой вариант — ошибка контроля хеша.
Если 1С сообщает что-либо вроде «Подпись неверна. Хеш-значение неправильное», проблему уже нельзя исправить установкой сертификатов.
Электронная подпись математически связана с конкретной последовательностью байтов подписанного документа. Изменим хотя бы один значимый байт после подписания — вычисленный хеш перестанет совпадать с хешем, подтвержденным электронной подписью.
В таком случае проанализируем транспортный пакет. Возможна ситуация, когда:
документ был изменен после формирования подписи;
оператор или интеграция передали не тот файл, к которому относится подпись;
при роуминге некорректно сформирован или преобразован транспортный контейнер;
подпись относится к другой версии файла;
произошло повреждение данных.
Такую подпись получатель самостоятельно «починить» не сможет. Сертификаты, КриптоПро, доверенные корни и изменение настроек здесь не помогут. Нужно будет восстанавливать корректную пару «исходный файл + подпись», а при невозможности — получать новый корректно подписанный экземпляр через оператора или отправителя.
Еще одна группа ошибок может внешне восприниматься как проблема сертификата, хотя фактически проверка останавливается на полномочиях подписанта.
Если УПД подписал не руководитель организации, а сотрудник своей квалифицированной электронной подписью физического лица, проверим наличие и состояние машиночитаемой доверенности.
Убедимся, что:
МЧД относится к нужной организации;
доверенность действует на дату подписания документа;
доверенность не отозвана;
подписант в МЧД соответствует владельцу сертификата;
полномочия позволяют подписывать соответствующий вид электронного документа;
1С смогла получить МЧД из распределенного реестра или из пакета ЭДО.
Не смешиваем два статуса: криптографически неверная подпись и верная подпись, для которой не удалось подтвердить полномочия. Способы устранения этих проблем различаются.
Теперь рассмотрим важную практическую особенность. В локальной 1С проверка электронной подписи во многих сценариях зависит от сертификатов и криптографической инфраструктуры рабочей станции или сервера организации. В 1С:Фреш часть операций выполняется в облачной инфраструктуре.
Поэтому возможна ситуация, когда на локальном компьютере мы:
установили корневой сертификат;
видим полностью корректную цепочку;
открываем сертификат без предупреждений;
успешно проверяем его средствами операционной системы;
но статус в самом облачном документе 1С:Фреш не меняется.
В этом случае перестанем бесконечно менять локальное хранилище сертификатов. Попросим поддержку проверить серверный результат валидации электронной подписи в 1С:Фреш. Для рассматриваемого сценария это особенно оправданно, поскольку в истории Библиотеки электронных документов уже было отдельное исправление именно для проверки просроченного сертификата подписанта в 1С:Фреш.
Допустим, мы установили недостающий промежуточный сертификат, восстановили доступ к CRL или устранили иную техническую проблему. Не будем сразу снова нажимать «Утвердить».
Сначала заставим 1С заново проверить электронную подпись:
откроем проблемный электронный документ;
выберем подпись;
выполним команду «Проверить электронные подписи»;
либо откроем «Текущие дела ЭДО» → «Еще» → «Проверить подписи»;
проверим изменение статуса и текста комментария.
Официальная инструкция 1С также завершает устранение проблем с сертификатной цепочкой именно повторной командой проверки подписи. При успешной проверке статус должен измениться на «Верна».
Только после этого вернемся к утверждению УПД.
Теперь соберем все выводы и разберем рекомендуемый порядок именно для приведенного примера.
Не будем считать сертификат поставщика автоматически недействительным для этого УПД. Подпись выполнена 06.08.2026, а сертификат и ключ действовали до 12.08.2026.
Получим подробную причину проверки. Запустим «Проверить электронные подписи» или массовую проверку через «Текущие дела ЭДО» и изучим комментарий.
Проверим фактическую версию Модуля ЭДО. Для 1С:Бухгалтерии 3.0.203.24 ожидается Библиотека электронных документов 1.9.16.66. Известное исправление поведения 1С:Фреш при окончании сертификата было внесено еще в ветке 1.9.15.21. Поэтому на текущей библиотеке старое поведение уже не должно быть нормой.
Если причина относится к цепочке доверия, проверим именно корневой и промежуточные сертификаты. Не ограничимся добавлением пользовательского сертификата поставщика в доверенные.
Если причина относится к спискам отзыва, восстановим возможность их проверки. Затем снова запустим проверку подписи.
Если программа считает сертификат просроченным именно на дату проверки, зафиксируем этот результат для поддержки 1С. Укажем, что фактическая дата подписания — 06.08.2026, сертификат и ключ действовали до 12.08.2026, а документ получен 19.08.2026. Попросим проверить определение момента подписания и серверную валидацию подписи в 1С:Фреш.
Если будет указано «Хеш-значение неправильное», прекратим работу с сертификатами. Это уже нарушение связи между подписью и подписанным файлом. Понадобится корректный исходный транспортный пакет либо повторная передача документа.
Если криптографическая подпись верна, но ошибка относится к МЧД, будем исправлять сведения о доверенности. Не будем просить поставщика переподписывать УПД только из-за проблемы получения МЧД, пока не выясним точную причину.
Обновление проверить стоит, но не будем рассчитывать на него как на единственное решение.
Конфигурация 3.0.203.24 уже содержит достаточно новую версию БиблиотекаЭлектронныхДокументов — 1.9.16.66. Известное исправление проверки подписи в 1С:Фреш при закончившемся сертификате появилось раньше. Поэтому обычный переход на следующий релиз конфигурации сам по себе не объясняет и не гарантирует устранение конкретной ошибки.
В 1С:Фреш сначала проверим, доступно ли штатное обновление приложения, и используем только штатный механизм сервиса. Не будем самостоятельно изменять типовые общие модули или переносить в облачную базу отдельные объекты более новой Библиотеки электронных документов.
Если после штатного обновления статус остается прежним, будем рассматривать проблему как конкретный сбой проверки этого пакета, а не как общую необходимость обновить бухгалтерскую конфигурацию.
Если проблему разбирает разработчик или специалист сопровождения, обратим внимание на подсистему электронной подписи БСП и Библиотеку электронных документов.
Для программной проверки сертификатов в современных версиях БСП используются функции ЭлектроннаяПодпись.ПроверитьСертификат и ЭлектроннаяПодписьКлиент.ПроверитьСертификат. При работе с меткой доверенного времени проверка может выполняться на заданную дату. Для расширенной проверки подписи используется ЭлектроннаяПодписьКлиент.ПроверитьПодпись. Также доступны свойства сертификата, содержащие сроки действия сертификата и ключа.
В рассматриваемой пользовательской ситуации писать собственный код не требуется. Будем использовать штатную проверку Модуля ЭДО, поскольку именно она определяет возможность дальнейшей обработки входящего электронного документа. Самовольная программная подмена результата проверки создала бы гораздо более серьезную проблему: визуально документ мог бы считаться принятым, хотя штатная криптографическая проверка фактически не выполнена.
Здесь важно разделить две задачи: убрать документ из текущих дел и подтвердить действительность электронной подписи.
В 1С-ЭДО существует команда «Закрыть принудительно». Она предназначена для случаев, когда стандартно завершить электронный документооборот невозможно. После выполнения команды документ выводится из активной обработки и помещается в архив с состоянием принудительного закрытия.
Но не будем воспринимать эту команду как способ исправить подпись. Принудительное закрытие не делает невалидную электронную подпись валидной и не заменяет успешную криптографическую проверку. Оно только завершает обработку документа внутри рабочего места 1С.
Поэтому используем принудительное закрытие только тогда, когда нам действительно необходимо убрать безнадежно зависший документооборот из текущих дел и уже принято отдельное решение, как оформлять хозяйственную операцию. Для нормального принятия юридически значимого УПД сначала постараемся добиться статуса корректной подписи.
Постараемся решить проблему без обращения к поставщику, и в большинстве технических случаев это возможно. Но обозначим границу, за которой получатель не способен восстановить документ самостоятельно.
Обращение к отправителю или оператору действительно потребуется, если выясним, что:
подпись математически не соответствует полученному файлу;
полученный транспортный пакет поврежден;
оператор передал подпись от другой версии документа;
сертификат уже не действовал или ключ уже не действовал в достоверно установленный момент подписания;
сертификат был отозван с датой, исключающей признание этой подписи;
достоверный момент подписания установить невозможно, а проверка должна выполняться уже после окончания допустимого срока;
сам отправитель подписал не тот файл и корректной электронной подписи к нужному УПД вообще не существует.
В этих ситуациях получатель не может сформировать новую подпись от имени поставщика. Нельзя «перепривязать» существующую подпись к другому файлу или изменить дату подписания без разрушения криптографической целостности.
Если связаться с поставщиком практически невозможно, пойдем через собственный сервис 1С-ЭДО. Для диагностики подписи контрагента нам не требуется доступ в техническую поддержку поставщика.
Подготовим для поддержки 1С-ЭДО максимально конкретные сведения:
версию платформы — 1С:Предприятие 8.5.1.1469;
версию конфигурации — 3.0.203.24;
фактическую версию Модуля ЭДО;
вид документа — УПД;
дату документа — 31.07.2026;
дату подписи — 06.08.2026;
дату окончания сертификата — 12.08.2026;
дату окончания действия ключа — 12.08.2026;
дату получения — 19.08.2026;
полный текст результата повторной проверки электронной подписи;
оператора отправителя и оператора получателя, особенно если документ пришел через роуминг;
идентификатор электронного документа или транспортного пакета, если он доступен в технической информации ЭДО.
Сформулируем суть обращения максимально предметно: «Документ подписан 06.08.2026 сертификатом и ключом, действовавшими до 12.08.2026. В 1С:Фреш документ получен 19.08.2026 и получает статус невалидной подписи. Просим проверить дату, на которую выполняется валидация сертификата, определение момента подписания, статус сертификата на дату подписи и серверную проверку пакета».
Такое обращение позволит специалисту сразу проверить техническую часть, вместо стандартного ответа с предложением установить сертификат заново.
В рассматриваемой ситуации не будем начинать с просьбы «перевыставьте УПД новым сертификатом». Сначала установим реальную причину.
Если документ действительно подписан 06.08.2026 действующей УКЭП и эта дата подтверждается механизмом электронной подписи, окончание сертификата 12.08.2026 не означает автоматически, что документ нужно формировать заново. Более того, наличие в истории изменений 1С отдельного исправления для проверки подписей в 1С:Фреш после окончания сертификата подтверждает, что такие документы должны обрабатываться корректно при соблюдении необходимых условий.
Повторная отправка имеет смысл только после того, как мы установили неисправимый дефект исходного пакета либо выяснили, что подпись изначально не соответствовала требованиям.
Сведем диагностику к последовательному алгоритму, чтобы не выполнять лишних действий.
Откроем проблемный УПД в 1С-ЭДО.
Запустим повторную проверку электронной подписи.
Получим не общий статус, а полный комментарий проверки.
Проверим фактическую версию Модуля ЭДО.
Если используется БЭД 1.9.16.66, учтем, что известная старая проблема 1С:Фреш с окончанием сертификата уже должна быть исправлена.
Проверим цепочку: сертификат подписанта → промежуточный УЦ → корневой доверенный УЦ.
Не будем добавлять сертификат контрагента в доверенные как замену нормальной цепочке.
Проверим возможность получения сведений об отзыве сертификата.
Проверим, определяется ли достоверный момент подписания 06.08.2026.
Проверим срок действия сертификата и ключа именно на дату подписания.
Если подпись выполнена сотрудником, отдельно проверим МЧД и полномочия.
Если обнаружена ошибка хеша, перестанем переустанавливать сертификаты и будем разбираться с транспортным пакетом.
После любого исправления снова выполним «Проверить электронные подписи».
При сохранении ошибки в 1С:Фреш обратимся непосредственно в поддержку 1С-ЭДО со сведениями о датах, версиях и идентификаторе пакета — обращаться в техническую поддержку поставщика для первичной диагностики не требуется.
Только если подтвердится реальная криптографическая некорректность файла или подписи, будем добиваться повторной передачи документа от отправителя или оператора.
Проанализируем все исходные данные еще раз. Сертификатная цепочка уже проверялась, корневые сертификаты отображаются, пользователь даже пробовал добавлять сертификат в доверенные. При этом конфигурация достаточно свежая — 3.0.203.24. Документ подписан 06.08.2026, то есть до 12.08.2026, когда завершалось действие и сертификата, и ключа.
Поэтому наиболее правильным следующим шагом будет не новая установка сертификата и не обращение к поставщику, а получение подробного текста повторной проверки подписи и проверка серверной валидации в 1С:Фреш.
Особенно подчеркнем факт известного исправления: в Библиотеке электронных документов 1.9.15.21 разработчики уже устраняли ситуацию, когда в 1С:Фреш проверка подписи давала ошибку после окончания срока сертификата подписанта, хотя подпись должна была пройти проверку. В 3.0.203.24 используется более новая ветка БЭД.
Если текущая проверка прямо сообщает только об истекшем сертификате и игнорирует дату подписания 06.08.2026, зафиксируем это как возможную ошибку механизма проверки конкретного пакета или облачной среды и передадим в 1С-ЭДО. Если же подробная проверка выдаст другую причину — CRL, цепочку, МЧД, хеш или транспортный контейнер — будем устранять уже ее.
Главный вывод: сертификат, который закончился после подписания УПД, не следует автоматически считать причиной недействительности подписи. Сначала определим достоверный момент подписания и конкретный результат криптографической проверки. В рассматриваемом примере дата подписи 06.08.2026 находится внутри срока действия сертификата и ключа до 12.08.2026, поэтому есть все основания сначала добиваться корректной повторной проверки документа в 1С-ЭДО, не привлекая поставщика.
Информация носит справочный характер