При настройке Электронного документооборота (ЭДО) в клиент-серверных базах 1С (Управление торговлей 11.5, ERP, Комплексная автоматизация) мы часто сталкиваемся с ситуацией, когда подписание документов останавливается с ошибкой. Система сообщает, что нет личного сертификата на серверной машине, хотя мы уверенно установили сертификат в хранилище, и он виден в панели управления криптопровайдера (например, КриптоПро CSP) под учетной записью администратора.
В этой статье мы подробно разберем, почему возникает данная проблема, как на нее влияет архитектура Windows Server и какие существуют проверенные способы решения. Мы проанализируем настройки самой 1С и особенности работы с криптографией в изолированных сеансах служб.
Давайте сначала проанализируем исходные данные. Мы имеем клиент-серверную архитектуру 1С. Пользователь пытается подписать документ с клиентской машины. 1С выдает ошибку проверки: сертификат не найден на сервере. При этом физически носитель (Рутокен или флешка) может быть вставлен в сервер, либо в клиентский компьютер.
Главная причина кроется в том, что сервер 1С (служба Агент сервера 1С:Предприятия) работает в специальной сессии операционной системы, так называемой Session 0. Эта сессия изолирована от интерактивных сеансов пользователей. Даже если вы зашли на сервер по RDP под администратором и видите сертификат, это не означает, что служба 1С, работающая в фоне, тоже его "видит".
Разберем методы решения от самых простых (настройка логики работы) до технических (перенос ключей).
Прежде чем погружаться в настройки сервера, давайте проверим настройки самой 1С. Очень часто проблема решается простым переключением "галочки".
Если электронная подпись (токен) находится физически у пользователя на клиентском компьютере, а 1С пытается искать его на сервере, ошибка неизбежна. Нам необходимо указать программе, что подписывать нужно на стороне клиента.
В современных конфигурациях 1С логика работы с криптографией устроена так, что программа сама пытается определить контекст. Однако, если мы используем регламентные задания для автоматического получения и отправки документов, эти операции всегда выполняются на сервере. В таком случае нам обязательно потребуется настроить доступность ключа именно для серверной службы.
Если специфика вашей работы требует, чтобы подписание происходило именно на сервере (например, работает автообмен ЭДО фоновым заданием, или пользователи подключаются через веб-клиент без установки криптопровайдера локально), нам необходимо обеспечить стабильный доступ службы 1С к закрытому ключу.
Использование аппаратного токена (USB-флешки), вставленного в сервер, является ненадежным решением для службы Windows из-за изоляции сессий. Служба не может вывести окно запроса PIN-кода, и часто драйверы смарт-карт не пробрасываются в сессию службы корректно.
Самый надежный способ, который мы рекомендуем рассмотреть — это копирование контейнера закрытого ключа с аппаратного носителя в Реестр серверной машины.
Важно: Данная операция возможна только если при генерации ключа он был помечен как "Экспортируемый".
Разберем процедуру по шагам:
_REG).Теперь ключевой момент: чтобы служба 1С могла использовать этот ключ без участия человека (она не сможет ввести пароль), пароль нужно сохранить в системе.
После этого установите сертификат из этого контейнера в хранилище "Личное". Теперь ключ находится в реестре и не требует физического наличия токена в порту.
Даже после переноса в реестр, мы можем столкнуться с тем, что 1С все равно не видит сертификат. Это происходит из-за того, что мы установили сертификат в хранилище "Личное" пользователя Administrator, а служба Агент сервера 1С может быть запущена под пользователем USR1CV8 или LocalSystem.
Давайте выясним, под кем работает сервер, и предоставим сертификат именно этому пользователю.
Анализ службы:
services.msc).Агент сервера 1С:Предприятия 8.3.Если там указан конкретный доменный или локальный пользователь (например, .\usr1cv8), нам нужно зайти в систему именно под этим пользователем и проделать установку сертификата и ввод сохраненного пароля в КриптоПро именно в этом сеансе.
Если служба работает от имени системной учетной записи (Local System), ситуация сложнее, так как интерактивный вход под ней невозможен. В этом случае системные администраторы часто прибегают к утилите PsExec (из пакета Sysinternals) для запуска оснастки управления сертификатами от имени системы:
PsExec.exe -i -s certmgr.msc
Запустив эту команду, мы попадем в хранилище сертификатов именно системной учетной записи. Туда необходимо импортировать личный сертификат.
Однако, для работы с КриптоПро и сохранения паролей для LocalSystem, более простым решением часто является перенастройка службы 1С на запуск от имени конкретного пользователя-администратора (или специально созданного сервисного пользователя), для которого мы уже настроили криптографию в обычном режиме.
Если вы все же решили использовать аппаратный ключ, вставленный непосредственно в сервер, обратите внимание на следующие настройки.
В панели управления КриптоПро CSP на вкладке "Настройки" для оборудования есть опция, связанная с использованием службы локальных смарт-карт. Если токен вставлен в сервер, убедитесь, что соответствующие службы Windows (Smart Card) запущены и работают.
Также проверьте права доступа к закрытому ключу:
Еще один нюанс, который мы не должны упускать из виду — это разрядность (битность) приложений. Сервер 1С:Предприятия (64-bit) требует установленной 64-битной версии криптопровайдера и соответствующих драйверов.
Бывают ситуации, когда в 32-битной оснастке сертификат виден, а 64-битное приложение сервера его не находит. Убедитесь, что вы используете актуальную версию КриптоПро CSP (рекомендуется версия 5.0 R2 и выше), которая корректно работает в обеих архитектурах.
Для успешного решения проблемы "Нет личного сертификата на сервере" мы рекомендуем действовать по следующему алгоритму:
Агент сервера 1С.Применяя эти методы, вы сможете настроить стабильную работу электронного документооборота в вашей корпоративной системе.