есть закрытый ключ для этого сертификата что это значит
Установка сертификата и закрытого ключа
Мы опишем установку сертификата электронной подписи и закрытого ключа для ОС семейства Windows. В процессе настройки нам понадобятся права Администратора (поэтому нам может понадобится сисадмин, если он у вас есть).
Если вы еще не разобрались что такое Электронная подпись, то пожалуйста ознакомьтесь вот с этой инструкцией. Или если еще не получили электронную подпись, обратитесь в Удостоверяющий центр, рекомендуем СКБ-Контур.
Хорошо, предположим у вас уже есть электронная подпись (токен или флешка), но OpenSRO сообщает что ваш сертификат не установлен, такая ситуация может возникнуть, если вы решили настроить ваш второй или третий компьютер (разумеется подпись не «прирастает» только к одному компьютеру и ее можно использовать на нескольких компьютерах). Обычно первоначальная настройка осуществляется с помощью техподдержки Удостоверяющего центра, но допустим это не наш случай, итак поехали.
1. Убедитесь что КриптоПро CSP 4 установлен на вашем компьютере
Для этого зайдите в меню Пуск КРИПТО-ПРО КриптоПро CSP запустите его и убедитесь что версия программы не ниже 4-й.
Если ее там нет, то скачайте, установите и перезапустите браузер.
2. Если у вас токен (Рутокен например)
Прежде чем система сможет с ним работать понадобится установить нужный драйвер.
Алгоритм такой: (1) Скачиваем; (2) Устанавливаем.
Для токена может понадобиться стандартный (заводской) пин-код, здесь есть стандартные пин-коды носителей.
3. Если закрытый ключ в виде файлов
Тут есть тонкость если эти файлы записаны на жесткий диск вашего компьютера, то КриптоПро CSP не сможет их прочитать, поэтому все действия надо производить предварительно записав их на флешку (съемный носитель), причем нужно расположить их в папку первого уровня, например: E:\Andrey\ <файлики>, если расположить в E:\Andrey\keys\ <файлики>, то работать не будет.
(Если вы не боитесь командной строки, то съемный носитель можно сэмулировать примерно так: subst x: C:\tmp появится новый диск (X:), в нем будет содержимое папки C:\tmp, он исчезнет после перезагрузки. Такой способ можно использовать если вы планируете установить ключи в реестр)
Нашли файлы, записали на флешку, переходим к следующему шагу.
4. Установка сертификата из закрытого ключа
Теперь нам нужно получить сертификат, сделать это можно следующим образом:
5. Использование электронной подписи без токена или флешки (установка в реестр)
Если скорость и удобство работы для вас стоит чуть выше чем безопасность, то можно установить ваш закрытый ключ в реестр Windows. Для этого нужно сделать несколько простых действий:
Чтобы для сертификата проставить ссылку на этот закрытый ключ выполните действия из пункта (4).
Важное замечание: портал OpenSRO не «увидит» сертификат, если вышел срок его действия.
Токены 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:
Список доступных механизмов можно посмотреть следующим образом: