1С-ЭДО Настройка криптопровайдера КриптоПРО для работы с 1С-ЭДО

Что требуется для юридически значимого документооборота?

«Настоящее» использование электронного документооборота в последнее время быстрее всего развивается в области обмена юридически значимыми документами с внешними контрагентами.

Так, в налоговую инспекцию нужно сдавать счета-фактуры либо исключительно на бумаге, либо в безбумажной форме (отправленный таким образом счет-фактура автоматически становится юридически значимым документом).

Что же значит этот термин – юридически значимый документооборот?

• В ФЗ № 149-ФЗ понятие «документированная информация» подразумевает, что кроме самой информации в документе необходимы реквизиты для ее идентификации. Кроме того, в этом же законе указано, что электронный документ как документированная информация, представленная в электронной форме», также должен содержать реквизитную часть.
• ГОСТ Р 51141-98, описывающий стандарты делопроизводства, дает понятие юридической силы документа и дополнительно определяет понятие официального. На практике определение юридической значимости применяется только к электронным документам, а в отношении бумажных используется лишь понятие «юридической силы».
• Закон № 63-ФЗ определяет равнозначность информации в электронном виде, подписанной квалифицированной электронной подписью, и документа на аналоговом носителе с собственноручной подписью, если закон однозначно не говорит о необходимости предоставления документа исключительно на бумаге.

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

Для активации поддержки юридически значимого документооборота включаем функциональную опцию «Использовать обмен электронными документами» в пункте «Настройка обмена данными-Настроек программы».

В подсистеме можно подключиться к сервису 1С-ЭДО или 1С-Такском для использования их в качестве провайдеров ЭДО.

Здесь же настраиваются профили настроек ЭДО.

По ссылке «Настройки ЭДО» можно перейти к настройкам обмена с конкретным контрагентом.

Как настроить сертификат ЭП в программе 1С:Документооборот 8

Настройка сертификата ЭП имеет два этапа: настройка программы и персональные настройки.

Настройка программы выполняется во вкладке «Настройка и администрирование» – «Настройка программы» – «Общие настройки» (рис. 2).

Рисунок 2

Для начала работы с ЭП необходимо:

1. Разрешить использовать электронные подписи в общих настройках программы (рис. 3).

Рисунок 3

2. Установить на рабочие компьютеры пользователей один или несколько криптопровайдеров и настроить их.

Для того чтобы остальные сотрудники смогли проверять электронные подписи, требуется установить флаг “Проверять подписи и сертификаты на сервере” (рис. 4), затем выполнить установку криптопровайдера на каждый компьютер кластера серверов “1С:Предприятия”.

Рисунок 4

По умолчанию в списке программ уже присутствуют два криптопровайдера: ViPNet CSP и КриптоПро CSP. Можно добавить любые другие программы. При этом в 1С:Документооборот 8 уже поставляются готовые настройки для Microsoft Enhanced CSP, ViPNet CSP, КриптоПро CSP, ЛИССИ CSP, Сигнал-КОМ CSP.

Персональные настройки ЭП

После того как администратор установил криптопровайдер и настроил профили криптографии, можно приступать к настройке рабочего места пользователя. Это делается в персональных настройках программы на закладке “Настройка и администрирование”:

Рисунок 5

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

Рисунок 6

В этом случае пользователю необходимо установить личный сертификат.

Рисунок 7

Для регистрации сертификата необходимо:

1. Выбрать назначение сертификата: для подписания и шифрования либо только для шифрования.

2. Выбрать сертификат, установленный на компьютере.

3. Ввести пароль сертификата для автоматического определения подходящих настроек программы ЭП и шифрования. Для того чтобы выбрать профиль настроек криптографии вручную, необходимо пропустить ввод пароля с помощью кнопки «Отмена».

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

Рисунок 8

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

Флаг «Обязательный сертификат» служит для пометки сертификата, предназначенного для расшифровки любого файла информационной базы при компрометации ключа. Такой сертификат автоматически добавляется в список сертификатов для расшифровки при каждом шифровании объектов информационной базы.

Любой из установленных сертификатов можно пометить на удаление. На статус подписей, удостоверенных этим сертификатом, это не повлияет.

Если на компьютере текущего пользователя зарегистрировано несколько сертификатов, то откроется окно с возможностью выбора требуемого сертификата.

Пользователь выбирает сертификат и вводит пароль к нему.

Пароль сертификата ЭП можно запомнить на время сеанса работы с программой. Для этого при подписании или расшифровке объекта информационной базы достаточно ввести пароль к сертификату и установить флаг “Запомнить пароль”. Если флаг установлен, то до закрытия программы текущему пользователю не придется вводить пароль сертификата ЭП при каждом подписании или расшифровке.

Если сертификат выпущен с усиленной защитой закрытого ключа, то пароль вводится в отдельном окне операционной системы после нажатия кнопки «Готово». После этого документ (файл) будет подписан по алгоритму криптопровайдера, соответствующего этому сертификату.

Подписанный ЭП документ или файл недоступен для редактирования. Чтобы внести изменения в документ, потребуется удалить все подписи. Каждый пользователь может удалить только свои подписи. Право удаления всех подписей принадлежит администратору.

Подписание резолюций и виз согласования ЭП

Рисунок 9

Резолюция может быть подписана сертификатами, выпущенными на разных провайдерах ЭП.

Обратите внимание: подписанная ЭП резолюция становится недоступна для редактирования. Изменить резолюцию можно только после удаления всех ее ЭП.

Статусы проверки ЭП резолюций отображаются на закладке «Резолюции и визы карточки документа». Синий значок говорит о том, что подпись еще не проходила проверку. Зеленый – прошла проверку и получила статус Действительна либо Действительна, но нет доверия к сертификату. Красный – подпись недействительна.

Рисунок 10

Проверка наличия ЭП резолюций и виз

В зависимости от правил документооборота на предприятии электронная подпись резолюции и визы может считаться либо обязательной, либо нет. Для этого в программе предусмотрено несколько режимов настроек.

Для того чтобы заверение резолюций электронной подписью было обязательным для определенного вида документа, предусмотрен Флаг «Подписывать резолюции электронной подписью» на закладке Настройки карточки вида документа.

Рисунок 11

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

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

Проверка сертификата

На командной панели карточки сертификата ЭП предусмотрена кнопка проверки сертификата.

Кнопка открывает окно с перечнем параметров проверки. Действительный сертификат должен пройти успешную проверку по всем параметрам.

Если проверка не прошла успешно, необходимо нажать на иконку для получения информации об ошибке.

Рисунок 12

Статус проверки электронной подписи сохраняется в информационной базе и отображается в карточке электронной подписи, карточках и списках всех подписываемых объектов.

Проверка подписи и сертификата выполняется раздельно и присваивает электронной подписи один из общих статусов:

■ Действительна – если действительны и подпись, и сертификат;

■ Действительна, но нет доверия к сертификату – если действительна только подпись, но не сертификат;

■ Недействительна – если недействительны ни подпись, ни сертификат.

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

Рисунок 13

Помимо статуса подписи, в карточке ЭП можно ознакомиться с причиной отрицательного результата проверки, датой подписания, владельцем сертификата и перейти в карточку сертификата.

Подпись можно сохранить в файл (например, для дальнейшей пересылки по электронной почте). Расширение файла указывается в персональных настройках ЭП. По умолчанию это p7s. 

Ситуация: недействителен сертификат или электронная подпись

Ниже перечислены наиболее частые причины, по которым недействительный сертификат может быть признан таковым:

■ Требуемый сертификат не прошел проверки по сроку действия при сверке с системными часами или временем подписи в файле. Это означает, что на момент проверки срок действия сертификата истек.

■ Цепочка сертификатов обработана, но прервана на корневом сертификате, который не является доверенным. Это значит, что программе не удается построить цепочку сертификатов для доверенного корневого центра. При этом необходимо проверить:

○ установлены ли на компьютере все сертификаты корневых и подчиненных удостоверяющих центров и действительны ли они;

○ установлен ли список отозванных сертификатов (файл с расширением CRL) и есть ли доступ до OCSP-службы.

■ Не удалось проверить сертификат в списке отозванных, так как соответствующий сервер находится в состоянии offline – в этом случае необходимо запросить список отозванных сертификатов в удостоверяющем центре, выдавшем сертификат, и установить этот список в ОС (файл с расширением CRL). Обратите внимание, что у этого списка ограниченный срок действия, поэтому его необходимо время от времени обновлять.

Если недействительна сама электронная подпись, обратитесь к администратору для проверки общих настроек криптопровайдера и используемого профиля криптографии (Настройка и администрирование – Настройка программы – Настройки криптографии). Неправильно установленные настройки могут стать причиной ошибки вида: Ошибка при получении контекста модуля криптографии, Ошибка при вызове метода контекста и т. п.

Хеш-значение неправильное – ЭП не соответствует подписанным данным. В качестве проверки убедитесь, что данные не были изменены после подписания:

■ Внутри программы 1С:Документооборот 8 изменение подписанных данных исключено (так как подписанный файл закрыт от редактирования), но целостность файла не гарантируется при хранении в томах.

■ Данные могли исказиться при отправке через почтовые программы (например, почтовая программа может добавлять в метаданные пересылаемого файла дополнительную информацию).

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

Шифрование и расшифровка файлов

Шифрование предназначено для защиты информации от несанкционированного доступа. В функционал 1С:Документооборот входит шифрование информации для защиты от несанкционированного доступа. Расшифровать файл можно только с помощью закрытого ключа одного из сертификатов.

Так же в программе реализована возможность ограничения доступа к файлу с помощью прав доступа. Минус этого варианта – файл будет доступен администратору базы. Только если зашифровать файл сертификатом сотрудника, невозможно будет расшифровать файл без ключа сертификата.

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

Зашифровать и расшифровать можно любой файл с помощью группы команд ЭП в подменю “Еще” карточки и списка файлов (рис. 14).

Рисунок 14

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

Существуют особенности шифрования файлов:

■ шифруются все версии файла;

■ зашифрованный файл можно копировать, копия останется зашифрованной;

■ зашифрованный файл запрещено редактировать;

■ для зашифрованных файлов не работает полнотекстовый поиск;

■ зашифрованный файл нельзя подписать ЭП, но подписанный ЭП файл можно зашифровать. Программа позволяет проверить подписи зашифрованного файла, причем при выполнении этой операции файл остается зашифрованным.

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

Обязательный сертификат должен быть привязан к каждой из установленных программ шифрования. Для этого в настройках ЭП и шифрования предусмотрена колонка Обязательный сертификат для шифрования. 

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

Обязательных сертификатов может быть несколько. Например, если помимо корпоративного сертификата уполномоченный сотрудник (контролер) хочет иметь доступ к расшифровке всех файлов информационной базы с помощью личного сертификата. Для этого в карточке сертификата достаточно установить Флаг Обязательный для шифрования (рис. 15).

Рисунок 15

Специалист компании ООО «Кодерлайн»

Кристина Удалова

Google chrome / chromium

Как уже было сказано, при работе на Linux, Google Chrome использует библиотеку Mozilla Network Security Services (NSS) для выполнения верификации сертификатов.

Корневые CA сертификаты, которые добавил пользователь, хранятся в файле ~/.pki/nssdb/cert9.db, их можно просмотреть командой:

certutil -L -d ~/.pki/nssdb

Поскольку Chrome не может удалить сертификаты из хранилища NSS, то если вы отключите некоторые из них в настройках веб браузера (Privacy and security → Manage certificates → Authorities), то в том же файле, где хранятся добавленные пользователем корневые CA сертификаты, будут сохранены изменения о полномочиях отключённого сертификата:

Используемые в Google Chrome / Chromium корневые CA сертификаты в Linux можно посмотреть следующим причудливым способом:

1. Найдите расположение файла libnssckbi.so (как было сказано в предыдущем разделе, в нём NSS хранит доверенные корневые сертификаты):

locate libnssckbi.so

Примеры расположений этого файла:

• /usr/lib/libnssckbi.so
• /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so

2. Теперь выполните команду вида:

ln -s /ПУТЬ/ДО/libnssckbi.so ~/.pki/nssdb

Например:

ln -s /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so ~/.pki/nssdb

2. Затем запустите команду:

certutil -L -d sql:$HOME/.pki/nssdb/ -h 'Builtin Object Token'

Вы увидите доверенные корневые сертификаты, которые использует Google Chrome в Linux.

Также вы можете просмотреть корневые CA сертификаты в настройках браузера:

Конфиденциальность и безопасность (выбрать «Ещё») → Настроить сертификаты → Центры сертификации, на английском это Privacy and security → Manage certificates → Authorities.

Mozilla network security services (nss)

Network Security Services (NSS) это набор библиотек, разработанных для поддержки кросс-платформенной разработки защищенных клиентских и серверных приложений. Приложения построенные с использование NSS могут использовать SSL v2 и v3, TLS, PKCS#5, PKCS#7, PKCS#11, PKCS#12, S/MIME, сертификаты X.509 v3 и другие стандарты обеспечения безопасности.

В отличие от OpenSSL, NSS использует файлы базы данных в качестве хранилища сертификатов.

NSS начинается с жёстко закодированного списка доверенных сертификатов CA внутри файла libnssckbi.so. Этот список можно просмотреть из любого приложения, использующего NSS, способного отображать (и манипулировать) хранилищем доверенных сертификатов, например, Chrome-совместимые или Firefox-совместимые браузеры.

Некоторые приложения, использующие библиотеку NSS, используют хранилище сертификатов, отличное от рекомендованного. Собственный Firefox от Mozilla является ярким примером этого.

В вашем дистрибутиве скорее всего уже установлен пакет NSS, в некоторых дистрибутивах он называется libnss3 (Debian и производные) в некоторых — nss (Arch Linux, Gentoo и производные).

Если вы хотите просматривать и изменять хранилища сертификатов NSS, то понадобиться утилита certutil. В Arch Linux эта утилита входит в пакет nss и, следовательно, предустановлена в Arch Linux. А в Debian и производные установка делается так:

sudo apt install libnss3-tools

Если используется свд

В 1С:Документооборот есть уникальный функционал сервера внешнего документооборота, когда происходит автоматический обмен электронными документами с контрагентами, также использующими 1С:Документооборот, без промежуточных провайдеров и подключений.

Если в системе используется СВД и настроен обмен электронными документами между контрагентами с ЭП, при регистрации исходящего документа программа автоматически потребует подписать его ЭП. При поступлении входящего документа система автоматически проверит статус его ЭП.

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

Как добавить корневой сертификат в доверенные в linux на уровне системы

Сертификат с расширением .crt можно открыть двойным кликом и просмотреть его содержимое:

Если вы работаете в системе от обычного пользователя (не root), то кнопка «Импортировать» будет недоступна.

Чтобы разблокировать кнопку «Импортировать», выполните следующую команду:

sudo gcr-viewer /ПУТЬ/ДО/СЕРТИФИКАТА.crt

Например:

sudo gcr-viewer ./HackWareCA.crt

Данный способ может не сработать, поэтому рассмотрим, как добавить доверенные корневые центры сертификации в командной строке.

Суть метода очень проста:

1. Добавить свой корневой CA сертификат в папку, предназначенную для таких сертификатов.
2. Запустить программу для обновления общесистемного списка сертификатов.

Пути и команды в разных дистрибутивах Linux чуть различаются.

Просмотреть Subject всех корневых CA сертификатов можно уже знакомой командой:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt

Для демонстрации я добавлю сертификат с Common Name, включающим «HackWare», тогда для проверки, имеется ли сертификат с таким именем среди корневых CA, я могу использовать команду:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare

Для добавления своего корневого CA в доверенные в Debian, Kali Linux, Linux Mint, Ubuntu и их производных:

1. Проверьте, существует ли директория /usr/local/share/ca-certificates:

ls -l /usr/local/share/ca-certificates

Если её ещё нет, то создайте:

sudo mkdir /usr/local/share/ca-certificates

Сертификат должен быть в формате PEM (обычно так и есть) и иметь расширение .crt — если расширение вашего сертификата .pem, то достаточно просто поменять на .crt.

2. Скопируйте ваш сертификат командой вида:

sudo cp СЕРТИФИКАТ.crt /usr/local/share/ca-certificates/

Например:

sudo cp ./HackWareCA.crt /usr/local/share/ca-certificates/

3. Запустите следующую команду для обновления общесистемного списка:

sudo update-ca-certificates

Пример вывода:

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

Adding debian:HackWareCA.pem
done.
done.

Проверим наличие нашего CA сертификата среди доверенных:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare

Сертификат успешно найден:

Чтобы его удалить:

sudo rm /usr/local/share/ca-certificates/СЕРТИФИКАТ.crt
sudo update-ca-certificates

Для добавления своего корневого CA в доверенные в Arch Linux, BlackArch и их производных:

1. Выполните команду вида:

sudo cp ./СЕРТИФИКАТ.crt /etc/ca-certificates/trust-source/anchors/

Например:

sudo cp ./HackWareCA.crt /etc/ca-certificates/trust-source/anchors/

2. Обновите общесистемный список доверенных CA:

sudo update-ca-trust

Чтобы удалить этот сертификат:

sudo rm /etc/ca-certificates/trust-source/anchors/СЕРТИФИКАТ.crt
sudo update-ca-trust

Настройка и диагностика криптопро csp

Проверим, видит ли криптографический провайдер наш токен и другие доступные типы носителей следующими командами:

/opt/cprocsp/bin/amd64/csptest -card -enum -v –v

/opt/cprocsp/bin/amd64/csptest -enum -info -type PP_ENUMREADERS | iconv -f cp1251

/opt/cprocsp/sbin/amd64/cpconfig -hardware reader -view -f cp1251

Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00 — это наш носитель.

Следуя инструкции КриптоПро CSP для Linux. Настройка, выполняем его регистрацию в криптографическом провайдере:

/opt/cprocsp/sbin/amd64/cpconfig -hardware reader -add "Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00"

В результате выполнения в конфигурационный файл /etc/opt/cprocsp/config64.iniв раздел [KeyDevicesPCSC] будет добавлена запись:

[KeyDevicesPCSC”Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00″Default]

Чтобы выполнить требования Формуляра, Правил пользования и Руководства администратора безопасности КриптоПро CSP:

Использование СКЗИ «КриптоПро CSP» версии 4.0 с выключенным режимом усиленного контроля использования ключей не допускается. Включение данного режима описано в документах ЖТЯИ.00087-01 91 02. Руководство администратора безопасности.

Необходимо включить режим усиленного контроля использования ключей:

/opt/cprocsp/sbin/amd64/cpconfig -ini 'configparameters' -add long StrengthenedKeyUsageControl 1

Проверяем, что режим включен:

cat /etc/opt/cprocsp/config64.ini | grep StrengthenedKeyUsageControl

Выполняем перезапуск службы криптографического провайдера:

/etc/init.d/cprocsp restart
/etc/init.d/cprocsp status

После перезапуска проверяем, что ошибок в работе провайдера с ключевыми носителями нет:

/opt/cprocsp/bin/amd64/csptest -keyset –verifycontext

/opt/cprocsp/bin/amd64/csptest -keyset -verifycontext -enum –unique

CSP (Type:80) v4.0.9017 KC2 Release Ver:4.0.9944 OS:Linux CPU:AMD64 FastCode:REA
AcquireContext: OK. HCRYPTPROV: 16052291
alfa_shark1                        |SCARDJACARTA_4E3900154029304CCC00E9F6
OK.
Total: SYS: 0.000 sec USR: 0.000 sec UTC: 4.560 sec
[ErrorCode: 0x00000000]

Причина 3

UPD 16.04.2021:

В процессе настройки среды и оборудования выяснилось, что носитель, первым оказавшийся в распоряжении, был вовсе не JaCarta PKI Nano, как ожидалось, а устройство работающее в режиме SafeNet Authentication Client eToken PRO.

UPD 16.04.2021: Некогда Банку требовалось устройство, которое могло бы работать в той же инфраструктуре, что и eToken PRO (Java). В качестве такого устройства компания “ЗАО Аладдин Р.Д.” предложила токен JaCarta PRO, который был выбран банком.

UPD 16.04.2021: Благодарю компанию Аладдин Р.Д., за то что помогли разобраться и установить истину.

В этой ошибке нет никаких политических и скрытых смыслов, а только техническая ошибка сотрудника при подготовке документов. Токен JaCarta PRO является продуктом компании ЗАО “Аладдин Р.Д.”. Апплет, выполняющий функциональную часть, разработан компанией “ЗАО Аладдин Р.Д”.

Этот eToken PRO относился к партии, выпущенной до 1 декабря 2021 года. После этой даты компания «Аладдин Р.Д.» прекратила продажу устройств eToken PRO (Java).

Забегая немного вперед, нужно сказать, что работа с ним настраивалась через соответствующие драйверы — SafenetAuthenticationClient-10.0.32-0.x86_64, которые можно получить только в поддержке Аладдин Р.Д. по отдельной online заявке.

В КриптоПро CSP для работы с этим токеном требовалось установить пакет cprocsp-rdr-emv-64 | EMV/Gemalto support module.

Данный токен определялся и откликался. При помощи утилиты SACTools из пакета SafenetAuthenticationClient можно было выполнить его инициализацию. Но при работе с СКЗИ он вел себя крайне странно и непредсказуемо.

Проявлялось это следующим образом, на команду:

csptest -keyset -cont '\.Aladdin R.D. JaCarta [SCR Interface] (205D325E5842) 00 00alfa_shark' -check 

Выдавался ответ, что все хорошо:

[ErrorCode: 0x00000000]

Но сразу после попытки зачитать ключи программно эта же проверка начинала выдавать ошибку:

[ErrorCode: 0x8009001a]

Согласно перечню кодов ошибок объектной модели компонентов Microsoft

NTE_KEYSET_ENTRY_BAD
0x8009001A
Keyset as registered is invalid.

«Невалидный набор ключей» — причина такого сообщения, возможно, кроется либо в старом чипе, прошивке и апплете Gemalto, либо в их драйверах для ОС, которые не поддерживают новые стандарты формирования ЭП и функции хэширования ГОСТ Р 34.10-2021 и ГОСТ Р 34.11-2021.

В таком состоянии токен блокировался. СКЗИ начинало показывать неактуальное состояние считывателя и ключевого контейнера. Перезапуск службы криптографического провайдера cprocsp, службы работы с токенами и смарт-картами pcscd и всей операционной системы не помогали, только повторная инициализация.

Справедливости ради требуется отметить, что SafeNet eToken PRO корректно работал с ключами ГОСТ Р 34.10-2001 в ОС Windows 7 и 10.

Можно было бы попробовать установить СКЗИ КриптоПро CSP 4.0 ФКН (Gemalto), но целевая задача — защитить наши ключи ЭП и шифрования с помощью сертифицированных ФСБ и ФСТЭК изделий семейства JaCarta, в которых поддерживаются новые стандарты.

Проблему удалось решить, взяв настоящий токен JaCarta PKI в (XL) обычном корпусе.

Но на попытки заставить работать Safenet eToken PRO времени было потрачено немало. Хотелось обратить на это внимание и, возможно, кого-то оградить от подобного.

Программное извлечение ключей

В общем виде пример извлечения закрытого ключа и сертификата открытого ключа из контейнера на токене с помощью КриптоПро Java CSP следующий:

import ru.CryptoPro.JCP.KeyStore.JCPPrivateKeyEntry;
import ru.CryptoPro.JCP.params.JCPProtectionParameter;


 KeyStore keyStore = KeyStore.getInstance("Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00", "JCSP");
            keyStore.load(null, null);

        JCPPrivateKeyEntry entry = null;
        X509Certificate certificate = null;
        PrivateKey privateKey = null;

        try {
         
            entry = (JCPPrivateKeyEntry) keyStore.getEntry(keyAlias,
                    new JCPProtectionParameter(pwd));
            
            certificate = (X509Certificate) entry.getCertificate();
            privateKey = entry.getPrivateKey();
         
        } catch (UnrecoverableEntryException | NullPointerException e) {
            LOGGER.log(Level.WARNING, PRIVATE_KEY_NOT_FOUND   keyAlias   ExceptionUtils.getFullStackTrace(e));
        }

Если действовать так:

Key key = keyStore.getKey(keyAlias, pwd);

то криптографический провайдер будет пытаться в системе отобразить через консоль или GUI окно запрос на ввод пароля к контейнеру.

Просмотр содержимого ключей и сертификатов

Мы можем подробно изучить содержимое всех созданных в OpenSSL файлов, а также при необходимости конвертировать их в другие форматы.

В следующих командах используются тестовые файлы со следующими именами:

Обратите внимание на расширения файлов — они могут отличаться от тех, которые используются в других инструкциях. Например, вместо .key и .crt может использоваться расширение .pem. Расширение файла не имеет особого значения кроме как служить подсказкой пользователю, что именно находится в этом файле. Это же самое касается и имён файлов — вы можете выбирать любые имена.

Все эти файлы являются текстовыми:

cat rootCA.key

Там мы увидим примерно следующее:

-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDJBKkr6XzzAcXD
eyDQdvB0SWE2Fl3nqlX/c2RgqMgScXtgidEzOu9ms3Krju5UKLokkQJrZFPMtiIL
MuPJFdYjVyfkfnqlZiouBVgJ60s8NQBBI8KnyyAoJCIFdASoW4Kv5C5LT8pX9eRa
/huJaRJL5XsFUGnTOLvW2ZLN52iAux9CoZlmH6ZF4nuQpblwN0MHULAhze52VNFT
…………………………………………………..
…………………………………………………..
…………………………………………………..
…………………………………………………..
…………………………………………………..
…………………………………………………..
-----END PRIVATE KEY-----

Работа с токеном jacarta pki

Запустим программу Xming (X11 forwarding) на своей станции, чтобы по SSH иметь возможность открывать и работать с графическими интерфейсами нужных утилит.

После установки IDProtectClient — программного обеспечения для работы с JaCarta PKI, на сервере в папке /usr/share/applications появились два файла:

Athena-IDProtectClient.desktopAthena-IDProtectManager.desktop

Это ярлыки, в которых можно посмотреть параметры запуска утилит Exec=/usr/bin/SACTools

Запустим утилиту IDProtectPINTool.

С помощью нее задаются и меняются PIN-коды доступа к токену.

/usr/bin/IDProtectPINTool

При первой инициализации токена будет полезна ссылка, содержащая PIN-коды (пароли) ключевых носителей по умолчанию

Программа IDProtect_Manager позволяет просматривать информацию о токене и контейнере с ключами и сертификатом:

/usr/bin/IDProtect_Manager

Для доступа к контейнеру с ключами нужно ввести пароль:

Для работы с SafeNet Authentication Client eToken PRO существуют аналогичные программы — SafeNet Authentication Client Monitor и SafeNet Authentication Client Tools, которые запускаются так:

/usr/bin/SACMonitor
/usr/bin/SACTools

Выполнять операции непосредственно с ключевыми контейнерами удобнее в интерфейсе криптографического провайдера КриптоПро JavaCSP:

/jdk1.8.0_181/jre/bin/java ru.CryptoPro.JCP.ControlPane.MainControlPane

Для отображения информации о содержимом контейнера с ключами можно выполнить команду:

/opt/cprocsp/bin/amd64/csptest -keyset -cont '\.Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00alfa_shark1' -info

Для диагностики контейнера используется эта же команда с ключом –check

/opt/cprocsp/bin/amd64/csptest -keyset -cont '\.Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00alfa_shark' –check

Потребуется ввести пароль от контейнера:

Создание ключа электронной подписи

Если требуется переиздание сертификата, перед отправкой помощник перейдет к шагу для создания ключа электронной подписи (рис. 5). Чтобы
приступить к созданию ключа, нажмите кнопку “Создать ключ электронной подписи”.

Рис. 5

Ключ электронной подписи генерируется с помощью программы-криптопровайдера. В зависимости от криптопровайдера, он может быть размещен на
внешнем устройстве или на компьютере пользователя. После выбора размещения электронного ключа будет предложено задать пароль (рис. 6).

При создании ключа для инициализации генератора случайных чисел потребуется в произвольном порядке нажимать клавиши на клавиатуре или двигать
мышью.

Рис. 6

После создания ключа электронной подписи заявление будет отправлено (рис. 7).

Рис. 7

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

Чтобы завершить изменение настроек подключения к 1С-Отчетности, необходимо дождаться одобрения заявления.

Создание корневого приватного ключа

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

Генерация приватного ключа RSA используя параметры по умолчанию (ключ будет сохранён в файл с именем rootCA.key):

openssl genpkey -algorithm RSA -out rootCA.key

Опция -out указывает на имя файла для сохранения, без этой опции файл будет выведен в стандартный вывод (на экран). Имя выходного файла не должно совпадать с именем входного файла.

Для безопасности ключа его следует защитить паролем. Генерация приватного ключа RSA используя 128-битное AES шифрование (-aes-128-cbc) и парольную фразу “hello” (-pass pass:hello):

openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc -pass pass:hello

Конечно, опцию -pass pass:hello можно не указывать, тогда вам будет предложено ввести пароль во время генерации ключа.

Список поддерживаемых симметричных алгоритмов шифрования приватного ключа можно узнать в документации (раздел SUPPORTED CIPHERS):

man enc

Если для генерируемого ключа не указано количество бит, то по умолчанию используется 2048, вы можете указать другое количество бит с помощью команды вида (будет создан 4096-битный ключ):

openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc -pkeyopt rsa_keygen_bits:4096

Создание файла с запросом на подпись сертификата (csr)

Получив закрытый ключ, вы можете приступить к созданию запроса на подпись сертификата — Certificate Signing Request (CSR). Это официальный запрос к CA о подписании сертификата, который содержит открытый ключ объекта, запрашивающего сертификат, и некоторую информацию об объекте.

Создание CSR обычно представляет собой интерактивный процесс, в ходе которого вы будете предоставлять элементы отличительного имени сертификата (вводить информацию о стране, городе, организации, email и т.д.). Внимательно прочитайте инструкции, предоставленные инструментом openssl; если вы хотите, чтобы поле было пустым, вы должны ввести одну точку (.) в строке, а не просто нажать «Enter».

Если вы сделаете последнее, OpenSSL заполнит соответствующее поле CSR значением по умолчанию. (Такое поведение не имеет никакого смысла при использовании с конфигурацией OpenSSL по умолчанию, что и делают практически все. Это имеет смысл, когда вы осознаете, что можете изменить значения по умолчанию, либо изменив конфигурацию OpenSSL, либо предоставив свои собственные конфигурации в файлах).

В запросе на подпись сертификата вы указываете информацию для сертификата, который хотите сгенерировать. Этот запрос будет обработан владельцем корневого ключа (в данном случае вы его создали ранее) для генерации сертификата.

Важно: имейте в виду, что при создании запроса на подпись важно указать Common Name, предоставляющее IP-адрес или доменное имя для службы, в противном случае сертификат не может быть проверен.

Я опишу здесь два способа:

Установка драйверов и по для работы с jacarta pki

На странице Поддержки сайта «Аладдин Р.Д.» загружаем

Согласно Руководству по внедрению «JaCarta для Linux» пункт 4.2., первым делом требуется установить пакеты pcsc-lite, ccid и libusb.

Для работы утилиты управления JaCarta необходимо установить следующие компоненты:

• PC/SC Lite — промежуточный слой для обеспечения доступа к смарт-картам по стандарту PC/SC, пакет pcsc-lite.
• Библиотеки ccid и libusb для работы с USB-ключами, смарт-картами и считывателями смарт-карт.

Выполняем проверку наличия этих пакетов и установку:

zypper search pcsc-lite

zypper search libusb

zypper install pcsc-lite

zypper search CCID

zypper install pcsc-ccid

zypper search CCID

zypper install libusb

В итоге пакет pcsc-lite был обновлен, CCID установлен, libusb никаких действия не требовалось.

Следующими двумя командами выполняем установку пакета с драйверами и программным обеспечением непосредственно для работы с JaCarta PKI:

zypper install idprotectclientlib-637.03-0.x86_64.rpm

zypper install idprotectclient-637.03-0.x86_64.rpm

Проверяем, что драйверы и ПО для JaCarta PKI установились:

zypper search idprotectclient

При попытках заставить работать SafeNet eToken PRO я нашел информацию, что предустановленный в SLES пакет openct — Library for Smart Card Readers может конфликтовать с pcsc-lite — PCSC Smart Cards Library, установку которого требует руководство Аладдин Р.Д.

zypper search openct

Поэтому пакет openct удаляем:

rpm -e openct

Теперь все необходимые драйверы и ПО для работы с токеном установлены.

Выполняем диагностику с помощью утилиты pcsc-tools и убеждаемся, что JaCarta определяется в операционной системе:

pcsc_scan

Установка пакетов криптопро csp

При установке КриптоПро CSP по умолчанию нужные пакеты для работы с токенами и смарт-картами отсутствуют.

zypper search cprocsp

Выполняем установку в CSP компонента поддержки JaCarta components for CryptoPro CSP

zypper install cprocsp-rdr-jacarta-64-3.6.408.683-4.x86_64.rpm

Некоторые компоненты имеют зависимости. Так, например, если попытаться выполнить установку пакета поддержки SafeNet eToken PRO cprocsp-rdr-emv-64-4.0.9944-5.x86_64.rpm — EMV/Gemalto support module, то получим сообщение о необходимости сначала установить базовый компонент CSP поддержки считывателей cprocsp-rdr-pcsc-64-4.0.9944-5.x86_64.rpm — PC/SC components for CryptoPro CSP readers:

zypper install cprocsp-rdr-emv-64-4.0.9944-5.x86_64.rpm
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: nothing provides cprocsp-rdr-pcsc-64 >= 4.0 needed by cprocsp-rdr-emv-64-4.0.9944-5.x86_64
 Solution 1: do not install cprocsp-rdr-emv-64-4.0.9944-5.x86_64
 Solution 2: break cprocsp-rdr-emv-64-4.0.9944-5.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/c] (c): c

Устанавливаем базовые пакеты поддержки считывателей и ключевых носителей:

zypper install cprocsp-rdr-pcsc-64-4.0.9944-5.x86_64.rpm

zypper install lsb-cprocsp-pkcs11-64-4.0.9944-5.x86_64.rpm

Теперь можно установить модули для работы с остальными видами носителей и компонент GUI:

zypper install cprocsp-rdr-emv-64-4.0.9944-5.x86_64.rpm

zypper install cprocsp-rdr-novacard-64-4.0.9944-5.x86_64.rpm
zypper install cprocsp-rdr-mskey-64-4.0.9944-5.x86_64.rpm
zypper install cprocsp-rdr-gui-gtk-64-4.0.9944-5.x86_64.rpm

Проверяем итоговую конфигурацию КриптоПро CSP:

zypper search cprocsp
Loading repository data...
Reading installed packages...

S | Name | Summary | Type— —————————– —————————————————- ——–i | cprocsp-curl-64 | CryptoPro Curl shared library and binaris. Build 9944. | packagei | cprocsp-rdr-emv-64 | EMV/Gemalto support module | packagei | cprocsp-rdr-gui-gtk-64 | GUI components for CryptoPro CSP readers. Build 9944. | packagei | cprocsp-rdr-jacarta-64 | JaCarta components for CryptoPro CSP. Build 683. | packagei | cprocsp-rdr-mskey-64 | Mskey support module | packagei | cprocsp-rdr-novacard-64 | Novacard support module | packagei | cprocsp-rdr-pcsc-64 | PC/SC components for CryptoPro CSP readers. Build 9944.| packagei | lsb-cprocsp-base | CryptoPro CSP directories and scripts. Build 9944. | packagei | lsb-cprocsp-ca-certs | CA certificates. Build 9944. | packagei | lsb-cprocsp-capilite-64 | CryptoAPI lite. Build 9944. | packagei | lsb-cprocsp-kc2-64 | CryptoPro CSP KC2. Build 9944. | packagei | lsb-cprocsp-pkcs11-64 | CryptoPro PKCS11. Build 9944. | packagei | lsb-cprocsp-rdr-64 | CryptoPro CSP readers. Build 9944. | package

Чтобы применить изменения, выполняем перезапуск службы криптографического провайдера и проверяем ее статус:

/etc/init.d/cprocsp restart
/etc/init.d/cprocsp status

Цели применения эцп в 1с:документооборот

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

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

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

Также электронная подпись в 1С Документооборот применяется в визах согласования, резолюциях, решениях об утверждении, то есть во внутреннем документообороте. При этом механизм бизнес-процесса в 1С:Документооборот несет в своих настройках лишь один дополнительный признак – подписывать ЭП.

При согласовании такого документа от согласующего требуется подписать проставляемую визу личным сертификатом электронной подписи. После этого при малейшем изменении документа эта подпись становится недействительной. То есть виза, подписанная ЭП, будет относиться именно к той версии документа, на которую ее ставил согласующий.