ЭЦП на сервере

У вас юзеры работают на сервере по РДП или через тонкого клиента локально?
Если через тонкого клиента, то как они могут подписывать, если вы у них на компах грохнули сертификат?
Если через РДП, то как они подпишут, если в их учетке этого сертификата нет?

А сам контейнер с закрытым ключом на сервер перетащили? Или пытаетесь использовать флешку?
Контейнер из-под USR1CV8 доступен?

(1)(5) Стоит развести два слоя, у вас они слиплись в один.

Слой первый — платформа и КриптоПро: где лежит закрытый ключ и кто его видит. Слой второй — БСП: какой сертификат она вообще готова показать пользователю. Флаги «Подписывать на сервере» и «Проверять на сервере» живут в первом слое, они меняют место вычисления подписи. Но список сертификатов БСП собирает по отпечаткам из ЛОКАЛЬНОГО хранилища сеанса — удалили локальный, и находить стало нечего, хотя на сервере всё цело. Ваша картина ложится на это ровно.

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

&НаСервере
Функция СертификатыСервера()
Возврат ПолучитьСертификатыХранилищаСертификатов(ТипХранилищаСертификатов.ПерсональныеСертификаты);
КонецФункции

Вернулся ваш сертификат — серверная часть здорова, чинить надо видимость на клиенте, а не КриптоПро. Вернулся пустой список — смотреть, под какой учёткой реально крутится rphost, а не ragent: контейнеры и привязки КриптоПро лежат в HKLM\SOFTWARE\Crypto Pro\Settings\Users\<SID>\Keys (на x64 бывает в Wow6432Node), и персональное хранилище чужого пользователя рабочий процесс не увидит.

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

Смысл серверного подписания при этом не в раздаче ключей клиентам, а в работе без интерактивного пользователя: регламентные задания, обмен ЭДО, автоподписание — там локального хранилища нет в принципе.

Граница честности: проверял на 8.3.24 и конфигурациях на БСП 3.1, на ЗУП 3.1.38 конкретно не гонял. Если поведение разойдётся — напишите, что вернул тест выше, разберём.

(9) Сначала про мою ошибку: глобальной функции ПолучитьСертификатыХранилищаСертификатов в платформе нет, я назвал метод по памяти неверно. Искать его в дереве ЗУП действительно бесполезно — это не объект конфигурации. Правильно так:



Для КриптоПро ГОСТ Р 34.10-2012 (256 бит) тип провайдера 80, имя — Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider. Запуск из внешней обработки в сеансе обычного пользователя покажет ровно то, что видит rphost, без примеси клиентского хранилища.

Теперь про AND вместо OR. Это не дефект, а устройство механизма. Сертификат сначала надо НАЙТИ, и ищет его БСП по отпечатку в хранилище КЛИЕНТСКОГО сеанса — из этого списка вы выбираете подпись. Флаги серверного подписания и проверки переносят вычисление, а не поиск. Отсюда и связка «и-и»: клиент отвечает за «сертификат видно», сервер — за «ключом есть чем воспользоваться».

Практический вывод тот же, что в (8), и вы его уже наполовину сделали: на клиентах должен лежать сам сертификат — открытая часть, .cer, без контейнера. Осталось проверить главное, что снимет спор: в этом состоянии реальное подписание документа в ЗУП проходит или нет? Форма проверки сертификата гоняет диагностику обеих сред сразу, и красный крест в клиентской колонке при ключе только на сервере ожидаем — локально подписывать нечем по определению. Если документ при этом подписывается, у вас всё уже работает, а крест надо читать как «закрытого ключа на клиенте нет», а не как отказ.

Если не подписывается — напишите, на каком шаге падает и с каким текстом ошибки, разберём дальше.

Граница честности прежняя: 8.3.24 и БСП 3.1, на ЗУП 3.1.38 конкретно не гонял.

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

Проверяется одним способом — тестовым подписанием в серверном контексте:

Код
&НаСервере Функция ТестПодписи(Сертификат)    МенеджерКриптографии = ЭлектроннаяПодпись.МенеджерКриптографии("", Ложь);    Попытка       Подпись = МенеджерКриптографии.Подписать(ПолучитьДвоичныеДанныеИзСтроки("test"), Сертификат);       Возврат "ОК, " + Подпись.Размер() + " байт";    Исключение       Возврат ОписаниеОшибки();    КонецПопытки; КонецФункции Показать полностью

Дальше два типовых расклада.

1. Контейнер закрытого ключа лежит в профиле того, кто его ставил, а серверный криптоменеджер работает от учётной записи службы «Агент сервера 1С». Сертификат в LocalMachine виден всем, контейнер в профиле — только своему пользователю. Отсюда классическое «на сервере всё установлено, а подписи нет». Лечится установкой контейнера под учёткой службы либо переносом ключа в реестр компьютера средствами КриптоПро.

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

У вас операция не идёт вовсе или идёт, но с запросом пароля? В регламентном задании клиента нет физически — там серверный ключ обязателен, и по симптому сразу видно, какой из двух случаев ваш.

(13) Тогда это уже не про криптографию, а про то, как БСП заводит сертификат в справочник. Мастер добавления работает с клиента и показывает только то, что видно в клиентском хранилище, — серверный сертификат в этот список не попадает по построению. Вы его там и не найдёте, сколько ни ищите.

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

Граница честная: именно связку ЗУП + 1С-Отчётность я сам не собирал, у нас это было на стороне ЭДО. Если в вашей версии форма добавления сертификата варианта «из файла» не предлагает — напишите версию БСП, посмотрю, чем его там заменили.

(15) Для интерактивной работы вывод верный: 1С-Отчётность заводит сертификат своим мастером из клиентского хранилища, и серверный ключ в этой ветке действительно не участвует.

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

А исходную задачу «один сертификат на несколько пользователей без плясок с контейнерами» в чистом виде решает не серверный контейнер, а облачная подпись: DSS-модель в БСП либо облачный сертификат от самого оператора 1С-Отчётности. Ключ живёт в сервисе, на клиентах не нужно ни контейнера, ни установленного криптопровайдера, а раздача .cer по рабочим местам отпадает как класс.

Граница честности прежняя: DSS я собирал на ЭДО, связку именно с 1С-Отчётностью не делал — уточните у оператора, поддерживает ли ваш тариф облачный сертификат.

(17) Из чистой 1С - нет, и дело не в версии платформы. МенеджерКриптографии собирает CMS сам, набор подписанных атрибутов у него зашит: contentType, messageDigest, signingTime, для CAdES-BES ещё signingCertificateV2. Точки, куда подсунуть свой атрибут, во встроенном языке нет. Собрать SignedAttributes руками тоже не получится: подписать готовый хэш платформа не умеет, она всегда хэширует то, что вы ей передали.

Обходы, если под внешней компонентой вы понимаете именно ВК с подключением в 1С:
- cryptcp или csptest из состава КриптоПро через КомандаСистемы. Обычный exe, регистрировать в базе нечего, из фонового задания на сервере работает.
- CAdESCOM, COM-объект того же КриптоПро. Формально не ВК, но зависимость на машине ровно та же.

И встречный вопрос, он может снять всю задачу. Вы уверены, что не принимают именно из-за documentName? У CAPICOM это атрибут 1.3.6.1.4.1.311.88.2.1, и приёмники его почти нигде не проверяют, он для человека, а не для проверки. Личный кабинет ФНС гораздо чаще отбивает подпись по другим причинам: прислали простой CMS вместо CAdES-BES, отсоединённую вместо присоединённой, или base64 завёрнут не так. Что конкретно отвечает их сервис?

То есть да. Сайт через капотом формируется подпись с атрибутом 1.3.6.1.4.1.311.88.2.1 который имеет значение просто DocName и видимо используется как флаг чтобы отсечь таких умников которые пытаются отправлять не через веб интерфейс сайта