криптопро hyper v

Как решить проблему, что криптопро не видит USB ключ?

Создали новую виртуальную машину и стали ставить софт все последовательно.

Перед установкой любого программного обеспечения работающего с USB носителями на которых находятся сертификаты и закрытые ключи. Нужно ОБЯЗАТЕЛЬНО
отключить токен, если воткнут локально, то отключаем его, если по сети, разрываем сессию

• Первым делом обновляем вашу операционную систему , всеми доступными обновлениями, так как Microsoft исправляет много ошибок и багов, в том числе и драйверами.
• Вторым пунктом является, в случае с физическим сервером, установить все свежие драйвера на материнскую плату и все периферийное оборудование.
• Далее устанавливаете Единый Клиент JaCarta.
• Устанавливаете свежую версию КриптоПРО

Работа с «КриптоПро NGate»

Предварительные комментарии

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

Подготовка к эксплуатации связана с первоначальным развёртыванием и настройкой программного обеспечения криптошлюза на аппаратной или виртуальной платформе. Этот этап является наиболее трудоёмким и ответственным. Он требует наличия практических навыков работы с операционной системой семейства Linux, знаний о сети организации и инфраструктуре открытых ключей (Public Key Infrastructure, PKI).

Затем с использованием веб-интерфейса администрирования осуществляется настройка криптошлюза для решения задач связанных с организацией доступа пользователей к ресурсам. Сюда входят настройка порталов, серверных мандатов, пользовательских ролей и политик доступа к защищаемым ресурсам, а также конфигурирование взаимодействия со внешними службами (Microsoft AD или другими LDAP-серверами, системами мониторинга, SIEM, средствами аутентификации, включая RADIUS-серверы, и др.).

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

Доступ к интерфейсу администрирования

В рамках подготовки этого обзора разработчик предоставил нам пользовательский сертификат и учётную запись типа «Аудитор» для доступа к тестовому стенду NGate. Эта пользовательская роль является одной из штатных функций продукта и предоставляет возможность просматривать большую часть разделов и возможностей веб-интерфейса без права что-либо изменять. Кроме того, для доступа использовались «Яндекс.Браузер», поскольку он поддерживает шифрование по ГОСТ, и «КриптоПро CSP» в качестве вспомогательного программного обеспечения (установочный файл доступен на основной странице после регистрации).

Рисунок 4. Вход в веб-интерфейс администрирования «КриптоПро NGate»

Панель управления

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

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

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

Рисунок 5. Вкладка «Системная информация» панели управления «КриптоПро NGate»

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

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

Рисунок 6. Поиск сессий пользователей в веб-интерфейсе «КриптоПро NGate»

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

Рисунок 7. Информация о системе управления в составе «КриптоПро NGate»

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

Рисунок 8. Информация о системе управления в составе «КриптоПро NGate»

Настройка конфигураций кластеров

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

Рисунок 9. Информация о конфигурации кластера в веб-интерфейсе «КриптоПро NGate»

Кроме того, на этой вкладке появилась функция по добавлению Stream-портала, то есть портала для доступа к ресурсам по произвольному протоколу на базе TCP поверх TLS. Ранее можно было добавлять порталы только для тех ресурсов, которые работают по HTTP.

Рисунок 10. Добавление портала для доступа пользователей к ресурсам по произвольному TCP-протоколу в веб-интерфейсе «КриптоПро NGate»

На другой вкладке этого же раздела можно смотреть детальную информацию о защищаемых ресурсах, настраивать их, добавлять новые, копировать или удалять уже существующие. Можно добавить веб-ресурс, динамический туннель, ресурс для перенаправления пользователей и gRPC-сервисы. По протоколу gRPC работают различные веб-приложения, а в целом он реализует удалённые программные интерфейсы (API).

Рисунок 11. Информация о ресурсах, связанных с кластером, в веб-интерфейсе «КриптоПро NGate»

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

Рисунок 12. Создание веб-ресурса в интерфейсе «КриптоПро NGate»

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

Рисунок 13. Внешние службы, настроенные для кластера, в веб-интерфейсе «КриптоПро NGate»

Также в разделах конфигурации кластера администратор осуществляет настройку правил и политик доступа к ресурсам (ACL) на основе групп пользователей на каком-либо сервере LDAP (к примеру, Microsoft AD) либо сертификатов (новая функциональность). Сертификатный ACL — это способ задать правила доступа на основе содержимого полей пользовательских сертификатов. В актуальной версии шлюза стало возможно создавать правила с запретительным доступом (в предыдущей версии он был только разрешительным), а также существенно расширился набор полей. Теперь анализируются не только поля с названием организации (Organization / Organization Unit), но и другие, в том числе нестандартные.

Рисунок 14. Настройка сертификатного ACL в веб-интерфейсе «КриптоПро NGate»

Настройка порталов

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

Рисунок 15. Общая информация о настройках портала в веб-интерфейсе «КриптоПро NGate»

Рисунок 16. Создание правила для динамического туннелирования в веб-интерфейсе «КриптоПро NGate»

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

Рисунок 17. Информация о сертификатах портала в веб-интерфейсе «КриптоПро NGate»

Также для каждого портала отдельно настраиваются методы аутентификации пользователей, включая RADIUS-протокол и форматы одноразовых паролей. Администратор может настроить многофакторную аутентификацию и определить перечень требуемых от пользователя данных, который, к примеру, одновременно может включать необходимость предоставить клиентский сертификат, логин и пароль из LDAP, затем PIN-код для доступа к OTP и сам OTP, полученный из SMS-сообщения или специализированного ПО 2FA (Google Authenticator, «Яндекс.Ключ» и т. д).

Рисунок 18. Настройка портала в веб-интерфейсе «КриптоПро NGate»

Настройки узлов

Новой функциональностью в разделе веб-интерфейса «Кластеры» стали возможности создания VLAN- и агрегированных сетевых интерфейсов (Bond-интерфейсов).

Рисунок 19. Общая информация об узлах кластера в веб-интерфейсе «КриптоПро NGate»

Рисунок 20. Сетевые интерфейсы узла кластера в веб-интерфейсе «КриптоПро NGate»

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

Рисунок 21. Создание Bond-интерфейса в «КриптоПро NGate»

Архитектура «КриптоПро NGate»

С точки зрения архитектуры NGate состоит из следующих компонентов: клиента (в виде VPN-клиента или браузера), сервера (самого шлюза) и системы управления (центра управления сетью, ЦУС). Дополнительно потребуется организовать автоматизированное рабочее место (АРМ) для администратора.

Основой серверной части NGate является криптопровайдер «КриптоПро CSP». В новой версии шлюза используется обновлённая его редакция — 5.0 R2. В ней помимо прочего реализована работа с алгоритмами «Кузнечик» (ГОСТ 34.12-2015) и «Магма» (ГОСТ 28147-89), добавлена и расширена поддержка отечественных операционных систем («Аврора», Astra Linux, ALT Linux). Кроме того, появились возможности по построению решений на базе отечественных процессоров «Байкал». Таким образом, стало возможным полноценное импортозамещение при внедрении криптографического шлюза для организации защищённого удалённого доступа ко критическим ресурсам.

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

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

Рисунок 1. Схема внедрения «КриптоПро NGate» в минимальной конфигурации

Кластерная конфигурация позволяет построить распределённую, отказоустойчивую и хорошо масштабируемую в части производительности систему. В этом варианте предусматривается объединение нескольких криптошлюзов (до 32 узлов единовременно) в один кластер. При этом центр управления сетью устанавливается отдельно и образует единую (централизованную) систему для настройки, мониторинга работы всех криптошлюзов и управления доступом к требуемым ресурсам и системам организации. Возможности центра управления по автоматизированной загрузке настроек и конфигураций на новые криптошлюзы в кластерах существенно облегчают и ускоряют процессы связанные как с вертикальной, так и с горизонтальной масштабируемостью системы. При этом выход из строя какого-либо узла кластера не приводит к разрыву соединений, поскольку балансировщик синхронизирует данные о сессии между устройствами и соединение перераспределяется на свободные узлы кластера. Может использоваться любой балансировщик, способный распределять TCP-соединения по узлам кластера, в том числе бесплатный HAProxy.

Рисунок 2. Схема внедрения «КриптоПро NGate» в виде кластера

Рисунок 3. Реализация технологии TLS VPN с помощью «КриптоПро NGate» в виде кластера

Инициализация XML-подписи в Santuario

Ах да, тут есть один интересный момент. В сети множество советов, касающихся СМЭВа, заключающихся в ручном парсинге кусков XMLек, и прочим закатом солнца вручную, но это не наш метод (и не метод, который использовали создатели клиента)

Замес в том, что сгенерить самоподписанные ключи по госту легко (копипаста на SO ищется за секунды). А вот подписать — нет, ибо по мнению интернет-школьников якобы Bouncycastle не поддерживает xml-подпись. Конкретней, при работе с Apache Santuario, XMLSignature из santuario-xmlsec не понимает что использовать для обработки метода “xmldsig-more#gostr34102001-gostr3411” при вызове xmlSignature.sign(privateKey).

Отдельная хохма в том, что IntelliJ IDEA Community глючит при попытке отдебажить xmlsec, бросая step in отладчика в неверное место верных исходников. Я попробовал все разумные версии Идеи, поэтому понимать как это работает надо вслепую, написуя тактические письма в Спортлото. Это не в укор Идее, не существует идеальных инструментов, просто фактор повлиявший на скорость понимания вопроса.

Чтобы это заработало, нужно:

1) Заимплементить реализацию SignatureAlgorithmSpi из Apache Santuario. В GetEngineUri вернуть строку: “http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411” (или что там у вас). Это ключевая магия. Совершенно ничего умного этот класс делать не должен.

Инициализация раз за всю жизнь приложения (н-р в синглтон-бине спринга):

2) Загрузить провайдер, чтобы не патчить JDK:

Security.addProvider(new BouncyCastleProvider());

3) Впердолить в рантайм только что написанный класс:

String algorithmClassName = "fully qualified name класса реализующего SignatureAlgorithmSpi";
Class.forName(algorithmClassName);
SignatureAlgorithm.providerInit();
SignatureAlgorithm.register("http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411", algorithmClassName);

4) Достучаться до маппингов алгоритмов JCE:

String ns = "http://www.xmlsecurity.org/NS/#configuration";
Document document = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
Element rootElement = document.createElementNS(ns, "JCEAlgorithmMappings");
Element algorithms = document.createElementNS(ns, "Algorithms");

5) Замапить метод на алгоритм:

Element aElem = document.createElementNS(NameSpace, "Algorithm");
aElem.setAttribute("URI", "http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411");
aElem.setAttribute("Description", "GOST R 34102001 Digital Signature Algorithm with GOST R 3411 Digest");
aElem.setAttribute("AlgorithmClass", "Signature");
aElem.setAttribute("RequirementLevel", "OPTIONAL");
aElem.setAttribute("JCEName", "GOST3411WITHECGOST3410");
algorithms.appendChild(aElem);

6) Применить маппинги:

org.apache.xml.security.Init.init();
JCEMapper.init(rootElement);

6) PROFIT!
После этого XMLSignature резко начинает понимать этот метод, и начнет делать xmlSignature.sign.

Алгоритм решения проблем с JaCarta

КриптоПРО очень часто вызывает различные ошибки в Windows, простой пример (Windows installer service could not be accessed). Вот так вот выглядит ситуация, когда утилита КриптоПРО не видит сертификат в контейнере.

Как видно в утилите UTN Manager ключ подключен, он видится в системе в смарт картах в виде Microsoft Usbccid (WUDF) устройства, но вот CryptoPRO, этот контейнер не определяет и у вас нет возможности установить сертификат. Локально токен подключали, все было то же самое. Стали думать что сделать.

Disclamer

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

Недавно мне нужно было разобраться, как написать сервис, работающий с Системой Межведомственного Электронного Взаимодействия.
Все написанное представляет собой просто результат небольшого исследования, максимально абстрагированный от выполненной работы. И даже приблизительно угадать что-то о реально принятых решениях невозможно, я проверял.

Windows Hyper-V + КриптоПро

Требуется реализовать схему с разворачиванием некого временного виртуального Windows окружения с КриптоПро для создания ключа ЭЦП для пользователя и обратным сворачиванием.

Коротко, выглядит оно вот так: 1. на локальном ноутбуке с Windows делается ряд манипуляций и формируются документы или контейнер документов; 2. через запрос разворачивается виртуальное пространство, на котором развернуты рабочие стол(ы) и на этом столе запускается КриптоПро и наш софт, в который из пункта 1 передаются документы или контейнер документов 3. ботом на виртуальной машине выполняются стандартные действия и документы прокидываются далее.

Разделы:

Опубликован:

08.06.2018 | 18:08 [последние изменения: 08.06.2018 | 18:50]

Функциональные возможности «КриптоПро NGate»

Режимы работы

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

Режим TLS-терминатора (TLS offload) или TLS-сервера для доступа к информационным ресурсам. При реализации такого формата функционирования шлюз становится промежуточным звеном между защищаемым публичным ресурсом и пользователем, который пытается получить доступ к нему используя веб-браузер (при этом установка VPN-клиента не требуется). NGate в режиме терминатора не осуществляет аутентификацию пользователей, но обеспечивает криптографическую защиту данных, передаваемых не только по HTTP, но и по HTTP/2, REST, gRPC, WebSockets и произвольным TCP-протоколам. Наиболее распространёнными и понятными примерами систем, для доступа к которым можно использовать криптографический шлюз в режиме терминатора, могут выступать различные государственные порталы (например, Единый портал государственных услуг), электронные торговые площадки, сайты дистанционного банковского обслуживания, видео-конференц-связи и телемедицины.

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

Режим VPN-сервера предназначен для реализации безопасного удалённого доступа сотрудников организации (на их устройства устанавливается VPN-клиент) к произвольным корпоративным ресурсам (файловым хранилищам, доступ по RDP и т. д.) с использованием технологии динамического туннелирования VPN TLS.

Методы аутентификации

NGate поддерживает разнообразные способы аутентификации, а также возможность их комбинировать:

• по логину и паролю (Microsoft Active Directory, AD);
• по сертификату (реализована не только простая проверка на валидность, но и аутентификация по различным полям сертификата: Organization, Organizational Unit (O / OU), Enhanced Key Usage, а также по дополнительным наборам полей, например СНИЛС, ИНН и т. д., в том числе при пустых полях O / OU);
• по имени участника-пользователя (User Principal Name, UPN) в Microsoft AD;
• с использованием сертификата присутствующего во внешней службе каталогов (Microsoft AD, LDAP);
• по одноразовому паролю (One-Time Password, OTP) при интеграции с RADIUS-сервером;
• с использованием сертификатов расположенных на различных токенах и смарт-картах (Aladdin, «Рутокен», Esmart и др.).

Возможности интеграции

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

Таблица 5. Примеры сторонних систем, с которыми возможна интеграция «КриптоПро NGate»

Новые функции и улучшения

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

Далее мы кратко перечислим новые функции и возможности или улучшения NGate версии 1.0 R2:

• Произошёл переход на новую базовую систему Debian 11.
• Выполнен переход на новую версию программного кода Python 3 в связи с окончанием поддержки Python 2.x.
• Произведено обновление криптопровайдера «КриптоПро CSP», составляющего основу серверной части шлюза, до версии 5.0 R2. В разделе с описанием архитектуры криптошлюза мы уже указали основные изменения, произошедшие в новой версии, поэтому дублировать их не будем.
• Расширена поддержка RADIUS-серверов для многофакторной аутентификации: теперь можно получать одноразовые пароли не только через SMS, появилась возможность одновременного ввода различных комбинаций OTP, кода OTP PIN и пароля пользователя из AD или LDAP, а также совместно с пользовательским сертификатом.
• Расширены возможности аутентификации по сертификату (Certificate Access Control List, ACL) на портале. Под порталом понимается сайт или группа сайтов, то есть совокупность ресурсов защищаемых криптошлюзом. Напомним, что теперь аутентификация возможна не только по полям Organization или Organizational Unit (O / OU), но и по дополнительным наборам полей.
• Добавлена возможность разграничения доступа к защищаемым ресурсам в зависимости от поддержки (или её отсутствия) клиентским устройством криптографических алгоритмов ГОСТ.
• Доработан и оптимизирован веб-интерфейс администратора. В частности, появилась панель для просмотра сессий подключённых пользователей и управления ими, добавлен способ быстрого копирования портала со всеми конфигурациями, расширен перечень вариантов фильтрации сертификатов, реализована функция создания резервной копии сразу из веб-интерфейса. Кроме того, были значительно дополнены комментарии к различным полям, упрощающие процессы взаимодействия с интерфейсом.
• Добавлена возможность криптографической защиты трафика передаваемого по HTTP/2, REST, gRPC, WebSockets и произвольным TCP-протоколам. Последнее выступает аналогом инструмента Stunnel и используется в основном для реализации доступа к ресурсам управления промышленными устройствами, защиты почтового трафика, передачи файлов (например, по FTP), удалённого доступа к устройствам по SSH и т. д.
• Реализована функция смены пароля пользователя в каталоге AD / LDAP при использовании клиента NGate.
• Добавлены возможности более тонкой настройки маршрутизации, а также управления приоритетом опроса — в том числе DNS-серверов — при разрешении имён через туннель (путём настройки метрики туннельного интерфейса).
• Значительно расширен перечень динамических HTTP-заголовков с информацией о клиенте, которые шлюз может отправлять защищаемым ресурсам. Кроме того, добавлена функция реализующая криптографическую защиту целостности передаваемых заголовков таким образом, чтобы ресурс мог проверить, кто является источником (или автором) конкретных заголовков и можно ли ему доверять. Отметим, что в случае передачи информации о паролях пользователей в HTTP-запросах она всегда шифруется с помощью специального алгоритма, построенного на базе симметричных шифров ГОСТ.
• Расширены функции по контролю соединений пользователей и управлению ими: добавлены возможности по настройке задержки синхронизации, таймаута для постоянных (keep-alive) HTTP-соединений, ограничения количества одновременных сессий пользователя, а также автоматического отключения при отзыве пользовательского сертификата. Кроме того, появилась функция принудительного разрыва соединений администратором.
• Добавлена поддержка TLS 1.3.

Тестовые самоподписанные ключи

Так как мы деламем все это в тестовых целях, теперь мы подходим к кульминации и начинаем сами себе выдавать ключи.

Как выдать ключи в формате Крипто Про, я особо не заморачивался, потому что это просто не нужно в рамках текущей задачи. Но на всякий случай, существует сервис выдачи таких ключей: http://www.cryptopro.ru/certsrv/

• Все действия производить на Windows (подойдет виртуальная машина) с установленным Крипто Про CSP;
• Открыть сайт и перейти к выдаче ключа;
• Нужно выбрать пункт “Сформировать ключи и отправить запрос на сертификат” и нажать кнопку “Дальше”;
• Щелкнуть по ссылке “Создать и выдать запрос к этому ЦС”;
• Заполнить необходимые поля;
• Нажат кнопку “Выдать”;
• Установить сертификат.

Сертификация шлюза «КриптоПро NGate» и выполнение требований законодательства

NGate был включён в Единый реестр российских программ для электронных вычислительных машин и баз данных Минцифры России в 2017 году (запись № 305680). В декабре 2019 года все компоненты шлюза (и серверные, и клиентские) прошли проверку на соответствие требованиям ФСБ России к средствам криптографической защиты информации по классам защиты КС1, КС2 и КС3 (получены сертификаты № СФ/124-3629, СФ/124-3630 и СФ/124-3631 для NGate в различных исполнениях). Кроме того, компоненты шлюза удалённого доступа используют в своём составе собственный криптопровайдер «КриптоПро CSP», который также сертифицирован ФСБ России для защиты информации по тем же классам.

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

Выше уже упоминалось, но повторим явно в текущем разделе следующее важное замечание. В среде виртуализации можно использовать NGate без ограничений функциональности и производительности (кроме тех, что связаны с характеристиками виртуальных машин), но только с пониженным классом сертификации. Криптошлюз NGate в виде виртуальной платформы отвечает требованиям ФСБ России по классу КС1.

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

Таблица 4. Требования законодательства РФ в области обеспечения информационной безопасности, которым отвечает «КриптоПро NGate»

Системные требования «КриптоПро NGate»

NGate сертифицирован ФСБ России по классам защиты КС1, КС2 и КС3 и может поставляться как в виде программно-аппаратного комплекса, с предустановкой программного обеспечения на специализированные сетевые аппаратные платформы в различных конфигурациях в зависимости от необходимых технических параметров, вычислительных мощностей и требований инфраструктуры каждой конкретной организации, так и в виде программного обеспечения для развёртывания в среде виртуализации.

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

Таблица 1. Основные характеристики аппаратных платформ «КриптоПро NGate» (центр управления сетью)

Таблица 2. Основные характеристики аппаратных платформ «КриптоПро NGate» (узел кластера)

Для развёртывания NGate в виде виртуальной программной платформы виртуальные машины должны удовлетворять определённым системным требованиям. Мы перечислили их в таблице далее.

Таблица 3. Системные требования для установки системы управления «КриптоПро NGate» в среде виртуализации

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

К программной и аппаратной частям пользовательских устройств для работы VPN-клиента NGate особых требований не предъявляется. Работа VPN-клиента возможна практически на всех популярных настольных и мобильных операционных системах, включая отечественные программные и аппаратные разработки:

• Microsoft Windows версий 7, 8, 8.1, 10, 11,
• macOS версий 10.10–10.15, 11,
• Linux (RHEL, CentOS, Debian, Ubuntu, ROSA, Astra, ALTLinux и другие),
• iOS,
• Android,
• «Аврора».

Для получения доступа к защищаемым ресурсам пользователь может применять VPN-клиент NGate, веб-браузер либо собственное мобильное приложение после встраивания в него криптопровайдера «КриптоПро CSP 5.0 R2» (реализует поддержку TLS с ГОСТ для операционных систем iOS, Android и «Аврора» без дополнительных тематических исследований).

Что нужно допилить в готовом клиенте, чтобы сбежать с Крипто Про

Код написан довольно дружелюбно для расширения, поэтому можно просто взять за основу класс KeyStoreWrapperJCP, и аналогично написать KeyStoreWrapperBouncyCastlePKCS12, KeyStoreWrapperBouncyCastleJKS.

Переписать DigitalSignatureFactory, так, чтобы он на вход начал принимать путь до криптоконтейнера на файловой системе и пароль от него (для КриптоПро это просто не нужно). Там есть свич, который проверяет тип криптопровайдера, в него надо дописать дополнительно два кейса, для имен типа BOUNCY_JKS и BOUNCY_PKCS12 и навешать использование соответсвующих KeyWrapper и вызов initXmlSec.

В initXmlSec нужно дописать
1) возможность принимать вообще любой провайдер, а не только криптопро (это просто удобно)
2) Security.addProvider(new BouncyCastleProvider());
3) для XMLDSIG_SIGN_METHOD сделать свич: если КриптоПро, то алгоритм называется “GOST3411withGOST3410EL”, а если BouncyCastle алгоритм называется “GOST3411WITHECGOST3410”.

Ну вроде как и все. Если бы была известна лицензия на этот смэв-клиент, я бы приложил конкретный код под Apache License 2, а так это просто список идей.

Как мы можем грубо заставить Крипто Про отдать ключи

Можно очень долго мучиться, пытаясь засучив C++ вычитать ключ из контейнера с помощью OpenSSL и такой-то матери. Я честно пытался, и разбился об задачу как корабль об скалы (по крайней мере, это задачка больше чем на 1 день для человека, который давно таким не занимался). На просторе интернетов мы не единственные, кто разбился об те же скалы: http://gigamir.net/techno/pub903517

Вот тут наступает момент “это радость со слезами на глазах”. Некая контора под названием Лисси Софт, всего за 2 тыщи рублей отдает нам гениальную утилиту P12FromGostCSP. Ее создатели таки победили ту проблему, которую не осилило сообщество, и она выдирает ключи в PFX. Радость — потому что она работает.

Со слезами — потому что это проприетарщина, и она фиг знает как работает.
На картинке Ричард Столлман как бы удивляется и спрашивает: “неужели вы боретесь с проприетарщиной с помощью другой проприетарщины?”

Так что целиком инструкция по перегону ключей выглядит как-то так:

• Все действия производить на Windows (подойдет виртуальная машина) с установленным Крипто Про CSP;
• Подготовить OpenSSL с ГОСТом по инструкции (есть в этой статье).
• Купить P12FromGostCSP. Поплакать.
• Установить исходный ключ в КриптоПро (это заслуживает отдельной инструкции, но она гуглится).
• Запустить P12FromGostCSP (перед этим спрятать икону Ричарда Столлмана под стол, чтобы он не проклял тебя за запуск проприетарщины)
• Выбрать установленный сертификат, указать пароль сертификата КриптоПро
• Указать произвольный новый пароль (парольную фразу) для ключевой пары PFX
• Указать местоположение для сохранения файла. Файл лучше именовать в формате p12.pfx (это название по-умолчанию, лучше не трогать — говорят, есть баги, если переименовать)
• Получить pem файл:

  openssl pkcs12 -in p12.pfx -out private.key.pem -name "alias"

• (-name “alias” — эта опция поменяет имя ключа внутри контейнера. Это нужно потому, что P12FromGostCSP именует ключи как попало (на самом деле, по порядку, цифрами), без сохранения исходного алиаса.
• Получить pkcs12 файл:

  openssl pkcs12 -export -out private.key.pkcs12 -in private.key.pem -name "alias"

• Готово

3 Comments

1. держу на ESXi 5.5 Windows 2012 R2
   стоит крипто про 3.9
   почему то после закрытия сбиса иногда процесс остается висеть в памяти, не сталкивались с такой проблемой?
   при этом можно запустить еще раз сбис и он откроется нормально, никакие файлы не будут заблокированы предыдущей версией.
   не могу понять в чем дело, отъедает память сильно если несколько копий останутся запущенные весеть..

День первый

На Windows 7 x64 были совместно установлены Virtual Box (версии 4 и 5) с расширением Extension Pack и CryptoPro CSP (КриптоПро CSP 3.6 R4 для Windows).

При запуске виртуальной машины через Virtual Box система падала в синий экран. Причина в невозможности совместной работы КриптоПро CSP и Virtual Box.

Чтобы не было синего экрана при запуске виртуальной машины VirtualBox удалил КриптоПро CSP и перезагрузил компьютер. Решение временное, не сумел разобраться как подружить два продукта, а VirtualBox был нужнее, чем КриптоПро.

Помогло выйти на связь VirtualBox + КриптоПро == BSOD сообщение на форуме:
На форуме Крипто Про также есть обсуждение:
Отчёты из программы blueScreenView :

A problem has been detected and Windows has been shut down to prevent damage
to your computer.
The problem seems to be caused by the following file: ntoskrnl.exe
SYSTEM_SERVICE_EXCEPTION
Technical Information:
*** STOP: 0x0000003b (0x00000000c0000005, 0xfffff800032735af, 0xfffff8800412eb90,
0x0000000000000000)
*** ntoskrnl.exe – Address 0xfffff80003292c40 base at 0xfffff8000321f000 DateStamp
0x5625815c
Вывод – Virtual Box (версии 4 и 5) и CryptoPro CSP (КриптоПро CSP 3.6 R4 для Windows) пока несовместимы на Windows 7 x64 SP1.

================

День второй

Подключил к первому монитору второй монитор, используя USB 3.0 VGA Adapter. Модель устройства – Fresco Logic FL200 USB Display Adapter. Если подключить адаптер до включения виртуальной машины, то порядок. А если подключать адаптер во время работы виртуальной машины Virtual Box, то будет снова синий экран.

A problem has been detected and Windows has been shut down to prevent damage
to your computer.
The problem seems to be caused by the following file: ntoskrnl.exe
IRQL_NOT_LESS_OR_EQUAL
Technical Information:
*** STOP: 0x0000000a (0x0000000000000088, 0x0000000000000002, 0x0000000000000001,
0xfffff800032579e6)
*** ntoskrnl.exe – Address 0xfffff80003276c00 base at 0xfffff80003203000 DateStamp
0x5684191c

Из того, что видно перед ошибкой – диспетчер устройств (HAL) сообщает, что подключено новое USB 2.0 устройство, а затем система падает. Диспетчер устройств не прав, так как подключается USB 3.0 устройство в USB 3.0 порт.

Возможно, просто совпадение, два BSOD-а подряд. И причина BSOD в реализации драйверов для Fresco Logic FL200 USB Display Adapter.

Но есть предположение, что причина ошибок в реализации поддержки USB 2.0 / USB 3.0 в VirtualBox. А особые возможности поддержки USB появляются при установке Oracle VM VirtualBox Extension Pack.

Удалить VirtualBox не хотелось бы, иногда бывает нужен. А удалить Extension Pack могу запросто. Надеюсь, что после удаления VirtualBox Extension Pack синих экранов больше не будет. И можно будет повторно установить КриптоПро CSP 3.6 R4 для Windows и пользоваться двумя мониторами.

Добрый день!. Последние два дня у меня была интересная задача по поиску решения на вот такую ситуацию, есть физический или виртуальный сервер, на нем установлена наверняка многим известная КриптоПРО. На сервер подключен , который используется для подписи документов для ВТБ24 ДБО
. Локально на Windows 10 все работает, а вот на серверной платформе Windows Server 2016 и 2012 R2, Криптопро не видит ключ JaCarta
. Давайте разбираться в чем проблема и как ее поправить.

Описание окружения

Есть виртуальная машина на Vmware ESXi 6.5, в качестве операционной системы установлена Windows Server 2012 R2 . На сервере стоит КриптоПРО 4.0.9944, последней версии на текущий момент. С сетевого USB хаба, по технологии USB over ip , подключен ключ JaCarta. Ключ в системе видится
, а вот в КриптоПРО нет.

Как мы можем попросить Крипто Про отдать ключи (на самом деле, нет)

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

Если поставить винду в виртуальную машину, накатить туда Крипто Про, установить ключи и попробовать их экспортировать, то обнаруживаем удивительную вещь: в экспортере не работает экспорт в PKCS12, а все остальные направления в экспортере заблокированы (англ. “grayed out”).

Гуглю ошибку, и что же мы видим на официальном форуме?
https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=2425

“От Алексея Писинина был получен ответ:
Добрый день. PKCS12 не соответствует требованиям безопасности ФСБ в части хранения закрытых ключей. В теории, закрытые ключи должны храниться на так называемых “съемных” носителях. Собственно, по этой причине и не работает экспорт.”

Я правильно это читаю как, что у них гуй для экспорта есть, но бизнес-логики к нему нету?!
Ппоэтому каких галочек ни нащелкай — всегда будет выпадать ошибка на последнем шаге гуевого мастера?!

Какой же стыд.

Dear God,
Please kill them all.
Love, Greg.

Выдача контейнера JKS

Этот вопрос широко представлен в интернете, поэтому можно сразу смотреть Stackoverflow:
http://stackoverflow.com/questions/14580340/generate-gost-34-10-2001-keypair-and-save-it-to-some-keystore

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

Security.addProvider( new org.bouncycastle.jce.provider.BouncyCastleProvider() );

KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance( "ECGOST3410", "BC" );
keyPairGenerator.initialize( new ECGenParameterSpec( "GostR3410-2001-CryptoPro-A" ) );
KeyPair keyPair = keyPairGenerator.generateKeyPair();

org.bouncycastle.asn1.x500.X500Name subject = new org.bouncycastle.asn1.x500.X500Name( "CN=Me" );
org.bouncycastle.asn1.x500.X500Name issuer = subject; // self-signed
BigInteger serial = BigInteger.ONE; // serial number for self-signed does not matter a lot
Date notBefore = new Date();
Date notAfter = new Date( notBefore.getTime() + TimeUnit.DAYS.toMillis( 365 ) );

org.bouncycastle.cert.X509v3CertificateBuilder certificateBuilder = new org.bouncycastle.cert.jcajce.JcaX509v3CertificateBuilder(
        issuer, serial,
        notBefore, notAfter,
        subject, keyPair.getPublic()
);
org.bouncycastle.cert.X509CertificateHolder certificateHolder = certificateBuilder.build(
        new org.bouncycastle.operator.jcajce.JcaContentSignerBuilder( "GOST3411withECGOST3410" )
                .build( keyPair.getPrivate() )
);
org.bouncycastle.cert.jcajce.JcaX509CertificateConverter certificateConverter = new org.bouncycastle.cert.jcajce.JcaX509CertificateConverter();
X509Certificate certificate = certificateConverter.getCertificate( certificateHolder );

KeyStore keyStore = KeyStore.getInstance( "JKS" );
keyStore.load( null, null ); // initialize new keystore
keyStore.setEntry(
        "alias",
        new KeyStore.PrivateKeyEntry(
                keyPair.getPrivate(),
                new Certificate[] { certificate }
        ),
        new KeyStore.PasswordProtection( "entryPassword".toCharArray() )
);
keyStore.store( new FileOutputStream( "test.jks" ), "keystorePassword".toCharArray()

Резюме

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

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

Выдача контейнера PKCS12

В принципе, это не особо нужно, потому что у нас уже есть простой и удобный способ выдавать JKS, а JKS для Java это самое что ни на есть родное решение. Но для полноты картины, пусть будет.

• Подготовить OpenSSL с ГОСТом по инструкции (есть в этой статье).
• Сделать Cerificate Signing Request + приватный ключ (вписать нужные данные о ключе!):

  openssl req -newkey gost2001 -pkeyopt paramset:A -passout pass:aofvlgzm -subj "/C=RU/ST=Moscow/L=Moscow/O=foo_bar/OU=foo_bar/CN=developer/emailAddress=olegchiruhin@gmail.com" -keyout private.key.pem -out csr.csr

• Подписать приватным ключом (на Windows эту операцию нужно делать с правами Administrator, иначе свалится с ошибкой “unable to write ‘random state'”):

  openssl x509 -req -days 365 -in csr.csr -signkey private.key.pem -out crt.crt

• GOST2001-md_gost94 hex (если надо):

  openssl.exe dgst -hex -sign private.key.pem message.xml 

• MIME application/x-pkcs7-signature (если надо):

  openssl smime -sign -inkey private.key.pem -signer crt.crt -in message.xml

• Превратить pem в pkcs12:

  openssl pkcs12 -export -out private.key.pkcs12 -in private.key.pem -name "alias" 

Подготовка OpenSSL для работы с ГОСТ

Если у вас в начале статьи на стене висит OpenSSL, когда-нибудь он точно выстрелит.
Так что да, это важный момент, необходимый для осуществления дальнейшего текста.

• Так как у нас Крипто Про, и на Маке оно не взлетает, нам понадобится виртуальная машина с Windows (можно даже Windows XP), и установленной Криптой
• Установить как можно более актуальную версию OpenSSL (так, чтобы в ней уже была поддержка ГОСТ):
  https://wiki.openssl.org/index.php/Binaries
  https://slproweb.com/products/Win32OpenSSL.html
• Проверить, что в установленной версии есть файл gost.dll
• В установленном OpenSSL найти файл openssl.cfg
• В самое начало файла добавить строчку:

  openssl_conf = openssl_def

• В самый конец файла добавить строчки:

  [openssl_def]
  engines = engine_section
  
  [engine_section]
  gost = gost_section
  
  [gost_section]
  engine_id = gost
  dynamic_path = ./gost.dll
  default_algorithms = ALL
  CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet

• PROFIT

Установка единого клиента JaCarta PKI

Единый Клиент JaCarta
– это специальная утилита от компании “Аладдин”, для правильной работы с токенами JaCarta. Загрузить последнюю версию, данного программного продукта, вы можете с официального сайта, или у меня с облака, если вдруг, не получиться с сайта производителя.

Далее полученный архив вы распаковываете и запускаете установочный файл, под свою архитектуру Windows , у меня это 64-х битная. Приступаем к установке Jacarta драйвера. Единый клиент Jacarta, ставится очень просто (НАПОМИНАЮ ваш токен в момент инсталляции, должен быть отключен). На первом окне мастера установки, просто нажимаем далее.

Принимаем лицензионное соглашение и нажимаем “Далее”

Чтобы драйвера токенов JaCarta у вас работали корректно, достаточно выполнить стандартную установку.

Если выберете “Выборочную установку”, то обязательно установите галки:

• Драйверы JaCarta
• Модули поддержки
• Модуль поддержки для КриптоПРО

Через пару секунд, Единый клиент Jacarta, успешно установлен.

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

После установки JaCarta PKI, нужно установить КриптоПРО, для этого заходите на официальный сайт.

https://www.cryptopro.ru/downloads

На текущий момент самая последняя версия КриптоПро CSP 4.0.9944. Запускаем установщик, оставляем галку “Установить корневые сертификаты” и нажимаем “Установить (Рекомендуется)”

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

После перезагрузки подключайте ваш USB токен JaCarta. У меня подключение идет по сети, с устройства DIGI, через . В клиенте Anywhere View, мой USB носитель Jacarta, успешно определен, но как Microsoft Usbccid (WUDF), а в идеале должен определиться как JaCarta Usbccid Smartcard, но нужно в любом случае проверить, так как все может работать и так.

Открыв утилиту “Единый клиент Jacarta PKI”, подключенного токена обнаружено не было, значит, что-то с драйверами.

Microsoft Usbccid (WUDF) – это стандартный драйвер Microsoft, который по умолчанию устанавливается на различные токены, и бывает, что все работает, но не всегда. Операционная система Windows по умолчанию, ставит их в виду своей архитектуры и настройки, мне вот лично в данный момент такое не нужно. Что делаем, нам нужно удалить драйвера Microsoft Usbccid (WUDF) и установить драйвера для носителя Jacarta.

Откройте диспетчер устройств Windows, найдите пункт “Считыватели устройств смарт-карт (Smart card readers)” щелкните по Microsoft Usbccid (WUDF) и выберите пункт “Свойства”. Перейдите на вкладку “Драйвера” и нажмите удалить (Uninstall)

Согласитесь с удалением драйвера Microsoft Usbccid (WUDF).

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

После перезагрузки системы, вы можете увидеть установку устройства и драйверов ARDS Jacarta.

Откройте диспетчер устройств, вы должны увидеть, что теперь ваше устройство определено, как JaCarta Usbccid Smartcar и если зайти в его свойства, то вы увидите, что смарт карта jacarta, теперь использует драйвер версии 6.1.7601 от ALADDIN R.D.ZAO, так и должно быть.

Если открыть единый клиент Jacarta, то вы увидите свою электронную подпись, это означает, что смарт карта нормально определилась.

Открываем CryptoPRO, и видим, что криптопро не видит сертификат в контейнере, хотя все драйвера определились как нужно. Есть еще одна фишка.

1. В RDP сессии вы не увидите свой токен, только локально, уж такая работа токена, либо я не нашел как это поправить. Вы можете попробовать выполнить рекомендации по устранению ошибки “Не возможно подключиться к службе управления смарт-картами”.
2. Нужно снять одну галку в CryptoPRO

ОБЯЗАТЕЛЬНО снимите галку “Не использовать устаревшие cipher suite-ы” и перезагрузитесь
.

После этих манипуляций у меня КриптоПРО увидел сертификат и смарт карта jacarta стала рабочей, можно подписывать документы.

Еще можете в устройствах и принтерах, увидеть ваше устройство JaCarta,

Если у вас как и у меня, токен jacarta установлен в виртуальной машине, то вам придется устанавливать сертификат, через console виртуальной машины, и так же дать на нее права ответственному человеку. Если это физический сервер, то там придется давать права на порт управления , в котором так же есть виртуальная консоль.

Когда вы установили все драйвера для токенов Jacarta, вы можете увидеть при подключении по RDP и открытии утилиты “Единый клиент Jacarta PKI” вот такое сообщение с ошибкой:

1. Не запущена служба смарт-карт на локальной машине. Архитектурой RDP-сессии, разработанной Microsoft, не предусмотрено использование ключевых носителей, подключенных к удалённому компьютеру, поэтому в RDP-сессии удалённый компьютер использует службу смарт-карт локального компьютера. Из этого следует что, запуска службы смарт-карт внутри RDP-сессии недостаточно для нормальной работы.
2. Служба управления смарт-картами на локальном компьютере запущена, но недоступна для программы внутри RDP-сессии из-за настроек Windows и/или RDP-клиента.\

Как исправить ошибку “Не возможно подключиться к службе управления смарт-картами”.

• Запустите службу смарт-карт на локальной машине, с которой вы инициируете сеанс удалённого доступа. Настройте её автоматический запуск при старте компьютера.
• Разрешите использование локальных устройств и ресурсов во время удалённого сеанса (в частности, смарт-карт). Для этого, в диалоге “Подключение к удалённому рабочему столу” в параметрах выберите вкладку “Локальные ресурсы”, далее в группе “Локальные устройства и ресурсы” нажмите кнопку “Подробнее…”, а в открывшемся диалоге выберите пункт “Смарт-карты” и нажмите “ОК”, затем “Подключить”.

• Убедитесь в сохранности настроек RDP-подключения. По умолчанию они сохраняются в файле Default.rdp в каталоге “Мои Документы” Проследите, чтобы в данном файле присутствовала строчка “redirectsmartcards:i:1”.
• Убедитесь в том, что на удалённом компьютере, к которому вы осуществляете RDP-подключение, не активирована групповая политика
  -[Конфигурация компьютера\административные шаблоны\компоненты windows\службы удалённых рабочих столов\узел сеансов удалённых рабочих столов\перенаправление устройств и ресурсов\Не разрешать перенаправление устройства чтения смарт-карт]. Если она включена (Enabled), то отключите её, и перегрузите компьютер.
• Если у вас установлена Windows 7 SP1 или Windows 2008 R2 SP1 и вы используете RDC 8.1 для соединения с компьютерами под управлением Windows 8 и выше, то вам необходимо установить обновление для операционной системы https://support.microsoft.com/en-us/kb/2913751

Вот такой вот был траблшутинг по настройке токена Jacarta, КриптоПРО на терминальном сервере, для подписи документов в ВТБ24 ДБО. Если есть замечания или поправки, то пишите их в комментариях.