Каждое расширение в сертификате может быть либо критичным, либо некритичным. Система, использующая сертификаты, должна отвергать сертификат, если она встретила критичное расширение, которое не в состоянии распознать; однако некритичные расширения могут игнорироваться, если они не распознаются. Рассмотрим рекомендуемые в Internet расширения сертификатов. Могут использоваться дополнительные расширения; однако следует осторожно устанавливать любые критические расширения в сертификаты, так как это может препятствовать проверке действительности сертификатов.
Каждое расширение должно иметь соответствующий OID и определяться ASN.1-структурой. Когда расширение появляется в сертификате, OID появляется как поле extnID , и соответствующая ASN.1 структура представления является значением строки октетов extnValue . Сертификат не должен включать более одного экземпляра конкретного расширения. Например, сертификат может содержать только одно расширение для идентификатора ключа уполномоченного органа. Расширение включает булево значение критичности со значением по умолчанию, равным FALSE . Для каждого расширения должны быть определены допустимые значения для поля критичности.
САs должны поддерживать расширения для идентификатора ключа, основных ограничений использования ключа и политик сертификатов. Если СА выпустил сертификаты с пустой последовательностью для поля субъекта, СА должен указать расширение альтернативного имени субъекта. Поддержка оставшихся расширений необязательна. САs могут поддерживать расширения, которые текущим стандартом не определены; при этом сертификационные центры должны учитывать, что расширения, помеченные как критичные, могут препятствовать интероперабельности.
Как минимум должны распознаваться следующие расширения: использование ключа, политики сертификата , альтернативное имя субъекта, базовые ограничения, ограничения имени, расширенное использование ключа и запрет произвольной политики.
Могут также распознаваться расширения идентификаторов ключа сертификационного центра и субъекта и расширение отображения политики.
Рассмотрим стандартные расширения сертификата, определенные в стандарте X.509. Каждое расширение имеет определенный OID. Эти OIDs являются элементами id-ce множества, которое определено следующим образом:
id-ce OBJECT IDENTIFIER::= { joint-iso-ccitt(2) ds(5) 29 }
Расширение для идентификатора ключа сертификационного центра предоставляет способ идентификации открытого ключа, соответствующего закрытому ключу, который использовался для подписывания сертификата. Данное расширение используется, когда выпускающий имеет несколько ключей для подписывания. Идентификация может быть основана либо на идентификаторе ключа (идентификатор ключа субъекта в сертификате выпускающего), либо на имени выпускающего и серийном номере.
Поле keyIdentifier расширения authorityKeyIdentifier должно быть включено во все сертификаты, выпущенные СА для обеспечения возможности создания сертификационного пути . Существует одно исключение: когда СА распространяет свой открытый ключ в форме самоподписанного сертификата , идентификатор ключа уполномоченного органа может быть опущен. Подпись для самоподписанного сертификата создается закрытым ключом, соответствующим открытому ключу субъекта. Это доказывает, что выпускающий обладает как открытым ключом, так и закрытым. В таком случае идентификаторы субъекта и уполномоченного органа должны быть одинаковыми, и идентификатор ключа может быть указан только для открытого ключа субъекта.
Значение поля keyIdentifier должно быть получено из открытого ключа, используемого для проверки подписи сертификата, или методом, который создает уникальные значения. Рассмотрим два метода создания идентификаторов ключей из открытого ключа и один метод создания уникальных значений для keyIdentifier . Если идентификатор ключа не был предварительно определен, рекомендуется использовать один из этих методов для создания keyIdentifiers . Если идентификатор ключа был предварительно определен, СА должен задействовать предварительно определенный идентификатор.
Данное расширение не должно помечаться как критичное.
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER::= { id-ce 35 } AuthorityKeyIdentifier::= SEQUENCE { keyIdentifier KeyIdentifier OPTIONAL, authorityCertIssuer GeneralNames OPTIONAL, authorityCertSerialNumber CertificateSerialNumber OPTIONAL } KeyIdentifier::= OCTET STRING
Расширение идентификатора ключа субъекта предоставляет способ идентификации сертификата, содержащего конкретный открытый ключ.
Для упрощения создания сертификационного пути данное расширение должно появляться во всех сертификатах СА, т.е. во всех сертификатах, в которых значение сА есть TRUE . Значение идентификатора ключа субъекта должно быть значением, указанным в поле идентификатора ключа сертификационного центра, который выпустил сертификат для данного субъекта.
Для сертификатов СА идентификаторы ключа субъекта должны быть получены из открытого ключа или методом, который создает уникальные значения. Существует два метода для создания идентификаторов ключей из открытого ключа:
Метод создания уникальных значений состоит в использовании монотонно возрастающей последовательности целых чисел.
Для сертификатов конечных участников расширение идентификатора ключа субъекта предоставляет способы для идентификации сертификатов, содержащих конкретный открытый ключ, используемый в приложении. Если конечный участник получает несколько сертификатов, возможно от нескольких САs, идентификатор ключа субъекта обеспечивает способы быстрого поиска конкретного открытого ключа, содержащегося в некотором множестве сертификатов. Для того чтобы помочь приложениям идентифицировать соответствующий сертификат конечного участника, данное расширение должно быть включено во все сертификаты конечного участника.
Данное расширение не должно быть помечено как критичное.
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER::= { id-ce 14 } SubjectKeyIdentifier::= KeyIdentifier
Установка сертификата и закрытого ключа
Мы опишем установку сертификата электронной подписи и закрытого ключа для ОС семейства Windows. В процессе настройки нам понадобятся права Администратора (поэтому нам может понадобится сисадмин, если он у вас есть).
Если вы еще не разобрались что такое Электронная подпись, то пожалуйста ознакомьтесь Или если еще не получили электронную подпись , обратитесь в Удостоверяющий центр, рекомендуем СКБ-Контур.
Хорошо, предположим у вас уже есть электронная подпись (токен или флешка), но OpenSRO сообщает что ваш сертификат не установлен, такая ситуация может возникнуть, если вы решили настроить ваш второй или третий компьютер (разумеется подпись не "прирастает" только к одному компьютеру и ее можно использовать на нескольких компьютерах). Обычно первоначальная настройка осуществляется с помощью техподдержки Удостоверяющего центра, но допустим это не наш случай, итак поехали.
Для этого зайдите в меню Пуск КРИПТО-ПРО КриптоПро CSP запустите его и убедитесь что версия программы не ниже 4-й.
Если ее там нет, то скачайте, установите и перезапустите браузер.
Прежде чем система сможет с ним работать понадобится установить нужный драйвер.
Алгоритм такой: (1) Скачиваем; (2) Устанавливаем.
Закрытый ключ может быть в виде 6 файлов: header.key , masks.key , masks2.key , name.key , primary.key , primary2.key
Тут есть тонкость если эти файлы записаны на жесткий диск вашего компьютера, то КриптоПро CSP не сможет их прочитать, поэтому все действия надо производить предварительно записав их на флешку (съемный носитель), причем нужно расположить их в папку первого уровня, например: E:\Andrey\{файлики} , если расположить в E:\Andrey\keys \{файлики} , то работать не будет.
(Если вы не боитесь командной строки, то съемный носитель можно сэмулировать примерно так: subst x: C:\tmp появится новый диск (X:), в нем будет содержимое папки C:\tmp, он исчезнет после перезагрузки. Такой способ можно использовать если вы планируете установить ключи в реестр)
Нашли файлы, записали на флешку, переходим к следующему шагу.
Теперь нам нужно получить сертификат, сделать это можно следующим образом:
Если скорость и удобство работы для вас стоит чуть выше чем безопасность, то можно установить ваш закрытый ключ в реестр Windows. Для этого нужно сделать несколько простых действий:
Важное замечание: портал OpenSRO не "увидит" сертификат, если вышел срок его действия.
Я рассказывал о не очевидных причинах возникновения ошибки "Keyset does not exist"
и о методах борьбы с ней. А именно: речь шла о правах доступа к файлу приватного ключа сертификата. Продолжая начатую тему странных сообщений CryptoAPI
, я хочу рассказать о не менее загадочной ошибке - "Bad key"
.
Bad key
Текст сообщения об ошибке, возникающей при попытке расшифровать данные, поражает своей лаконичностью - предположить можно всё что угодно. При этом не имеет значения, каким средством дешифрования вы пользовались: нативной функцией CryptDecrypt
из библиотеки CryptoAPI
, или методом Decrypt
класса RSACryptoServiceProvider
из пространства имён System.Security.Cryptography
. На самом же деле данная ошибка с высокой долей вероятности означает, что используемый сертификат всего-навсего не предназначен для обмена данными.
Эта проблема наиболее характерна для тестовых сертификатов, сгенерированных утилитой makecert.exe
, и применяемых отделом контроля качества. Но бывает, что в данную ловушку попадает и клиент. Если приложению требуется сертификат для шифрования / де-шифрования, то достаточно всего лишь предложить ему воспользоваться sign-only
сертификатом, чтобы увидеть жалобы CryptoAPI
на "плохой ключ". К сожалению, у этой проблемы есть только одно решение: необходимо сгенерировать или купить правильный сертификат.
Каждый сертификат X.509
содержит следующие поля и расширения, описывающие назначение сертификата:
Зачем же нужно такое многообразие деклараций назначений сертификата? Всё очень просто. Как не сложно заметить, каждая последующая декларация расширяет предыдущую. Если Key Specification задаёт только 2 назначения, то Key Usage уже 8, в то время как Extended Key Usage вообще не ограничена сверху. Таким образом, каждое приложение выбирает для проверки то поле, которое наиболее точно соответствует его целям. Если назначение сертификата не соответствует требованиям приложения, оно должно отказаться от его использования и сообщить об ошибке. То есть в общем случае подобная проверка возлагается на само приложение.
К сожалению, в документации отсутствует упоминание того, какие спецификации использования CryptoAPI проверяет автоматически и делает ли она это вообще. Но из этого правила есть, по крайней мере, одно исключение: проверка Key Specification выполняется автоматически. И происходит это вот почему. В отличие от расширений Key Usage и Extended Key Usage , которые являются по сути всего лишь декларациями о намерениях, Key Specification определяет алгоритм, применяемый с ключом сертификата. Поэтому попытка применить для операций шифрования / де-шифрования ключ, предназначенный для формирования цифровой подписи, заканчивается ошибкой Bad key .
Напоследок приведу пример команды, позволяющей сгенерировать тестовый сертификат, который можно применять в операциях шифрования.
Электронная цифровая подпись это набор специальных символов, предназначенных для:
Для того, что начать пользоваться сертификатом ключа электронной подписи по его прямому назначению – как юридически значимого реквизита электронного документа необходимо установить сертификат ЭЦП на компьютер или компьютеры, где будет осуществлять работа с электронными документами и непосредственно с электронной подписью.
Необходимо пояснить, что любая ЭЦП состоит из двух видов ключей - закрытого, его еще называют ключевым контейнером, именно за счет него происходит подписание документа и его шифрование и отрытого ключа или говоря проще личного сертификата.
Личный сертификат, представлен в виде файлов с расширением.cer здесь можно просмотреть все данные о владельце электронной подписи. Такой открытый ключ необходим для того, что бы провести проверку подлинности документов. Установить сертификат ЭЦП для открытого ключа можно и нужно на все компьютеры, на которые будет поступать электронная корреспонденция.
В состав закрытого ключа входит шесть файлов, каждый из них имеет расширение.key. В том случае если эта папка утеряна или повреждена, закрытый ключ работать не будет, и придется обращаться в УЦ за перевыпуском сертификата электронной подписи.
Ключи ЭЦП, как правило, хранится на специальных ключевых носителях, раньше с этой целью использовались обычные магнитные дискеты, но время показало их ненадежность и недолговечность, поэтому сегодня все чаще используются такие сертифицированные носители как RuToken. Рутокен защищается специальным паролем, благодаря чему доступ к информации на нем обеспечивается только непосредственно владельцу сертификата, которому известен этот код.
Для того, что бы установить сертификат ЭЦП на свой компьютер пользователю необходимо зайти в закладку Панель Управления в программе КриптоПро, там выбрать вкладку под названием Сервис, после чего щелкнуть по Просмотр сертификатов в контейнере. В появившемся окне выбираем кнопку Обзор и выбираем сертификат, который необходимо добавить. Нажимаем кнопку Далее, в окне Свойства появляется всплывающая вкладка Сертификата, нажимаем Установить сертификат.
Затем перед пользователем появляется Мастер импорта сертификата, в нем выбираем значение Поместить и отбираем сертификаты и хранилище для них, если все удалось сделать правильно перед пользователем должно появиться окно в котором сообщается, что сертификат был успешно установлен.
Все
тарифы на электронные подписи Вы можете посмотреть
в разделе .
