Есть закрытый ключ для этого сертификата что это значит
Установка личного сертификата с привязкой к закрытому ключу
Установка личного сертификата с привязкой к закрытому ключу
Проверка наличия сертификата в контейнере
Перед установкой личного сертификата с носителя ruToken или eToken необходимо проверить наличие сертификата в контейнере, для этого:
Откройте вкладку «Сервис» и нажмите кнопку «Просмотреть сертификаты в контейнере»
В открывшемся окне нажмите кнопку «Обзор»
Выберите контейнер, который необходимо проверить на наличие в нем сертификата, и нажмите кнопку «Ок»
После того, как в поле «Имя ключевого контейнера» установится название контейнера, нажмите кнопку «Далее»
Если откроется окно «Введите pin-код для контейнера», необходимо ввести Pin-код для носителя.
Pin-код по умолчанию: 12345678
Если появится сообщение «В контейнере закрытого ключа **** отсутствует сертификат открытого ключа шифрования», значит в контейнере отсутствует личный сертификат.
Если открылось окно «Сертификат для просмотра», значит в контейнере есть личный сертификат и вы можете его установить.
Экспорт личного сертификата
Для установки сертификата нажмите кнопку «Свойства»
Во вкладке «Состав» нажмите кнопку «Копировать в файл. »
Для подтверждения копирования нажмите кнопку «Далее»
Для подтверждения копирования нажмите кнопку «Далее»
Для подтверждения копирования нажмите кнопку «Далее»
В следующем окне нажмите кнопку «Обзор. »
1. Выбирете рабочий стол
2. Напишите имя файла Например :«Сертификат»
3. Нажмите кнопку «Сохранить»
Для подтверждения копирования нажмите кнопку «Далее»
Для подтверждения копирования нажмите кнопку «Готово»
После того как Экспорт будет выполнен успешно нажмите кнопку «ОК»
Установка личного сертификата
Откройте вкладку «Сервис» и нажмите кнопку «Установить личный сертификт. »
В открывшемся окне нажмите кнопку «Обзор»
В следующем окне нажмите кнопку «Далее»
В следующем окне нажмите кнопку «Далее»
В следующем окне нажмите кнопку «Обзор»
В следующем окне нажмите кнопку «Далее»
В следующем окне нажмите кнопку «Обзор»
В следующем окне нажмите кнопку «Далее»
В следующем окне нажмите кнопку «Готово»
Токены PKCS#11: сертификаты и закрытые ключи
Токены PKCS#11 выполняют не только криптографические функции (генерация ключевых пар, формирование и проверка электронной подписи и другие), но и являются хранилищем для публичных (открытых, PUBLIC KEY) и приватных (закрытых, PRIVATE KEY) ключей. На токене также могут храниться сертификаты. Как правило, на токене хранятся личные сертификаты вместе с ключевой парой. При этом на токене может храниться несколько личных сертификатов.
Встает дилемма, как определить какой закрытый ключ (да и открытый тоже) соответствует тому или иному сертификату.
Такое соответствие, как правило, устанавливается путем задание идентичных параметров CKA_ID и/или CKA_LABEL для тройки объектов: сертификата (CKO_CERTIFICATE), публичного ключа (CKO_PUBLIC_KEY) и приватного ключа (CKO_PRIVATE_KEY).
Возникает вопрос – как задавать эти значения, чтобы, по крайней мере, не возникла коллизия, и насколько это безопасно с точки зрения получения корректного результата.
Наиболее распространенный способ задания CKA_ID – это использование значения хэш-функции от значения открытого ключа. Именно такой способ для связывания тройки объектов используется в проекте NSS (Network Security Services). При этом в качестве хэш-функции используется алгоритм SHA1. С учетом того, что на токене реально будет храниться едва ли больше десятка личных сертификатов, то с точки зрения появления коллизии этот способ является хорошим. Вместе с тем CKA_ID для этой тройки могут устанавливаться в любой момент и любое значение. Именно в этом и состоит вся проблема. Если бы RFC или Рекомендации ТК-26 требовали установки параметра CKA_ID в момент появления объекта на токене (например, при генерации ключевой пары CKM_GOSTR3410_KEY_GEN_PAIR) и его нельзя было бы изменить, то на этом данное повествование можно было бы завершить. К сожалению, это не так. Как уже было сказано, CKA_ID можно установить в любой момент с любым значением. Таким образом, всегда существует вероятность, что сертификат окажется связанным с чужим приватным ключом. Не нужно объяснять, к каким это приведет последствиям.
А вообще, существует ли строгий математический алгоритм, который позволяет связать тройку CKO_CERTIFICATE x CKO_PRIVATE_KEY x CKO_PUBLIC_KEY в единое целое?
Да, такой алгоритм на базе криптографических механизмов (CKM_) токена существует. Связка сертификата и публичного ключа проверяется легко и просто. Берутся значение открытого ключа и его параметров из сертификата и сравниваются и аналогичными значениями публичного ключа.
Что касается сертификата и приватного ключа, то до недавнего времени этот алгоритм выглядел следующим образом. С помощью приватного ключа формируется подпись под некоторым текстом (например, «поиск закрытого ключа»), а затем с помощью открытого ключа, полученного из сертификата, проверяется корректность полученной подписи. Если подпись корректна, значит, мы получили закрытый ключ для выбранного сертификата. Если нет, то выбирается следующий закрытый ключ на токене.
Все, мы теперь не зависим ни от CKA_ID, ни от CKA_LABEL.
Но вот появляется документ «МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ. Расширение PKCS#11 для использования российских стандартов ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, ГОСТ Р 34.12-2015 и ГОСТ Р 34.13-2015», в котором появляется новый механизм CKM_GOSTR3410_PUBLIC_KEY_DERIVE — механизм создания открытого ключа из закрытого. Данный механизм используется в C_DeriveKey. Теперь поиск закрытого ключа для сертификата значительно упрощается. Достаточно получить список закрытых ключей на токене, затем для каждого закрытого ключа получить открытый ключ:
А далее сравниваем значения полученного публичного ключа, со значениями публичного ключа в сертификате.
Применение любого из этих алгоритмов избавляет от необходимости следить за значениями CKA_ID/CKA_LABEL и делает использованием сертификатов и приватных ключей, хранящихся на токенах PKCS#11, и надежным и безопасным.
Использование механизма CKM_GOSTR3410_PUBLIC_KEY_DERIVE предполагает его реализацию на том или другом токене. Посмотреть список реализованных механизмов удобно с помощью утилиты p11conf:
Список доступных механизмов можно посмотреть следующим образом:
Есть закрытый ключ для этого сертификата что это значит
В CSP Крипто Про 4 версии, в отличии от 3 версии, есть ограничение на срок использования закрытого ключа. Вся суть этого неприятного сюрприза для владельца сертификата в том, что сертификат еще действует, а закрытый ключ уже нет. На закрытый ключ проецируется срок действия сертификата. Поскольку закрытый ключ генерируется за несколько дней или недель до создания сертификата, то соответственно закрытый ключ заканчивается раньше на несколько дней или недель. Как так то. — была моя первая реакция. Но, к счастью, это можно победить.
Как узнать срок действия закрытого ключа?
В КриптоПро вкладка «Сервис» — кнопка «Протестировать» — кнопка «Обзор» — выбираем контейнер закрытого ключа который надо протестировать — кнопка «Далее» — вводим пароль от контейнера. В окне «Тестирование контейнера закрытого ключа» видим две разные даты. Если срок действия закрытого ключа 26 сентября уже наступил, то электронная подпись не работает, хотя сертификат действителен по 28 сентября.
Для продления закрытого ключа надо сделать экспорт сертификата и закрытого ключа в формат PFX и потом сделать установку из файла PFX.
Экспорт закрытого ключа с сертификатом в формат PFX
Формат PFX на сегодняшний день является единственным стандартным способом для хранения закрытых ключей и сертификатов в одном зашифрованном файле.
Файл PXF делаем с помощью КриптоПро. Вкладка «Сервис» — кнопка «Просмотреть сертификаты в контейнере».
Выбираем ключевой контейнер нажав на кнопку «Обзор».
В окне «Выбор ключевого контейнера» выбираем контейнер (он должен быть с установленным сертификатом, если сертификат не установлен, то вот инструкция как это сделать) и нажимаем «ОК».
В следующем окне нажимаем «Далее».
В следующем окне нажимаем кнопку «Свойства».
Далее — вкладка «Состав» — кнопка «Копировать в файл».
Выбираем «Да, экспортировать закрытый ключ», нажимаем кнопку «Далее».
Выбираем «Файл обмена личной информацией — PKCS #12 (.PFX)» и «Экспортировать все расширенные свойства», нажимаем «Далее».
Задаем пароль и нажимаем «Далее».
Нажимаем «Обзор» чтобы выбрать папку для нашего pxf файла.
Мне проще сохранить pxf файл на рабочем столе. Задаю имя и нажимаю «Сохранить».
Вводим пароль и нажимаем «ОК».
Экспорт успешно завершен.
В результате экспорта на рабочем столе получим такой файл.
Импорт закрытого ключа с сертификатом из формата PFX
Кликаем по файлу PFX и видим окно «Мастер импорта сертификатов», нажимаем «Далее».
В следующем окне нажимаем «Далее».
Вводим пароль от закрытого ключа, нажимаем «Далее».
Хранилище выбираем автоматически, нажимаем «Далее».
Нажимаем кнопку «Готово».
Далее будут стандартные запросы от КриптоПро — выбор носителя для хранения контейнера и пароли. При этом имя контейнера будет выглядеть как случайный набор символов. В финале увидим такое сообщение.
В результате вышеописанных действий срок действия закрытого ключа составит 1 год и 3 месяца от даты манипуляций с файлом PFX.
Есть закрытый ключ для этого сертификата что это значит
Данное действие необходимо выполнять после развертывания экземпляров служб.
Назначить права доступа к закрытому ключу можно в оснастке «Сертификаты». Для запуска оснастки выполните следующие шаги: Пуск – Выполнить – mmc. В открывшейся консоли управления выберите: Файл – Добавить или удалить оснастку. В открывшемся окне выберите оснастку «Сертификаты» и нажмите кнопку «Добавить».
Далее в диалоге «Оснастка диспетчера сертификатов» выберите пункт «Учетной записи компьютера» и нажмите «Далее».
В качестве компьютера, которым будет управлять данная оснастка, необходимо указать локальный компьютер.
Далее в разделе Сертификаты (локальный компьютер) – Личное – Сертификаты выберите нужный сертификат. Нажмите правой кнопкой мыши по выбранному сертификату и выберите: Все действия – Управление закрытыми ключами.
В открывшемся окне необходимо добавить учётную запись пула приложений и установить для неё полные права на доступ к закрытому ключу.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Перенос сертификатов и закрытых ключей CryptoPro хранящихся в реестре
КриптоПро один из наиболее широко используемых криптопровайдеров на территории Российской Федерации, он широко используется в системах электронного документооборота, сдачи отчетности и взаимодействия с государственными органами, поэтому встретить его можно практически в любой организации. По этой причине у системных администраторов часто встает вопрос его переноса на другой ПК. А так как криптография является для многих сложной и непонятной областью, то эта простая задача может вызвать некоторые затруднения.
Если вы ранее не сталкивались с криптографией вообще, то рекомендуем прочитать нашу статью: Введение в криптографию. Общие вопросы, проблемы и решения. Здесь мы не будем углубляться в теорию, но приведем некоторый необходимый ликбез.
В повседневной деятельности широко распространено понятие «сертификат», им оперируют все, от сотрудников удостоверяющих центров, то бухгалтеров, работающих с ЭЦП. Часто можно услышать что-то подобное: «нам купили в бухгалтерию новый компьютер, нужно перенести сертификаты». Но если подходить с точки зрения криптографии, то слово «сертификат» в данном случае употребляется неправильно. Вся современная криптография строится вокруг инфраструктуры открытых ключей (PKI), которая подразумевает наличие у каждого участника ключевой пары: открытого и закрытого ключа.
Закрытый ключ является секретным, с его помощью мы можем подписывать документы, шифровать информацию и т.д. и т.п. Закрытый ключ Усиленной квалифицированной электронной подписи (УКЭП) равнозначен нотариально заверенной подписи и его попадание в чужие руки может привести к самым тяжелым последствиям.
Открытый ключ, дополненный некоторыми дополнительными данными, выпускается в форме сертификата и является публично доступным, с его помощью можно проверить действительность цифровой подписи, выполненной закрытым ключом или убедиться в подлинности участника обмена электронными документами.
Поэтому, когда мы говорим о переносе «сертификатов», то подразумеваем необходимость перенести ключевую пару: закрытый ключ и сертификат, перенос одних только сертификатов не принесет успеха, криптография на новом узле работать не будет.
Выяснив этот момент, перейдем к хранилищам закрытых ключей. КриптоПро предполагает в таком качестве токены, флеш-накопители и системный реестр. Токены являются наиболее защищенными устройствами, извлечь закрытый ключ из них невозможно, и вы можете не опасаться несанкционированного копирования (для этого закрытый ключ должен быть помечен как неэкспортируемый). Флеш-накопители представляют некий компромисс между безопасностью и мобильностью, а реестр удобен в тех случаях, когда на одном ПК нужно одновременно работать с большим количеством ключей. И именно с ним связаны определенные сложности при переносе на другой узел.
Экспорт ключей и сертификатов
Для того, чтобы правильно экспортировать закрытые ключи, нам нужно выяснить идентификатор безопасности ( SID) текущего пользователя (который работает с ЭЦП), это можно сделать командной:
Затем откроем редактор реестра и перейдем в ветку для 32-битных систем:
для 64-битных систем:
Найдем и раскроем раздел с SID текущего пользователя и экспортируем оттуда ветку Keys.
Обратите внимание, что данная ветка содержит закрытые ключи, поэтому следует принять все меры безопасности и не передавать файл экспорта по открытым каналам связи и вообще исключить к нему несанкционированный доступ посторонних лиц.
После чего скопируем все сертификаты, расположенные по пути
Это открытые ключи, никакой секретности они не представляют, поэтому просто копируем их любым доступным способом.
Импорт ключей и сертификатов
Прежде всего установим на новый узел КриптоПро, обратите внимание, что переносить ключи и сертификаты следует между одинаковыми версиями. В противном случае либо обновите версию КриптоПро на старой системе, либо установите старую версию на новой и обновите ее уже после переноса ключевых пар.
Затем снова узнаем SID пользователя, который будет работать с ЭЦП, если это текущий пользователь, то снова выполните:
В противном случае:
После чего откройте на редактирование файл реестра с экспортированными закрытыми ключами и замените в нем все вхождения старого SID на SID нового пользователя.
Сохраните файл и импортируйте его в реестр. Закрытые ключи перенесены, файл переноса в целях безопасности следует удалить.
Следующим шагом скопируйте сохраненные сертификаты в
После чего можно устанавливать и настраивать приложения работающие с криптографией, все будет работать.
Как быть если доступ к старой системе невозможен?
С копированием сертификатов проблемы возникнуть не должно, их хранилище простая папка на диске, а вот с хранилищем закрытых ключей в реестре немного сложнее. Но не будем забывать, что системный реестр тоже хранится в файлах на диске. Вам следует любым доступным образом скопировать файл SOFTWARE из C:\Windows\System32\config
После чего пройдите в раздел с закрытыми ключами (с учетом новой точки монтирования) и выполните экспорт ветки Keys.
Дальнейшие действия ничем не отличаются от описанных нами в разделе Импорт ключей и сертификатов.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 