Проблемы сертификации: Эпизод II - Правила использования. Где взять данные для установки SSL-сертификата? Сертификат расширение использование ключа

Я рассказывал о не очевидных причинах возникновения ошибки "Keyset does not exist" и о методах борьбы с ней. А именно: речь шла о правах доступа к файлу приватного ключа сертификата. Продолжая начатую тему странных сообщений CryptoAPI , я хочу рассказать о не менее загадочной ошибке - "Bad key" .

Bad key
Текст сообщения об ошибке, возникающей при попытке расшифровать данные, поражает своей лаконичностью - предположить можно всё что угодно. При этом не имеет значения, каким средством дешифрования вы пользовались: нативной функцией CryptDecrypt из библиотеки CryptoAPI , или методом Decrypt класса RSACryptoServiceProvider из пространства имён System.Security.Cryptography . На самом же деле данная ошибка с высокой долей вероятности означает, что используемый сертификат всего-навсего не предназначен для обмена данными.

Эта проблема наиболее характерна для тестовых сертификатов, сгенерированных утилитой makecert.exe , и применяемых отделом контроля качества. Но бывает, что в данную ловушку попадает и клиент. Если приложению требуется сертификат для шифрования / де-шифрования, то достаточно всего лишь предложить ему воспользоваться sign-only сертификатом, чтобы увидеть жалобы CryptoAPI на "плохой ключ". К сожалению, у этой проблемы есть только одно решение: необходимо сгенерировать или купить правильный сертификат.
Каждый сертификат X.509 содержит следующие поля и расширения, описывающие назначение сертификата:

• Subject"s Key Specification - свойство приватного ключа, может принимать значения 1 (AT_KEYEXCHANGE - ключ для шифрования и подписи) или 2 (AT_SIGNATURE - ключ только для подписи);
• Key Usage - расширение сертификата X.509 v3 ; значение представляет собой битовую маску, каждый бит которой определяет то или иное назначение; например, бит 2, если установлен, определяет, что сертификат может использоваться в процедуре обмена ключами (Key Exchange).
• Extended Key Usage - расширение сертификата X.509 v3 ; представляет собой набор Object Identifier `ов (OID ), определяющих дополнительные назначения сертификата; например, добавление OID `а 1.3.6.1.5.5.7.3.2 определяет, что сертификат может использоваться для аутентификации клиентов.

Примечательным является то, что все вышеперечисленные свойства и расширения по сути является независимыми друг от друга. Они могут появляться в сертификате в разных комбинациях и даже противоречить друг другу. К счастью подобные сертификаты - с противоречащими декларациями назначений - являются ошибочными. На сайте Technet`а есть хорошая статья, описывающая в частности, как можно сравнить разные спецификации назначения сертификата на предмет непротиворечивости: http://technet.microsoft.com/en-us/library/dd277392.aspx .

Зачем же нужно такое многообразие деклараций назначений сертификата? Всё очень просто. Как не сложно заметить, каждая последующая декларация расширяет предыдущую. Если Key Specification задаёт только 2 назначения, то Key Usage уже 8, в то время как Extended Key Usage вообще не ограничена сверху. Таким образом, каждое приложение выбирает для проверки то поле, которое наиболее точно соответствует его целям. Если назначение сертификата не соответствует требованиям приложения, оно должно отказаться от его использования и сообщить об ошибке. То есть в общем случае подобная проверка возлагается на само приложение.

К сожалению, в документации отсутствует упоминание того, какие спецификации использования CryptoAPI проверяет автоматически и делает ли она это вообще. Но из этого правила есть, по крайней мере, одно исключение: проверка Key Specification выполняется автоматически. И происходит это вот почему. В отличие от расширений Key Usage и Extended Key Usage , которые являются по сути всего лишь декларациями о намерениях, Key Specification определяет алгоритм, применяемый с ключом сертификата. Поэтому попытка применить для операций шифрования / де-шифрования ключ, предназначенный для формирования цифровой подписи, заканчивается ошибкой Bad key .

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

Данные для установки SSL-сертификата отправляются после его выпуска и активации . Они высылаются на контактный e-mail сертификата. Некоторые данные (CSR-запрос и приватный ключ) генерируются только во время покупки SSL-сертификата и не высылаются в письме..

Как узнать, на какой контактный e-mail отправлено сообщение?

Если SSL-сертификат заказывался через партнёра сайт, контактный e-mail указан на сайте партнёра.

Готово! Вы узнали e-mail, на который были высланы данные SSL-сертификата.

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

Начало письма с данными для установки

В письме вы найдёте:

• SSL-сертификат (указан после слов «Ваш сертификат предоставлен ниже»);
• Корневой сертификат ;
• Промежуточный сертификат (используется в цепочке с корневым сертификатом. Это значит, что при установке сначала вставляется корневой сертификат, а затем промежуточный с новой строки);
• Запрос на получение сертификата — на базе него центр сертификации сгенерировал и выпустил SSL-сертификат;
• Приватный ключ (для бесплатного сертификата) — после слов «Сохраните приватный ключ на локальном компьютере». Приватный ключ для платного сертификата нужно сохранить на этапе заказа.

Внимание!

Приватный ключ (Private Key) сертификата не хранится на серверах сайт. Скопируйте приватный ключ из письма, вставьте в пустой текстовый файл и сохраните его в формате .txt или .key .

Если вы потеряли или скомпрометировали приватный ключ, текущий SSL-сертификат использовать не удастся. Чтобы решить проблему, переиздайте SSL-сертификат по инструкции: .

Данные в Личном кабинете

Некоторые данные (Сертификат, Корневой + Промежуточный сертификат и CSR-запрос ) дублируются в Личном кабинете. Они представлены в виде файлов, которые вы можете скачать, а затем загрузить при установке SSL-сертификата на сервер.

сертификата Х.509 v3 также допускает определение частных расширений.

Каждое расширение в сертификате может быть либо критичным, либо некритичным. Система, использующая сертификаты, должна отвергать сертификат, если она встретила критичное расширение, которое не в состоянии распознать; однако некритичные расширения могут игнорироваться, если они не распознаются. Рассмотрим рекомендуемые в 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 . Значение идентификатора ключа субъекта должно быть значением, указанным в поле идентификатора ключа сертификационного центра, который выпустил сертификат для данного субъекта.

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

1. keyIdentifier получается из 160-битного хэша SHA-1 значения битовой строки subjectPublicKey (исключая тег, длину и неиспользуемые биты).
2. keyIdentifier получается из четырех битов поля типа со значением 0100, следующим за младшими 60 битами хэша SHA-1 значения битовой строки subjectPublicKey (исключая тег, длину и неиспользуемые биты).

Метод создания уникальных значений состоит в использовании монотонно возрастающей последовательности целых чисел.

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

Данное расширение не должно быть помечено как критичное.

id-ce-subjectKeyIdentifier OBJECT IDENTIFIER::= { id-ce 14 } SubjectKeyIdentifier::= KeyIdentifier

Для установки личного сертификата с проставленной ссылкой на закрытый ключ используется приложение КриптоПро CSP. Запустить его в ОС Windows можно выполнив Пуск >> Все программы >> КРИПТО-ПРО >> КриптоПро CSP. В появившемся окне приложения нужно выбрать вкладку Сервис и в ней нажать на кнопку Установить личный сертификат . Далее следует указать расположение файла сертификата (файл с расширением.cer) и нажать кнопку Далее . Окно просмотра свойств сертификата позволяет убедиться, что выбран правильный сертификат; после проверки снова нажмите на кнопку Далее .

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

ВАЖНО! В этом шаге используются только съемные USB-носители или смарт-карты, а также реестр операционной системы.

Приложение КриптоПРО CSP версии 3.9 позволяет найти контейнер автоматически путем проставления соответствующего флажка; более ранние версии после нажатия кнопки Обзор предоставляют список имеющихся носителей, из которых требуется выбрать нужный. После выбора контейнера нажмите Далее . Следующее окно позволяет задать параметры установки сертификата в хранилище. Выбрав необходимое хранилище, нажмите на кнопку Далее .

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

Установка сертификата и закрытого ключа

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

Если вы еще не разобрались что такое Электронная подпись, то пожалуйста ознакомьтесь Или если еще не получили электронную подпись , обратитесь в Удостоверяющий центр, рекомендуем СКБ-Контур.

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

1. Убедитесь что КриптоПро CSP 4 установлен на вашем компьютере

Для этого зайдите в меню Пуск КРИПТО-ПРО КриптоПро CSP запустите его и убедитесь что версия программы не ниже 4-й.

Если ее там нет, то скачайте, установите и перезапустите браузер.

2. Если у вас токен (Рутокен например)

Прежде чем система сможет с ним работать понадобится установить нужный драйвер.

• Драйверы Рутокен: https://www.rutoken.ru/support/download/drivers-for-windows/
• Драйверы eToken: https://www.aladdin-rd.ru/support/downloads/etoken
• Драйверы JaCarta: https://www.aladdin-rd.ru/support/downloads/jacarta

Алгоритм такой: (1) Скачиваем; (2) Устанавливаем.

3. Если закрытый ключ в виде файлов

Закрытый ключ может быть в виде 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, он исчезнет после перезагрузки. Такой способ можно использовать если вы планируете установить ключи в реестр)

Нашли файлы, записали на флешку, переходим к следующему шагу.

4. Установка сертификата из закрытого ключа

Теперь нам нужно получить сертификат, сделать это можно следующим образом:

1. Открываем КриптоПро CSP
2. Заходим на вкладку Сервис
3. Нажимаем кнопку Просмотреть сертификаты в контейнере , нажимаем Обзор и здесь (если на предыдущих шагах сделали все правильно) у нас появится наш контейнер. Нажимаем кнопку Далее , появятся сведения о сертификате и тут нажимаем кнопку Установить (программа может задать вопрос проставить ли ссылку на закрытый ключ, ответьте "Да")
4. После этого сертификат будет установлен в хранилище и станет возможным подписание документов (при этом, в момент подписания документа, нужно будет чтобы флешка или токен были вставлены в компьютер)

5. Использование электронной подписи без токена или флешки (установка в реестр)

Если скорость и удобство работы для вас стоит чуть выше чем безопасность, то можно установить ваш закрытый ключ в реестр Windows. Для этого нужно сделать несколько простых действий:

1. Выполните подготовку закрытого ключа, описанную в пунктах (2) или (3)
2. Далее открываем КриптоПро CSP
3. Заходим на вкладку Сервис
4. Нажимаем кнопку Скопировать
5. С помощью кнопки Обзор выбираем наш ключ
6. Нажимаем кнопку Далее , потом придумаем какое-нибудь имя, например "Пупкин, ООО Ромашка" и нажимаем кнопку Готово
7. Появится окно, в котором будет предложено выбрать носитель, выбираем Реестр, жмем Ок
8. Система попросит Установить пароль для контейнера, придумываем пароль, жмем Ок

Важное замечание: портал OpenSRO не "увидит" сертификат, если вышел срок его действия.