Что делать, если файл не подписывается ЭЦП или возникает ошибка «Нет полного доверия к сертификату» в 1С?

← На главную

В процессе работы с электронно-цифровой подписью (ЭЦП) в среде 1С часто возникает ситуация, когда при попытке подписать документ система выдает предупреждение: «Нет полного доверия к сертификату подписи». При этом файл подписи может создаваться, но принимающая сторона (сервер или контрагент) не может его проверить или «снять» подпись. Рассмотрим подробно, как проанализировать эту проблему и решить её как на уровне настроек системы, так и на уровне программного кода 1С.

Разбираем причину: почему возникает недоверие к сертификату

Проблема «желтого значка» (отсутствия доверия) в КриптоПро или 1С сигнализирует о том, что система не может выстроить полную цепочку от вашего личного сертификата до головного удостоверяющего центра. Проанализируем основные факторы:

Отсутствие корневых или промежуточных сертификатов. Ваш сертификат выдан конкретным УЦ, который, в свою очередь, подчиняется головному УЦ (например, Минцифры). Если в системе нет всей цепочки «родительских» сертификатов, доверие не будет подтверждено.
Недоступность списков отзыва (CRL). Система должна быть уверена, что сертификат не был отозван. Для этого она обращается к спискам CRL. Если доступ к серверам УЦ заблокирован или списки устарели, возникнет ошибка.
Права доступа. Если код выполняется на стороне сервера 1С, служба rphost может не иметь доступа к хранилищу сертификатов или контейнеру закрытого ключа.

Шаг 1. Проверка цепочки сертификации и установка корневых сертификатов

Прежде чем менять код, необходимо убедиться в корректности установки сертификатов в операционной системе. Разберем этот процесс по шагам:

Откроем оснастку управления сертификатами (команда certmgr.msc для пользователя или certlm.msc для локального компьютера). Найдем наш личный сертификат и перейдем на вкладку «Путь сертификации». Если в цепочке виден только ваш сертификат без вышестоящих узлов, или если на каком-то из узлов стоит красный крест/желтый восклицательный знак — цепочка разорвана.

Выясним, кто выдал сертификат, и скачаем корневой и промежуточный сертификаты с сайта этого УЦ (например, Казначейство, Контур или ФНС). Важный момент: если вы работаете на сервере 1С, сертификаты нужно устанавливать не в «Текущего пользователя», а в хранилище «Локальный компьютер». Это обеспечит доступ к ним для учетной записи, под которой запущен сервер 1С (обычно USR1CV8).

Посмотрим, в какие папки устанавливать:

Самый верхний (головной) сертификат — в «Доверенные корневые центры сертификации».
Средние (промежуточные) сертификаты — в «Промежуточные центры сертификации».

Шаг 2. Настройка проверки списков отзыва (CRL)

Если цепочка выстроена, но статус всё равно сомнительный, проанализируем настройки проверки отзыва. Рассмотрим порядок действий в программе «КриптоАРМ» или «КриптоПро CSP»:

Убедимся, что в настройках прокси-сервера установлены системные параметры, иначе программа не сможет скачать списки CRL из интернета. В «КриптоАРМ» это делается через меню «Настройки» — «Управление настройками» — «Параметры прокси-сервера».

Попробуем принудительно обновить статус. Нажмем правой кнопкой на сертификат и выберем «Проверить статус по CRL». Если проверка проходит успешно и появляется «зеленая галочка», значит, технически подпись теперь будет валидна.

Шаг 3. Программная настройка менеджера криптографии в 1С

Рассмотрим код, который автор использовал в первом сообщении, и внесем в него необходимые улучшения. Часто стандартный метод Подписать() не учитывает специфику проверки цепочки на сервере.

Во-первых, рекомендуется выбирать сертификат не по индексу в массиве (как МассивВыбора[2]), а по уникальному отпечатку (Thumbprint), чтобы избежать ошибок при обновлении сертификатов. Во-вторых, используем свойство для управления проверкой цепочки.


Процедура ПодписатьФайл(ПутьКФайлу, ОтпечатокСертификата)
    
    // Инициализируем менеджер криптографии
    // Используем конкретный провайдер, установленный в системе
    МК = Новый МенеджерКриптографии("Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider", "", 80);
    
    // Если мы знаем, что цепочка на сервере может не проверяться, 
    // но уверены в валидности ключа, можно программно проигнорировать ошибки доверия
    МК.ДействиеПриПроверкеСертификатаКриптографии = ДействиеПриПроверкеСертификатаКриптографии.Игнорировать;
    
    // Обязательно включаем полную цепочку сертификатов в подпись, 
    // чтобы получатель мог проверить ее без поиска ваших корневых сертификатов
    МК.ВключениеСертификатовВПодпись = СпособВключениеСертификатовКриптографии.ВключатьПолнуюЦепочку;
    
    // Поиск сертификата по отпечатку
    ПараметрыОтбора = Новый Структура("Отпечаток", ОтпечатокСертификата);
    МассивСертификатов = МК.ПолучитьСертификаты(ПараметрыОтбора);
    
    Если МассивСертификатов.Количество() = 0 Тогда
        Сообщить("Сертификат с указанным отпечатком не найден!");
        Возврат;
    КонецЕсли;
    
    СертификатПодписи = МассивСертификатов[0];
    
    // Выполняем подписание
    МК.ПарольДоступаКЗакрытомуКлючу = "ваш_пароль";
    Попытка
        МК.Подписать(ПутьКФайлу, ПутьКФайлу + ".sgn", СертификатПодписи);
    Исключение
        Сообщить("Ошибка при подписании: " + ОписаниеОшибки());
    КонецПопытки;
    
КонецПроцедуры

Шаг 4. Решение проблемы «не могут снять подпись» на стороне сервера

Выясним причину, по которой принимающая сторона не может обработать файл. Если ваш код создает файл .sgn, а сервер его отклоняет, проблема может быть в формате данных или кодировке.

Формат подписи (CMS vs CAdES). Стандартный МенеджерКриптографии создает подпись в формате PKCS#7 (CMS). Однако современные государственные и коммерческие системы часто требуют усовершенствованную подпись CAdES-BES. Если принимающая сторона требует именно CAdES, стандартный метод 1С может не подойти, и придется использовать COM-объект CadesCom.CadesSignedData.

Кодировка Base64. Посмотрим на передачу данных. Многие HTTP-сервисы ожидают подпись в текстовом формате Base64, а метод МК.Подписать() создает бинарный файл. Проанализируем, как преобразовать результат перед отправкой:


// Читаем бинарный файл подписи
ДвоичныеДанныеПодписи = Новый ДвоичныеДанные(ПутьКФайлу + ".sgn");
// Преобразуем в строку Base64
СтрокаПодписиBase64 = Base64Строка(ДвоичныеДанныеПодписи);
// Удаляем лишние переносы строк, если это требуется веб-сервисом
СтрокаПодписиBase64 = СтрЗаменить(СтрокаПодписиBase64, Символы.ПС, "");
СтрокаПодписиBase64 = СтрЗаменить(СтрокаПодписиBase64, Символы.ВК, "");

Шаг 5. Особенности работы на сервере (права доступа)

Проанализируем ситуацию, когда под пользователем всё работает, а в регламентном задании (на сервере) — нет. Это классическая проблема прав доступа службы 1С.

Контейнер закрытого ключа. Если ключ хранится в реестре, убедитесь, что у пользователя USR1CV8 есть права на ветку HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Crypto Pro\Settings\Users\... (для 64-битных систем путь может отличаться). Лучшим решением будет переустановка контейнера в хранилище компьютера, а не пользователя.
Взаимодействие с рабочим столом. Если КриптоПро настроен на запрос пароля через собственное окно, серверная подпись не сработает (окно просто не отобразится). Пароль должен передаваться программно через свойство ПарольДоступаКЗакрытомуКлючу, а в настройках КриптоПро должно быть разрешено использование ключа службами.

Итоги

Для успешного подписания файлов в 1С без ошибок доверия мы должны реализовать комплексный подход: установить полную цепочку сертификатов в хранилище локального компьютера, настроить доступ к спискам отзыва и использовать программные методы включения цепочки в тело подписи. Проанализировав формат, требуемый получателем (бинарный или Base64), и обеспечив серверную службу 1С правами доступа к криптопровайдеру, мы добьемся стабильной работы ЭЦП.