КриптоПро и ЭЦП в 1С на терминальном сервере: лицензия, токен, ошибки подписи

На терминальном сервере КриптоПро ставят на сам сервер и берут серверную лицензию. Подпись в 1С считается либо в сессии пользователя (токен проброшен по RDP или контейнер лежит в его профиле), либо службой сервера 1С под её учётной записью. Выбор режима определяет всё остальное: ниже лицензия, токен, ошибки 103 и 104 и кейс на 49 рабочих мест.

Где в 1С на терминальном сервере считается подпись: в сессии или на сервере

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

Режим «на клиенте» на терминальном сервере означает следующее: клиент 1С запущен в RDP-сессии пользователя, значит, подпись считает процесс в этой сессии. Ему нужно, чтобы КриптоПро был установлен на сервере и чтобы в сессии были видны сертификат и закрытый ключ: либо токен, проброшенный с рабочего места, либо контейнер в профиле этого пользователя. Режим «на сервере» устроен иначе: подпись считает служба «Агент сервера 1С:Предприятия», и ключи должны быть доступны той учётной записи, от имени которой она запущена. Справка 1С-ЭДО описывает это прямо: по умолчанию служба работает от пользователя USR1CV8, но администратор мог назначить другую запись, поэтому настраивать криптографию нужно под тем пользователем, под которым служба реально запущена.

Узнать эту учётную запись можно одной командой в PowerShell на сервере 1С:

Get-CimInstance Win32_Service | Where-Object { $_.PathName -like '*ragent.exe*' } | Select-Object Name, DisplayName, StartName, State

Фильтрую по исполняемому файлу агента ragent.exe, а не по отображаемому имени: в русской установке оно звучит как «Агент сервера 1С:Предприятия», и буква «С» там бывает кириллической, так что фильтр по латинскому «1C» службу просто не найдёт. В колонке StartName будет имя пользователя службы. Дальше по справке 1С-ЭДО нужно войти на сервер под этой записью, установить криптопровайдер, положить контейнеры с закрытыми ключами туда, где они доступны этой записи, и установить личные и корневые сертификаты. Достаточно установки «для текущего пользователя», установка «для компьютера» не требуется. После этого в 1С в разделе «Администрирование — Общие настройки — Электронная подпись и шифрование» включаются опции «Проверять подписи и сертификаты на сервере» и «Подписывать на сервере».

Какой режим выбираю я? Для бухгалтеров, которые подписывают документы и отчётность руками из своей сессии, я оставляю «на клиенте» и учу контейнеры жить в сессии: так у каждого человека своя подпись и свой токен, и никто не подписывает чужим ключом. Режим «на сервере» включаю там, где нужны регламентные задания, например автоматический обмен ЭДО без участия человека: сессии пользователя в этот момент нет, а служба есть. Про сам терминальный сервер под бухгалтерию, ресурсы и RDS я уже рассказывал в статье про терминальный сервер 1С для бухгалтерии, здесь я его не повторяю и говорю только про подпись.

• «на клиенте» — подпись считает процесс клиента 1С в RDP-сессии; ключ должен быть виден в сессии (токен по RDP или контейнер в профиле пользователя)
• «на сервере» — подпись считает служба «Агент сервера 1С:Предприятия»; ключ должен быть доступен её учётной записи (по умолчанию USR1CV8)
• регламентные задания без человека работают только с серверным режимом: в сессии пользователя в этот момент никого нет
• проверить, под кем работает служба, до любой установки: Get-CimInstance Win32_Service, поле StartName

Какая лицензия КриптоПро нужна на терминальном сервере

Вопрос лицензии я задаю клиенту ещё до выезда, потому что здесь чаще всего экономят неправильно. Картина, которую я наблюдаю в проектах: у каждого бухгалтера на старом рабочем месте стояла «пользовательская» лицензия КриптоПро CSP на рабочее место, и при переезде в терминал её просто перенесли на сервер. Так нельзя, и это написано не на форуме, а в официальном прайс-листе КриптоПро прямо под позицией лицензии на рабочее место: «Лицензия на рабочее место не позволит использовать КриптоПро CSP в среде серверных операционных систем». Для Windows Server в том же прайсе есть отдельная позиция — лицензия на право использования КриптоПро CSP 5.0 на сервере. Для терминального сервера с несколькими пользователями речь идёт об одной серверной лицензии на сервер, а не о лицензиях на каждого пользователя: так на форуме cryptopro.ru отвечали и сотрудники КриптоПро. Перед покупкой условия и цену всё равно подтвердите у поставщика: цифры в статье я не привожу, потому что прайс обновляется.

Дальше три тонкости, о которые спотыкаются. Первая: лицензия привязана к версии продукта. Лицензии от 4.0 принимал только первый релиз пятой версии (5.0 R1, сборка 5.0.11455), а начиная с 5.0 R2 нужна лицензия именно на 5.0. Для старой серверной лицензии 4.0 в прайсе КриптоПро есть отдельная позиция «обновление до версии 5.0 на сервере», так что при обновлении CSP сверяйте серийный номер с версией, а не надейтесь, что старый ключ подойдёт. Вторая: лицензия действует только там, где активирована, и никакого сервера лицензирования для рабочих мест у КриптоПро нет, то есть купленная «серверная» не раздаёт лицензии рабочим станциям. Третья: в сертификаты некоторых удостоверяющих центров встроена ограниченная лицензия на CSP. Сотрудник КриптоПро писал, что она корректно работает и на серверной ОС, но действует только при использовании того сертификата, в который встроена. Для одного сертификата это решение, для офиса с десятком подписей и несколькими версиями CSP это лотерея, и я на неё не рассчитываю.

Отдельно напомню про лицензии самой Windows: за терминальные подключения отвечают RDS CAL, и это не то же самое, что лицензия КриптоПро. По документации Microsoft, каждому пользователю или устройству, которое подключается к серверу сеансов, нужна RDS CAL (на пользователя или на устройство), а до установки сервера лицензирования действует льготный период 120 дней. Подробно про выбор режима и про то, что будет после льготного периода, я писал в статье про лицензирование RDS CAL. Здесь важно одно: если у вас в сессии начинает «отваливаться» всё сразу, а не только подпись, сначала проверьте CAL, а не КриптоПро.

Сводка по сценариям, как я её держу в голове: | Сценарий | Какая лицензия КриптоПро CSP | Что проверить | |---|---|---| | Терминальный сервер, несколько пользователей | серверная, одна на сервер | версия лицензии совпадает с версией CSP | | Служба сервера 1С подписывает без человека | серверная на сервере 1С | ключи доступны учётной записи службы | | Один сертификат со встроенной лицензией | встроенная, только для этого сертификата | условия УЦ; не рассчитывать на другие сертификаты | | Проверка идеи до покупки | пробная, около трёх месяцев (на странице продукта указано 90 дней) | дату окончания, чтобы не получить остановку в отчётный день |

Как пробросить токен ЭЦП в RDP-сессию терминального сервера

Если подпись лежит на токене (Рутокен, JaCarta и аналоги), а работает человек в сессии на сервере, токен нужно «увидеть» внутри сессии. Начинаю с клиентской стороны, потому что в половине случаев причина именно там. В окне подключения mstsc на вкладке «Локальные ресурсы» должны быть включены смарт-карты: сразу в кнопке «Подробнее» там есть отдельный флажок. Если вы раздаёте пользователям готовые .rdp-файлы, то в файле за это отвечает параметр redirectsmartcards. По справочнику Microsoft его значение по умолчанию равно 1, то есть смарт-карты перенаправляются, и в файле достаточно такой строки:

redirectsmartcards:i:1

Этот же справочник описывает и параметр usbdevicestoredirect для низкоуровневого проброса USB-устройств, но к нему я прибегаю только когда обычное перенаправление смарт-карт не помогло: чем проще путь, тем меньше шансов на сюрпризы после очередного обновления.

Серверная сторона — групповая политика. Параметр называется «Do not allow smart card device redirection» и находится в разделе Computer Configuration, Policies, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Device and Resource Redirection. По документации Microsoft, чтобы разрешить перенаправление смарт-карт, этот параметр нужно оставить в состоянии «Отключено» или «Не задано», а «Включено» его запрещает. После изменения политики сервер сеансов нужно перезагрузить, как написано в той же инструкции. И ещё одно правило, которое экономит часы: если перенаправление запрещено в одном месте и разрешено в другом, побеждает самое строгое. Разрешили в .rdp-файле, но запретили политикой на сервере, значит запрещено. Если на вашем сервере уже настроены ограничения для безопасности RDP, загляните в этот же раздел политик: перенаправление устройств часто закручивают заодно.

Проверка занимает минуту. Внутри RDP-сессии открываем командную строку или PowerShell и выполняем:

certutil -scinfo
Get-Service SCardSvr

Первая команда выводит список считывателей и карт, которые видны сессии; в документации Microsoft именно она приведена как способ проверить, что перенаправление работает. Вторая показывает состояние службы «Смарт-карты» (SCardSvr), которая должна работать и на клиенте, и на сервере. Если certutil видит токен, а КриптоПро нет, проблема уже не в RDP, а в самом провайдере.

Остаётся настройка КриптоПро. По обсуждениям на форуме cryptopro.ru, в сборках пятой линейки, начиная с 5.0.12600, на вкладке «Безопасность» панели КриптоПро CSP появилась кнопка «Включить службу локальных смарт-карт» для доступа к смарт-картам в терминальной сессии, а пользователю при этом нужны права администратора или членство в локальной группе «Пользователи локальных смарт-карт КриптоПро CSP». Это сведения с форума для конкретных сборок, поэтому сверяйте их с документацией на вашу версию CSP: в одной из тем после обновления проброс перестал работать у пользователей из этой группы, и участники связывали это со службой, а не с группой. Мой порядок: сначала mstsc и политика, потом certutil, и только потом кнопка в КриптоПро.

• mstsc: Локальные ресурсы, Подробнее, включить смарт-карты; в .rdp — redirectsmartcards:i:1
• политика сервера: «Do not allow smart card device redirection» — Отключено или Не задано; после изменения перезагрузить сервер
• проверка в сессии: certutil -scinfo и Get-Service SCardSvr
• КриптоПро 5.0 (с 5.0.12600): вкладка «Безопасность», служба локальных смарт-карт; сверить по документации своей сборки

Токен, реестр или серверный контейнер: где хранить ключ, если пользователей много

У клиентов до 50 мест я встречаю три способа хранения ключа на терминале, и у каждого своя цена. Токен остаётся у человека: ключ физически не покидает носитель, украсть его сложнее, а в сессии он виден через перенаправление. Минус: человек должен быть с токеном в тот момент, когда подписывает, и работа с домашнего ноутбука упирается в настройки клиента. Контейнер в реестре или на диске сервера удобнее в эксплуатации: подпись «живёт» на сервере и не зависит от рабочего места. Минус: это копия ключа на сервере, и вопрос, кто к ней имеет доступ, надо решать сразу. Серверный контейнер для службы 1С подходит только для сценариев «на сервере» и для автоматических обменов.

Есть подвох, который выясняется слишком поздно: ключ не всегда можно перенести. Если сертификат выпущен на токен с неизвлекаемым ключом, скопировать его в реестр сервера не получится, и тогда единственный вариант — перенаправление токена. Прежде чем обещать директору «перенесём всё на сервер», я проверяю у каждого сертификата, как он записан и можно ли его вообще экспортировать, и только потом пишу план. Это тот случай, когда лучше разочаровать на этапе оценки, чем в день сдачи отчётности.

Если ключи лежат в реестре на сервере, у каждого пользователя они должны оставаться своими. Форумные обсуждения описывают рабочую, хоть и ручную схему: администратор заходит на сервер под каждым пользователем, копирует контейнер и ставит сертификат в «Личные» этого пользователя. Предупреждение оттуда же: если не ограничить права, продвинутый пользователь может поставить себе чужой сертификат. Поэтому доступ к хранилищам и каталогам с контейнерами я ограничиваю по пользователям и не складываю ключи в общую папку «для всех». О том, как вообще хранить носители подписи в организации, где подписей много и тендеры идут круглый год, я писал в статье про хранение токенов ЭЦП.

Ошибки подписи в 1С на терминальном сервере: симптом, причина, что делать

Из того, что я вижу в обращениях, 80 % случаев сводятся к пяти симптомам. Самый частый документирован самой 1С: «Не удалось выполнить операции формирования/проверки ЭЦП на сервере» с кодами 103 и 104. Справка 1С-ЭДО (страница обновлена 28.07.2025) предлагает два пути: перевести в настройках криптографии на вкладке «Общие» параметры «Выполнять криптографические операции» и «Выполнять авторизацию» на «на клиенте», при этом провайдер и ключи должны быть доступны там, где работает клиент; либо, если операции остаются на сервере, установить ключи в профиль учётной записи, под которой работает служба «Агент сервера 1С:Предприятия 8». Обратите внимание на формулировку: ошибка про доступность ключа учётной записи службы, а не про «сломанный КриптоПро».

Вторая типовая история: токен не виден в сессии. Дальше по дереву решений идёт проверка клиента (флажок смарт-карт), затем политики на сервере, потом службы SCardSvr, потом КриптоПро. Третья история: ключи видит администратор, а обычный пользователь нет. В обсуждениях на форуме КриптоПро в таких случаях указывали на права администратора или на группу «Пользователи локальных смарт-карт КриптоПро CSP». Четвёртая: сертификат есть, но 1С пишет, что не находит нужный провайдер. Тип провайдера в сертификате должен соответствовать установленному: для КриптоПро CSP с ГОСТ 2012 справка 1С-ЭДО указывает «Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider», тип программы 80. Пятая: лицензия. Срок пробной истёк или стоит клиентская на серверной ОС, и подпись вдруг перестаёт работать.

Свожу в таблицу, чтобы можно было прикрепить к стене у дежурного администратора: | Симптом | Вероятная причина | Что делаю | |---|---|---| | Ошибка 103/104 при подписи на сервере | ключ или провайдер недоступны учётной записи службы 1С | поставить ключ в профиль этой записи или перевести режим на «на клиенте» | | Токен не виден в сессии | не включены смарт-карты в mstsc, запрет политикой, не работает SCardSvr | флажок в mstsc, политика «Do not allow smart card device redirection», certutil -scinfo | | Видит администратор, пользователь нет | нет прав на службу смарт-карт КриптоПро | группа «Пользователи локальных смарт-карт КриптоПро CSP», проверка по документации сборки | | 1С не находит провайдера | тип провайдера в сертификате не совпал с установленным | сверить тип (80 для КриптоПро ГОСТ 2012) | | Работало, перестало в отчётный день | истёкла пробная или клиентская лицензия на сервере | серверная лицензия на нужную версию CSP |

Если подпись «тормозит» или пользователи жалуются на задержки при работе в 1С, проверьте сначала сам терминал, а не криптографию. Со временем отклика сессий и тонким клиентом на медленных каналах я разбирался в статье про тонкий клиент 1С на терминальном сервере: подпись только сделала проблему заметной, а причина лежит в канале и в профиле.

Кейс: отель на 49 рабочих мест переехал на терминальный сервер и сохранил подпись

К нам обратился «Отель Гавань»: 49 рабочих мест, из них около 20 в администрации и бухгалтерии, остальные — стойка, служба номерного фонда, кухня и склад. 1С работала в файловом режиме на сетевых папках, отчётность и ЭДО уходили с рабочих мест бухгалтерии. Директор хотел вынести 1С на терминальный сервер: бухгалтеры нередко работали из дома, а вечерами файловая база тормозила. Подписей было семь: главный бухгалтер, два бухгалтера, кадровик, финансовый директор, директор и специалист по закупкам.

Исходное состояние было типичным: три подписи на токенах, воткнутых в рабочие компьютеры, четыре контейнера в реестре разных рабочих станций, а лицензии КриптоПро на рабочее место, купленные в разные годы под разные версии. Сначала я составил реестр: кто чем подписывает, на каком носителе, какая версия CSP и какая лицензия, можно ли экспортировать ключ. Два из четырёх реестровых контейнеров оказались с просроченными лицензиями, один сертификат был на токене с неизвлекаемым ключом, и значит, его надо было пробрасывать, а не переносить.

Схема, которую мы сделали: Windows Server 2022 с ролью RDS, КриптоПро CSP на сервере с одной серверной лицензией на нужную версию, 1С переведена в клиент-серверный режим, подпись пользователей — «на клиенте» в сессии, регламентные обмены ЭДО — «на сервере» под отдельной учётной записью службы. Токены пробросили через смарт-карты в mstsc, на сервере проверили политику перенаправления, а контейнеры из реестра перенесли по одному под каждого пользователя. Для сертификата с неизвлекаемым ключом настроили токен на клиентском компьютере и перенаправление в сессию.

Сроки: два рабочих дня на подготовку и реестр подписей, день на установку и лицензирование, ещё два дня — по группам пользователей с проверкой реальной подписи и отправки отчётности в тестовом режиме, и неделя наблюдения. Итог: все семь подписей работали в терминальной сессии, никаких «переносов ключей наугад» не было, а при подключении из дома остался единственный пользовательский шаг — не снимать флажок смарт-карт в mstsc. Я не приукрашиваю: два пользователя в первую неделю пришли с вопросом «подпись не видна», и в обоих случаях причиной был снятый флажок на клиенте. Поэтому готовый .rdp-файл с redirectsmartcards:i:1 мы теперь отдаём им сразу.

Частые вопросы