криптопро для centos

На данный момент популярные операционные системы (Windows, macOS и др. ) по умолчанию не поддерживают российские криптографические алгоритмы, а для работы с электронной подписью, отвечающей требованиям закона, они необходимы. КриптоПро CSP – специализированное программное обеспечение, добавляющее в операционную систему вашего устройства необходимые алгоритмы работы с российской криптографией. Установка программы позволяет работать с электронной подписью соответствующей Федеральному закону № 63-ФЗ «Об электронной подписи».

В связи с переходом на Linux возникла необходимость переноса одной из наших серверных систем написанной на C# в Mono. Система работает с усиленными ЭЦП, поэтому одной из поставленных перед нами задач была проверка работоспособности ГОСТовых сертификатов от КриптоПро в mono. Сам КриптоПро уже довольно давно реализовал CSP под Linux, но первая же попытка использования показала, что нативные классы криптографии Mono (аналогичные тем, что есть в базовом. Net — X509Store, X509Certificate2 и проч. ) не только не работают с ГОСТовыми ключами, они даже не видят их в своих хранилищах. В силу этого работу с криптографией пришлось подключать напрямую через библиотеки КриптоПро.

Al Tinho, у меня похожий вопрос сегодня возник: есть приватный ключ в формате. reg файла (windows registry). Если открыть в блокноте, там видно header. key, primary. key, masks. key, primary2. key, masks2. key, выглядит так:
Windows Registry Editor Version 5

Вопрос 1): почему этих ключей так много? Я думал должен быть один приватный и один публичный (публичный, кстати, тоже есть в отдельном. cer файле)
Вопрос 2): как их использовать с консольными утилитами КриптоПро на Linux? Есть ли какой-то конвертер. reg -> ???

Навигация по записям

В данном разделе будет рассмотрен процесс установки и настройки «КриптоПро NGate
Клиент» для операционных систем семейства Linux. В данном разделе будет рассмотрен процесс установки и настройки «КриптоПро NGate Клиент» и криптопровайдера КриптоПро CSP для операционных систем семейства Linux. «КриптоПро NGate
Клиент» (или Клиент NGate) предназначен для обеспечения доступа пользователей
к ресурсам, защищаемым посредством шлюза NGate. В качестве демонстрации работоспособности клиента будут приведены инструкции для
подключения ктестовымшлюзам КриптоПро :

В качестве среды для примера настройки клиента будет использоваться ОС Astra Linux
Common Edition (Orel) 2. «КриптоПро NGate Клиент» предназначен для функционирования в следующих операционных
системах семейства Linux:

• ОС семейства Linux (только Исполнения 5 и 6):
• Red OS (x64);
• Fedora (x64);
• SUSE Linux Enterprise Server 12, Desktop 12 (x64);
• ОpenSUSE 13.2, Leap 42 (x64);
• Ubuntu 14.04/16.04 (x64);
• Ubuntu 17.04/17.10 (x64);
• Ubuntu 18.04/18.10 (x64);
• Linux Mint 13/14/15/16/17/18 (x64);
• Альт Сервер 8, Альт Рабочая станция 8, Альт Рабочая станция К 8 (x64);
• ROSA 2011, Fresh, Enterprise Desktop, Enterprise Linux Server (x64);
• РОСА ХРОМ/КОБАЛЬТ/НИКЕЛЬ (x64);
• ThinLinux (x64).

Устанавливаем необходимые пакеты

sudo apt-get install libccid pcscd opensc

Если предполагается использовать Рутокен S, устанавливаем драйвер Рутокен. Для Рутокен ЭЦП 2. 0/3. 0 этот шаг пропускаем.

cd ~/Downloadstar -xf linux-amd64_deb. tgzcd linux-amd64_debsudo. /install_gui. sh#Установить необходимые компоненты, например, как на скриншоте# Если необходима автоматическая установка, то можно использовать следующую командуsudo. /install. sh cprocsp-rdr-pcsc cprocsp-rdr-rutoken cprocsp-rdr-cryptoki# Ключ cprocsp-rdr-cryptoki указывается, если необходимо работать с библиотекой rtpkcs11ecp через КриптоПро CSP

Скачиваем и устанавливаем корневой сертификат УЦ.

В данном примере устанавливается корневой сертификат Тестового УЦ КриптоПро. Сертификаты, выданные данным УЦ, можно использовать только в тестовых целях.

Для просмотра доступных установленных контейнеров выполняем:

/opt/cprocsp/bin/amd64/csptest -keyset -enum_cont -verifycontext -fqcn

Скачиваем КриптоПро ЭЦП Browser plug-in.

cd ~/Downloadstar -xf cades_linux_amd64. tar. gzcd cades_linux_amd64 # Устанавливаем пакетыsudo dpkg -i cprocsp-pki-cades_*_amd64. debsudo dpkg -i cprocsp-pki-plugin_*_amd64. deb # Копируем файл libnpcades. so в папку с плагинами (если используется Firefox)sudo cp /opt/cprocsp/lib/amd64/libnpcades. so /usr/lib/firefox-addons/plugins/libnpcades

Для Google Chrome устанавливаем расширение CryptoPro Extension for CAdES Browser из магазина Chrome.

Перезапускаем браузер и заходим на тестовую страницу КриптоПро CSP.

• В отобразившемся окне выберите Продолжить установку.
• В следующем окне выберите Добавить.
• В отобразившемся окне нажмите ОК. Понятно.

В настройках плагинов браузера у CryptoPro CAdES plugin ставим значение Always Activate.

В данной статье мы описываем процесс установки и настройки КриптоПро CSP на ОС Linux (на примере Debian 11).

Она будет полезна вам, если вы получили ключ и сертификат в ФНС и используете ОС Linux для работы.

• КриптоПро CSP 5.0
• КриптоПро ЭЦП Browser plug-in 2.0

1) Установка КриптоПро CSP 5

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

Перейдите на страницу загрузки дистрибутивов КриптоПро CSP

Распакуйте загруженный архив: tar -xvf linux-amd64_deb. tgz && cd linux-amd64_deb

Запустите установку в графическом интерфейсе посредством запуска скрипта

При установке дополнительно нужно отметить пакеты

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

• pcscd (sudo apt-get install pcscd)
• libccid (sudo apt-get install libccid)
• Рутокен ЭЦП 2.0 – библиотека для работы через PKCS#11 интерфейс
• JaCarta-2 ГОСТ – Единый клиент JaCarta
• ESMART Token ГОСТ – ESMART PKI Client
• Рутокен S – пакет ifd-rutokens_1.0.4 расположен в архиве с ПО

установка скаченных выше библиотек PKCS#11 выполняется командой

sudo dpkg -i путь до скаченной библиотеки

убедитесь, что служба pcscd запущена sudo systemctl status pcscd

если нет запустите ее sudo systemctl enable –now pcscd

2) Установка КриптоПро ЭЦП BrowserPlug-in 2

Распакуйте загруженный архив: tar -xvf cades-linux-amd64. tar

3) Установка личного сертификата:

Установка личного сертификата с привязкой к ключевому контейнеру на ключевом носителе (при подключенном ключевом носителе):

Показать приложенияИнструменты КриптоПроКонтейнерыВыбрать нужный ключевой носительУстановить сертификат

Установка облачного сертификата описана в инструкции по ссылке

4) Проверить правильность настройки можно на тестовой странице проверки плагина.

Если настройка произведена корректно, то в поле Сертификат появится строка, соответствующая сертификату.

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

5) Проверка статуса лицензии КриптоПро CSP 5

6) Активация лицензии КриптоПро CSP 5

Показать приложенияИнструменты КриптоПроОбщееВвести лицензию для меня

a) При необходимости отдельной установки сертификатов

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

Показать приложенияИнструменты КриптоПроСертификатыУстановить сертификатывыбрать файл с нужным сертификатом

b) Для работы на портале nalog. ru необходимо:

– иметь в наличии квалифицированный сертификат электронной подписи и соответствующий ему ключ,

– для входа в личный кабинет ИП или ЮЛ с помощью электронной подписи использовать один из браузеров (рекомендуется использовать последнии доступные версии браузеров) с поддержкой ГОСТ TLS – Chromium-Gost или Яндекс. Браузер и входить по прямой ссылке:

c) Информация по входу на портал gosuslugi. ru доступна по ссылке.

Установка сертификата

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

Компонент КриптоПро CSP версии 3. 9 был установлен в Centos 7 в папку /opt/cprocsp. Для того, чтобы не было конфликтов между утилитами mono и КриптоПро, имеющих одинаковые названия (например, certmgr), в переменные окружения не стали вносить путь до папки и все утилиты вызывались по полному пути.

Если среди списка нет считывателя с папки на диске (HDIMAGE) ставим его:
/opt/cprocsp/sbin/amd64/cpconfig -hardware reader -add HDIMAGE store

Установленный сертификат можно увидеть с помощью следующей команды:
/opt/cprocsp/bin/amd64/certmgr -list mMy

Если с сертификатом все нормально, то можно переходить к подключению в коде.

Ссылки

• документация КриптоПро CAPILite
• ресурс c объявлением стандартных экспортируемых функций в С#
• исходники .Net:
  класс CAPIBaseкласс X509Certificate2класс SignedCMSкласс SignerInfo
• класс CAPIBase
• класс X509Certificate2
• класс SignedCMS
• класс SignerInfo
• исходники mono:
  класс X509Certificate2класс X509CertificateImplBtls
• класс X509CertificateImplBtls

Подключение в коде

Анализ методов библиотек криптографии оказался удачным, т. КриптоПро реализовало библиотеку «libcapi20. so» которая полностью мимикрирует под стандартные библиотеки Windows шифрования — «crypt32. dll» и «advapi32. dll». Возможно, конечно, не целиком, но все необходимые методы для работы с криптографии там в наличии, и почти все работают.

Поэтому формируем два статических класса «WCryptoAPI» и «LCryptoAPI» каждый из которых будет импортировать необходимый набор методов следующим образом:

Синтаксис подключения каждого из методов можно либо сформировать самостоятельно, либо воспользоваться сайтом pinvoke, либо скопировать из исходников. Net (класс CAPISafe). Из этого же модуля можно почерпнуть константы и структуры связанные с криптографией, наличие которых всегда облегчают жизнь при работе с внешними библиотеками.

А затем формируем статический класс «UCryptoAPI» который в зависимости от системы будет вызывать метод одного из двух классов:

Таким образом используя методы класса UCryptoAPI можно реализовывать почти единый код под обе системы.

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

Работа с криптографией обычно начинается с поиска сертификата, для этого в crypt32. dll имеется два метода CertOpenStore (открывает указанное хранилище сертификатов) и простой CertOpenSystemStore (открывает личные сертификаты пользователя). В силу того, что работа с сертификатами не ограничивается только личными сертификатами пользователя подключаем первый:

Поиск происходит в несколько этапов:

• открытие хранилища;
• формирование структуры данных по которым ищем;
• поиск сертификата;
• если требуется, то проверка сертификата (описана в отдельном разделе);

В ходе поиска сертификатов есть несколько тонких моментов.

КриптоПро в Linux работает с ANSI строками, а в Windows с UTF8, поэтому:

• передавая строку для поиска (например, по имени Subject) ее необходимо преобразовывать в набор байт различными кодировками;
• для всех констант криптования, у которых есть вариация по типу строки (например, CERT_FIND_SUBJECT_STR_A и CERT_FIND_SUBJECT_STR_W) в Windows необходимо выбирать *_W, а в Linux *_A;

Метод MapX509StoreFlags можно взять напрямую из исходников Microsoft без изменений, он просто формирует итоговую маску исходя из. Net флагов.

Значение по которому происходит поиск зависит от типа поиска (сверяйтесь с MSDN для CertFindCertificateInStore), в примере приведены два самых часто используемых варианта — для строкового формата (имена Subject, Issuer и проч) и бинарного (отпечаток, серийный номер).

Процесс создания сертификата из IntPtr в Windows и в Linux сильно отличается. Windows создаст сертификат простым способом:

в Linux же приходиться создавать сертификат в два этапа:

В дальнейшем нам для работы потребуется доступ к hCert, и его надо бы сохранить в объекте сертификата. В Windows его позже можно достать из свойства Handle, однако Linux преобразует структуру CERT_CONTEXT, лежащую по ссылке hCert, в ссылку на структуру x509_st (OpenSSL) и именно ее прописывает в Handle. Поэтому стоит создать наследника от X509Certificate2 (ISDP_X509Cert в примере), который сохранит у себя в отдельном поле hCert в обеих системах.

Не стоит забывать, что это ссылка на область неуправляемой памяти и ее надо освобождать после окончания работы. Net 4. 5 X509Certificate2 не Disposable — очистку методом CertFreeCertificateContext, надо проводить в деструкторе.

Формирование подписи

При работе с ГОСТовыми сертификатами почти всегда используются отцепленные подписи с одним подписантом. Для того чтобы создать такую подпись требуется довольно простой блок кода:

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

Метод подписания может получать один или несколько документов для одновременного подписания одной подписью. Это, кстати, не противоречит 63 ФЗ и бывает очень удобно, т. пользователь вряд ли обрадуется необходимости несколько раз нажимать на кнопку «подписать».

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

Единственной серьезной проблемой является поиск OID алгоритма хэширования (Digest) используемый при подписании — в явном виде его нет в сертификате (там есть только алгоритм самой подписи). И если в Windows его можно указать пустой строкой — он подцепится автоматически, но Linux откажется подписывать если алгоритм не тот.

Но тут есть хитрость — в информации об алгоритме подписи (структура CRYPT_OID_INFO) в pszOID храниться OID подписи, а в Algid — храниться идентификатор алгоритма хэширования. А преобразовать Algid в OID уже дело техники:

Получение OID алгоритма хэширования

Внимательно прочитав код можно удивится, что идентификатор алгоритма получается простым способом (CertOIDToAlgId) а Oid по нему — сложным (CryptFindOIDInfo). Логично было бы предположить использование либо оба сложных, либо оба простых способа, и в Linux оба варианта успешно работают. Однако в Windows сложный вариант получения идентификатора и простой получения OID работает нестабильно, поэтому стабильным решением будет вот такой странный гибрид.

Проверка подписи

Проверка подписи происходит в два этапа, в начале проверяется сама подпись, а затем проверяется сертификат, которым она была сформирована (цепочка, дата подписания и проч). Так же как и при подписании необходимо указать набор подписываемых данных, параметры подписи и саму подпись:

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

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

Извлечение информация из подписи

Часто в системах работающих с криптографией требуется печатное представление подписи. В каждом случае оно разное, поэтому лучше сформировать класс информации о подписи, который будет содержать информацию в удобном для использования виде и уже с его помощью обеспечивать печатное представление. Net такой класс есть — SignedCms, однако его аналог в mono c подписями КритоПро, во первых отказывается работать, во вторых содержит модификатор sealed и в третьих почти все свойства у него закрыты на запись, поэтому придется формировать свой аналог.

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

Чтение подписи происходит следующим образом:

Разбор подписи происходит в несколько этапов, вначале формируется структура сообщения (CryptMsgOpenToDecode), затем в нее вносятся реальные данные подписи (CryptMsgUpdate). Остается проверить что это реально подпись и получить сначала список сертификатов, а потом список подписантов. Список сертификатов извлекается последовательно :

Получение списка сертификатов

Сначала определятся количество сертификатов из параметра CMSG_CERT_COUNT_PARAM, а затем последовательно извлекается информация о каждом сертификате. Завершает процесс создания формирование контекста сертификата и на его основе самого сертификата.

Извлечение данных подписанта сложнее. В них содержится указание на сертификат и список параметров подписи (например, дата подписания). Процесс извлечения данных выглядит следующим образом:

Извлечение информации о подписанте

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

После извлечения сертификата необходимо определить параметры подписи, самая важная из которых — дата подписания (даже если это не верифицированная сервером штампа даты времени, для отображения она очень важна).

Список атрибутов подписи

Атрибуты представляют из себя вложенный справочник вида Oid – список значений (по сути это разобранная структура ASN. Пройдя по первому уровню формируем вложенный список:

Разобрать атрибут подписи

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

Обернув представленные выше методы в два класса — информация о подписи и информация о подписанте — получаем аналог SignedCms, из которой при формировании печатного вида извлекаем данные.

Шифрование

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

Процесс шифрования происходит в три этапа — заполнение параметров, определение длины и наконец шифрование. Зашифрованные данные могут быть большие, вероятно, поэтому метод поддерживает режим двух вызовов.

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

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

Получение алгоритма шифрования

В примере извлекается контекст закрытого ключа и по нему происходит поиск по алгоритмам. Но в этом списке находятся все алгоритмы (обмена ключей, хэширования, подписи, шифрования и проч. ), поэтому надо отфильтровать только алгоритмы шифрования. Пытаемся по каждому извлечь информацию ограничившись группой алгоритмов шифрования (UCConsts. CRYPT_ENCRYPT_ALG_OID_GROUP_ID). И если информация найдена — значит это наш алгоритм.

В случае если таких алгоритмов больше чем один можно так же фильтровать по размеру (опираясь на размер алгоритма хэширования).

Дешифрование

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

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

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

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

• целостность цепочки (сертификат издателя, сертификат издателя сертификата издателя, и т. п.);
• сертификат корневого издателя — должен быть в хранилище доверенных корневых центров;
• период действия всех сертификатов — момент использования сертификата должен быть в границах этого периода;
• каждый из сертификатов в цепочке, кроме корневого, должен отсутствовать в списке отозванных у своего издателя (CRL);

По хорошему надо еще проверять и права подписи, но в реальной жизни это делается редко.

Как уже понятно из введения, проверка сертификата на валидность, одна из самых сложных задач. Именно поэтому в библиотеке масса методов для реализации каждого из пунктов в отдельности. Поэтому, для упрощения обратимся к исходникам. Net для метода X509Certificate2. Verify() и возьмем их за основу.

Проверка состоит из двух этапов:

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

Такая проверка должна осуществляться перед подписанием и шифрованием на текущую дату, и в момент проверки подписи на дату подписания. Сам метод проверки небольшой:

Сначала формируется цепочка методом BuildChain, а затем она проверяется. В ходе формирования цепочки формируется структура параметров, дата проверки и флаги проверки:

Формирование цепочки сертификата

Это сильно упрощенный вариант формирования цепочки по сравнению с тем, как ее формирует Microsoft. Структуры hCertPolicy и hAppPolicy можно наполнить OID-ами, отображающими права на действия, которые необходимы в проверяемом сертификате. Но в примере, будем считать, что их мы не проверяем.

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

Метод MapRevocationFlags — можно взять напрямую из исходников. Net без изменений —он просто формирует uint по набору передаваемых флагов.

Заключение

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

• ожидание 10 мс;
• извлечение сертификата;
• проверка полученной подписи;
• извлечение параметров подписи;
• дешифрование полученных данных;

Данный цикл был запущен в Windows и в Linux в 1-ом, 10-и и 50-и потоках, чтобы проверить работу в Linux сразу в нескольких потоках. Приложение в Linux работало стабильно в течении какого-то времени во много-поточном режиме (и чем больше потоков, тем меньше по времени), а затем «вставало» наглухо. Что свидетельствует о наличии взаимной блокировки (deadlock-е) в библиотеке (при нарушении работы с потоками связанных с разделяемым доступом обычно происходит падение с «Access Violation»).

По этой причине для обеспечения стабильности работы все методы класса UCryptoAPI стоит обрамить критической секцией. Для этого добавляем поле fpCPSection типа object после чего в каждый вызов добавляем следующую конструкцию:

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

Нагрузочное тестирование так же показало утечки памяти в mono при обращении к полям Issuer и Subject сертификата. Утечка, вероятно, происходит при попытке mono сформировать классы X500DistinguishedName для подписанта и издателя. К счастью, mono посчитали этот процесс достаточно ресурсоемким (или же они знают об утечке), поэтому предусмотрели кэширование результата данного формирования во внутренние поля сертификата (impl. issuerName и impl. subjectName). Поэтому данная утечка лечится прямой записью через отражение (Reflection) в эти поля экземпляров класса X500DistinguishedName, сформированных на базе значений из структуры CERT_CONTEXT сертификата.

Установка КриптоПРО CSP в Linux

Описание процесса установки приведено на примере дистрибутива семейства Debian (x64). Некоторые команды могут потребовать запуска с sudo. Названия файлов и директорий могут отличаться из-за различий в версиях.

Загрузите КриптоПро CSP версии 4. 0 для Вашей платформы и распакуйте архив:

tar -xzvf linux-amd64_deb. tgz

Для установки выполните команды:

sudo chmod 777 -R linux-amd64_deb/ sudo linux-amd64_deb/install

Проверьте отсутствие cprocsp-rdr-gui:

Установите дополнительно cprocsp-rdr-gui-gtk:

sudo dpkg -i linux-amd64_deb/cprocsp-rdr-gui-gtk-64_4. 0-4_amd64. deb

Установите лицензионный ключ командой:

sudo /opt/cprocsp/sbin/amd64/cpconfig -license -set XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

Дополнительная информация по установке