Сертификат расширение использование ключа. Проблемы сертификации: Эпизод II - Правила использования
Каждое расширение в сертификате может быть либо критичным, либо некритичным. Система, использующая сертификаты, должна отвергать сертификат, если она встретила критичное расширение, которое не в состоянии распознать; однако некритичные расширения могут игнорироваться, если они не распознаются. Рассмотрим рекомендуемые в 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 . Значение идентификатора ключа субъекта должно быть значением, указанным в поле идентификатора ключа сертификационного центра, который выпустил сертификат для данного субъекта.
Для сертификатов СА идентификаторы ключа субъекта должны быть получены из открытого ключа или методом, который создает уникальные значения. Существует два метода для создания идентификаторов ключей из открытого ключа:
- keyIdentifier получается из 160-битного хэша SHA-1 значения битовой строки subjectPublicKey (исключая тег, длину и неиспользуемые биты).
- keyIdentifier получается из четырех битов поля типа со значением 0100, следующим за младшими 60 битами хэша SHA-1 значения битовой строки subjectPublicKey (исключая тег, длину и неиспользуемые биты).
Метод создания уникальных значений состоит в использовании монотонно возрастающей последовательности целых чисел.
Для сертификатов конечных участников расширение идентификатора ключа субъекта предоставляет способы для идентификации сертификатов, содержащих конкретный открытый ключ, используемый в приложении. Если конечный участник получает несколько сертификатов, возможно от нескольких САs, идентификатор ключа субъекта обеспечивает способы быстрого поиска конкретного открытого ключа, содержащегося в некотором множестве сертификатов. Для того чтобы помочь приложениям идентифицировать соответствующий сертификат конечного участника, данное расширение должно быть включено во все сертификаты конечного участника.
Данное расширение не должно быть помечено как критичное.
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER::= { id-ce 14 } SubjectKeyIdentifier::= KeyIdentifier
Данные для установки SSL-сертификата отправляются после его выпуска и активации . Они высылаются на контактный e-mail сертификата. Некоторые данные (CSR-запрос и приватный ключ) генерируются только во время покупки SSL-сертификата и не высылаются в письме..
Как узнать, на какой контактный e-mail отправлено сообщение?
Если SSL-сертификат заказывался через партнёра сайт, контактный e-mail указан на сайте партнёра.
Готово! Вы узнали e-mail, на который были высланы данные SSL-сертификата.
Данные для установки в письме
Начало письма с данными для установки
В письме вы найдёте:
- SSL-сертификат (указан после слов «Ваш сертификат предоставлен ниже»);
- Корневой сертификат ;
- Промежуточный сертификат (используется в цепочке с корневым сертификатом. Это значит, что при установке сначала вставляется корневой сертификат, а затем промежуточный с новой строки);
- Запрос на получение сертификата — на базе него центр сертификации сгенерировал и выпустил SSL-сертификат;
- Приватный ключ (для бесплатного сертификата) — после слов «Сохраните приватный ключ на локальном компьютере». Приватный ключ для платного сертификата нужно сохранить на этапе заказа.
Внимание!
Приватный ключ (Private Key) сертификата не хранится на серверах сайт. Скопируйте приватный ключ из письма, вставьте в пустой текстовый файл и сохраните его в формате .txt или .key .
Если вы потеряли или скомпрометировали приватный ключ, текущий SSL-сертификат использовать не удастся. Чтобы решить проблему, переиздайте SSL-сертификат по инструкции: .
Данные в Личном кабинете
Некоторые данные (Сертификат, Корневой + Промежуточный сертификат и CSR-запрос ) дублируются в Личном кабинете. Они представлены в виде файлов, которые вы можете скачать, а затем загрузить при установке 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 определяет, что сертификат может использоваться для аутентификации клиентов.
Зачем же нужно такое многообразие деклараций назначений сертификата? Всё очень просто. Как не сложно заметить, каждая последующая декларация расширяет предыдущую. Если Key Specification задаёт только 2 назначения, то Key Usage уже 8, в то время как Extended Key Usage вообще не ограничена сверху. Таким образом, каждое приложение выбирает для проверки то поле, которое наиболее точно соответствует его целям. Если назначение сертификата не соответствует требованиям приложения, оно должно отказаться от его использования и сообщить об ошибке. То есть в общем случае подобная проверка возлагается на само приложение.
К сожалению, в документации отсутствует упоминание того, какие спецификации использования CryptoAPI проверяет автоматически и делает ли она это вообще. Но из этого правила есть, по крайней мере, одно исключение: проверка Key Specification выполняется автоматически. И происходит это вот почему. В отличие от расширений Key Usage и Extended Key Usage , которые являются по сути всего лишь декларациями о намерениях, Key Specification определяет алгоритм, применяемый с ключом сертификата. Поэтому попытка применить для операций шифрования / де-шифрования ключ, предназначенный для формирования цифровой подписи, заканчивается ошибкой Bad key .
Напоследок приведу пример команды, позволяющей сгенерировать тестовый сертификат, который можно применять в операциях шифрования.
В данном приложении описаны стандарты, которых придерживаются службы сертификации Windows 2000, и конкретное применение этих стандартов. Также описывается, как и где эти стандарты используются службами сертификации. Эти темы раскрываются в следующих подразделах:
Международный союз электросвязи
Международный союз электросвязи (ITU) является организацией, которая определяет стандарты в отрасли связи. Ее членами являются более 150 стран. ITU обеспечивает правительства и частный сектор механизмом, с помощью которого возможно координированное развитие глобальных телекоммуникационный сетей и систем. ITU-T является сектором ITU, отвечающим за стандарты в области телекоммуникаций. ITU-T отвечает за разработку стандартов для сетевых протоколов, за факсимильные системы передачи и за разработку стандартов построения модемов и их работы.
Сертификаты X.509 версии 3
Большинство сертификатов, которые используются сегодня, основаны на стандарте X.509 ITU-T. При работе с сертификатами Windows 2000 придерживается этого стандарта.
Сертификат X.509 содержит в себе открытый ключ и информацию о человеке или объекте, которому этот сертификат был выдан, информацию о самом сертификате, а также дополнительную информацию о центре сертификации (СА), выдающего сертификат. Информация о владельце может включать название объекта (имя, получившего сертификат), открытый ключ, алгоритм открытого ключа и, в качестве опции, уникальный идентификатор владельца. Расширения стандарта позволяет добавлять для сертификата X.509 версии 3 информацию, связанную с идентификаторам ключа, информацию об использовании ключа, политику сертификата, дополнительные названия и атрибуты, ограничения пути сертификации и расширения для отзыва сертификатов, включая причины отзыва и разделение списка CRL, выполняемое при обновлении центра сертификации (CA).
Использование форматов сертификатов промышленного стандарта X.509 версии 3 и открытых интерфейсов позволяет службам сертификации Windows 2000 взаимодействовать со многими другими продуктами и технологиями, поддерживающими использование криптографии на основе открытых ключей и инфраструктуру открытых ключей.
Сообщество IETF
Сообщество IETF (Internet Engineering Task Force, IETF) является открытым международным сообществом проектировщиков сетей, операторов, производителей и исследователей, заинтересованных в развитии архитектуры сети Интернет. Сообщество IETF подразделяется на несколько рабочих групп в соответствии с тематическими разделами. Каждая рабочая группа разрабатывает стандарты для Интернет в соответствии с собственной тематикой. Каждый стандарт публикуется в документе RFC (RFC - Request for Comments) под определенным номером. Впоследствии стандарт может пересматриваться, в результате чего публикуется документ RFC под новым номером, а первоначальный документ считается устаревшим.
Рабочая группа IETF, нацеленная на разработку основ взаимодействия инфраструктуры открытых ключей, получила название PKIX. (Адрес веб-узла PKIX, представлен в разделе "Дополнительная информация"). Стандарты инфраструктуры открытых ключей для сети Интернет все еще разрабатываются. Не смотря на это, Microsoft разрабатывала службы сертификации, придерживаясь существующих стандартов, для обеспечения совместимости с инфраструктурой открытых ключей. В особенности Microsoft заботилась о том, чтобы службы сертификации Windows 2000 соответствовали требованиям документа RFC 2459 (описываемого далее).
Документ RFC 2459
Спецификация RFC 2459 является одним из стандартов, описывающих использование сертификата X.509 инфраструктуры открытых ключей в Интернет. Особенности RFC 2459 описываются в следующих подразделах:
Названия полей в сертификатах
В соответствии с RFC 2459 центры сертификации (CA) Windows 2000 заносят информацию в поля: Имя владельца (Subject name), Имя издателя (Issuer name), Альтернативное имя владельца (Alternate Subject Name) и Альтернативное имена издателей (Alternate Issuer names) в определенной кодировке. В RFC 2459 определены три типа кодировки для применения в сертификатах: PrintableString , BMPString и Unicode Transformation Format 8 (UTF-8) . Использование кодировки TeletexString также разрешено, чтобы обеспечить поддержку клиентов, которые не соответствуют этому RFC. Каждый тип кодировки поддерживает различные наборы символов. Набор символов, используемый в сертификатах, определяет тип кодировки, которая должна использоваться.
По умолчанию используется кодировка PrintableString . Набор символов, которые поддерживаются кодировкой PrintableString , являются подмножеством символов ASCII. Подмножество представлено такими символами:
Если набор символов PrintableString не подходит для использовании, то применяется BMPString . BMPString использует набор символов Unicode, благодаря чему он может применяться для ввода символов из большинства международных наборов символов (в Unicode используется два байта для кодирования каждого символа, что позволяет создать 65,536 комбинаций символов). В том случае, если невозможно использовать набор символов PrintableString, и если известно, что при подаче заявки клиент не поддерживает Unicode, используется набор символов TeletexString . Платформа Windows 2000 в настоящее время не поддерживает кодировку UTF-8 .
Некоторые продукты инфраструктуры открытых ключей не поддерживают Unicode в сертификатах. Отсутствие такой поддержки может привести к проблемам с совместимостью, которые сложно выявить. Большинство производителей высказали свои намерения поддерживать RFC 2459 в своей продукции. Чем больше продуктов будет обновлено и начнет поддерживать этот тип кодировки, тем меньше будет возникать проблем. В настоящее время перед использованием в сертификатах символов отсутствующих в PrintableString, важно проверять, чтобы все продукты инфраструктуры открытых ключей, использующие сертификаты центра сертификации (CA) Windows 2000, могли поддерживать кодировку Unicode, используемую в сертификатах.
Расширения сертификатов
RFC 2459 определяет боьшое количество расширений, большинство из которых являются дополнительными. Большинство расширений включает в себя дополнительные настройки. Одной из самых больших проблем, связанной с совместимостью продуктов инфраструктуры открытых ключей на основе RFC 2459, является большое количество перестановок параметров, которые разрешены этим стандартом.
В Таблице 2 представлены все расширения RFC 2459, которые используют в сертификатах при их создании центры сертификации (CA) Windows 2000.
Таблица 2 – Используемые центром сертификации (СА) Windows 2000 расширения сертификатов RFC 2459
| Тип сертификата | Центры сертификации (CA) предприятия | Изолированные центры сертификации (CA) |
| Сертификат корневого центра сертификации (CA) | (Basic Constraints) Основные ограничения Использование ключа (Subject Key Identifier) (Certificate Template) Шаблон сертификата
| (Basic Constraints) Основные ограничения (Key Usage) (Subject Key Identifier) (CRL Distribution Point (CDP)) (Certificate Template) Шаблон сертификата
Версия центра сертификации (CA) |
| Сертификат подчиненного центра сертификации (CA) | (Basic Constraints) Основные ограничения Использование ключа (CRL Distribution Point (CDP)) Точка распространения списков отзыва (CDP)
Доступ к сведениям о центрах
сертификации (AIA)
Шаблон сертификата
Версия центра сертификации (CA) | (Basic Constraints) Основные ограничения (Key Usage) (CRL Distribution Point (CDP)) Точка распространения списков отзыва (CDP)
(Authority Information Access (AIA)) Версия центра сертификации (CA) |
| Сертификат конечного владельца | (Key Usage) Использование ключа
Использование расширенного ключа
Точка распространения списков отзыва (CDP)
Идентификатор ключа центра сертификации (CA)
(Subject Alternate Name) Альтернативное имя владельца (Certificate Template) Шаблон сертификата | (Key Usage) Использование ключа
Использование расширенного ключа Точка распространения списков отзыва (CDP)
Идентификатор ключа центра сертификации (CA)
Доступ к сведениям о центрах сертификации (AIA) |
Расширения сертификатов и списков CRL
Ниже приводится описание некоторых из наиболее важных расширений сертификатов и списков CRL:
- Расширение Основные ограничения
используется только для сертификатов центров сертификации (СА). Оно содержит логический флаг для указания сертификата центра сертификации (CA). Это расширение помечено как критическое в сертификате. В данный момент центры сертификации (CA) предприятия и изолированные центры сертификации (CA) Windows 2000 не поддерживают опцию длины пути в этом расширении.
Расширение Использование ключа определяет криптографические операции, для которых могут использоваться пары ключей. Возможны следующие варианты использования:
- Цифровая подпись
- Неотрекаемость
- Шифрование ключей
- Шифрование данных
- Согласование ключей
- Подписание сертификатов
- Подписание списка отзыва (CRL)
- Только для подписания. Цифровую подпись разрешено использовать только в сертификатах, предназначенных для подписания.
- Только для обмена ключами. Для сертификатов, которые могут использоваться только для обмена ключами. При этом шифрование ключей и данных выполняется с помощью ключей RSA. Центры сертификации (CA) Windows 2000 не поддерживают открытые ключи Диффи-Хелмана.
- Как для подписания, так и для обмена ключами. Для сертификатов, которые используются как в операциях подписания, так и обмена ключами, разрешено использование цифровой подписи, шифрование ключей и данных.
- Точки распространения списков отзыва (CDP - CRL distribution points). Расширение CDP указывает, где опубликован список CRL. В месте опубликования содержится состояние отзыва сертификата. Центры сертификации (CA) Windows 2000 используют URI-идентификаторы разных типов. По умолчанию центр сертификации (CA) предприятия использует URI-идентификаторы LDAP и HTTP. Изолированный центр сертификации (CA) использует URI-идентификаторы HTTP и FILE. Если необходимо указать дополнительные местонахождения, следует изменить список URI с помощью оснастки Центр сертификации (CA) консоли MMC. Идентификатор ключа центра сертификации (CA) (Authority Key Identifier, AKI). Расширение AKI позволяет определить, какой ключ использовался для подписания сертификата. Это бывает очень полезно в случае, когда производилось обновление центра сертификации (CA), после чего у него может быть несколько ключей. Также центры сертификации (CA) Windows 2000 дополнительно могут включать в сертификаты информацию об издателе и серийном номере сертификата, позволяющую точно определить центр сертификации (CA), выдавший данный сертификат. Такая возможность может быть полезна для использования в высоконадежных приложениях.
- Доступ к сведениям о центрах сертификации (Authority Information Access, AIA). Расширение AIA позволяет определить местонахождение центра сертификации (CA), выдавшего сертификат. Большинство протоколов инфраструктуры открытых ключей включают полную цепочку сертификатов, однако это не гарантируется. Центры сертификации (CA) Windows 2000 используют URI-идентификаторы разных типов. По умолчанию центр сертификации (CA) предприятия использует URI-идентификаторы LDAP и HTTP. Изолированный центр сертификации (CA) использует URI-идентификаторы HTTP и FILE. Если необходимо указать дополнительные местонахождения, следует изменить список URI с помощью оснастки Центр сертификации (CA) консоли MMC.
- Альтернативное имя владельца. У сертификатов пользователей существует много типов названий для их идентификации. Центры сертификации (CA) предприятия в этом расширении могут использовать имена Kerberos и адрес электронной почты.
Особые расширения Windows 2000
Центры сертификации (CA) предприятия Windows 2000 включают в себя два особых расширения Microsoft. Эти расширения используются в задачах управления:
Год 2000 и сертификаты
Сертификаты и списки CRL содержат дату. Для сертификатов дата показывает срок действия. Для списков CRL дата показывает, когда список CRL был создан и когда ожидается следующее опубликование списка CRL. В рекомендации RFC 2459 определено, что для дат с 1949 по 2050 год будет использоваться двухразрядное обозначение года. Для дат после 2050 года будет применяться четырехразрядное обозначение. Службы сертификации Windows 2000 полностью соответствуют этим рекомендациям.
Международные наборы символов и DNS-имена
Сообщество IETF гарантирует, что во всех новых документах RFC включена поддержка международных наборов символов, разрешено использование UTF-8 или определены сроки, в которые должна быть обеспечена поддержка UTF-8 (в стандартах инфраструктуры открытых ключей определено, что полную поддержку UTF-8 должны обеспечить к 2003 году). Не все стадии этого процесса еще завершены. Нерешенным пока остается вопрос, каким образом использовать международный набор символов в URI-идентификаторах. На момент завершения разработки служб сертификации Windows 2000 не существовало еще стандарта, который бы описывал это. URI-идентификаторы указываются в сертификатах для определения того, где были опубликованы списки CRL и сертификаты центра сертификации (CA). URI-идентификаторы частично происходят от DNS-имени центра сертификации (CA). Поэтому центры сертификации (CA) Windows 2000 не поддерживают использование международного набора символов в DNS-имени сервера.
Стандарты шифрования с открытым ключом (PKCS)
Стандарты шифрования с открытым ключом (PKCS) представляют собой семейство стандартов для шифрования с открытым ключом, которые были разработаны RSA лабораториями при сотрудничестве с компаниями Apple, Digital, Lotus, Microsoft, MIT, Northern Telecom, Novell и Sun. Стандарты PKCS описывают синтаксис для многочисленных структур данных, используемых при шифровании с открытым ключом.
В частности, стандарты PKCS описывают синтаксис для:
| Цифровой подписи сообщения. В стандартах определяется, как подписать сообщение цифровой подписью, чтобы другие могли проверить, кем это сообщение было подписано и не изменялось ли оно с момента подписания. | |
| Шифрования сообщения. В стандартах определяется, каким образом можно зашифровать сообщение без какого-либо предварительного обмена данными с получателем сообщения, чтобы никто кроме самого получателя не мог бы расшифровать сообщение. | |
| Гарантирования того, что у запрашивающей стороны есть закрытый ключ. В стандартах определяется, как осуществить запрос к центру сертификации (CA), чтобы он мог проверить, что сообщение было подписано ключом, содержащемся в запросе, тем самым, гарантируя, что у запрашивающей стороны есть закрытый ключ. |
Все стандарты различаются по своим номерам (с 1 по 15). Службы сертификации Windows 2000 используют следующие стандарты PKCS:
| PKCS-1. В данном стандарте описывается создание цифровых подписей на основе алгоритма открытого ключа RSA совместно с алгоритмами хеширования. В нем также описывается, каким образом происходит шифрование симметричных ключей с помощью алгоритма RSA для обмена ключами. Этот стандарт также используется совместно со стандартом PKCS-7 для определения того, как создаются подписанные сообщения. В данном стандарте также описывается предоставление открытых ключей RSA и закрытых ключей. Службы сертификации Windows 2000 придерживаются документа RFC 2459, который ссылается на стандарт PKCS-1 в части создания подписи для сертификатов X.509 с помощью RSA и того, когда в них вносить открытые ключи RSA. | |
| PKCS-7. В данном стандарте описывается, как ставится цифровая подпись и происходит шифрование любого блока данных. Также описывается возможность включения в сообщение дополнительной информации (например, времени подписания сообщения) и ее защиты той же цифровой подписью. А также описывается использование особой формы сообщения PKCS-7, известного как вырожденное сообщение (degenerate message) , для транспортировки сертификатов и списков CRL. В стандарте PKCS-7 также определено, каким образом осуществляется шифрования данных с помощью алгоритма шифрования симметричными ключами (например, с помощью алгоритма шифрования содержимого (content-encryption algorithm)) и открытых ключей RSA для шифрования симметричных ключей (например, с помощью алгоритма обмена ключами (key-exchange algorithm)). | |
| PKCS-10. Этот стандарт описывает принцип формирования сообщения для запроса сертификата. Запрос сертификата состоит из открытого ключа и дополнительного набора атрибутов. Например, ими могут быть: различимое имя или адрес электронной почты запрашивающей стороны, подписанные закрытым ключом, который соответствует указанному в запросе открытому ключу. Сообщение PKCS-10 является тем стандартом, которого придерживаются службы сертификации Windows 2000 для получения запроса сертификата. После получения запроса службы сертификации Windows 2000 обрабатывают его и либо отклоняют его, либо выдают сертификат X.509 для запросившей стороны. Информация, которую получит запросившая сторона, будет представлена либо в виде одного сертификата X.509, либо в виде сертификата и всей цепочки сертификатов вплоть до корневого сертификата. В данном случае информация будет представлена в форме вырожденного сообщения PKCS-7. |
Дополнительная информация
Для получения самой последней информации об ОС Windows 2000 Server, обратитесь к веб-узлу http://www.microsoft.com/windows2000/ (EN).
Для получения дополнительной информации ознакомьтесь с:
Учебником по основам криптографии: Шнейер, Брюс. «Прикладная криптография: протоколы, алгоритмы, источники на С» издание второе, издательство John Wiley & Sons, 1995 (Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C . 2nd Ed. John Wiley & Sons, 1995) (EN).
Официальным документом: «Решение проблем при развертывании инфраструктуры открытых ключей (PKI) Windows 2000 и входе в систему со смарт-картой» Troubleshooting Windows 2000 PKI Deployment and Smart Card Logon (EN).
Официальным документом: «Архитектура Active Directory»
Active Directory Architecture (EN).
| 1 | В ОС Windows 2000 используется список управления доступом (ACL), в котором представлен перечень ограничений безопасности, применяемых к целому объекту, к набору свойств объекта или к отдельно взятому свойству объекта. У каждого объекта Active Directory есть два связанных с ним списка ACL: разграничительный список контроля доступа (DACL- discretionary access control list) и системный список управления доступом (System Access Control List, SACL). В списке DACL перечисляются учетные записи пользователей, группы и компьютеры, которым разрешен (или запрещен) доступ к объекту. Список DACL состоит из записей ACE (Access Control Entries, ACE), каждая из которых представляет собой разрешение или запрет пользователям, группам или компьютерам, перечисленных в списке DACL. Запись ACE содержит идентификатор безопасности (SID) с правами доступа, такими, как разрешение на чтение, запись или полный доступ. Список SACL отвечает за ведение аудита в журнале безопасности при соответствующих действиях над объектом (например, доступ к файлу) для пользователей или групп. |
| 2 | LDAP представляет собой протокол службы каталогов, который работает поверх TCP/IP. Он является простейшим протоколом доступа к каталогу, используемым для добавления, модификации и удаления хранящейся в Active Directory информации. Он также используется для запроса и получения данных из Active Directory. Клиенты Active Directory должны использовать протокол LDAP для получения информации из Active Directory или для сохранения информации в Active Directory. Active Directory использует этот протокол для взаимодействия с LDAP-совместимыми клиентскими приложениями. При наличии соответствующих разрешений Вы можете использовать любое LDAP-совместимое клиентское приложение для просмотра, подачи запроса, добавления, модификации или для удаления информации в Active Directory. |
| 3 | MIME представляет собой способ передачи через Интернет нетекстовых данных с помощью электронной почты. MIME кодирует нетекстовые данные с помощью символов ASCII и затем преобразовывает их на приемной стороне к исходному виду. S/MIME является расширением MIME, которое поддерживает безопасную почту. S/MIME позволяет отправителю подписать сообщение цифровой подписью, чтобы обеспечить возможность проверки происхождения сообщения и целостность данных. S/MIME позволяет передавать сообщение в зашифрованном виде для обеспечения конфиденциальности. |
| 4 | SSL (Secure Sockets Layer, SSL) - это открытый стандарт, предложенный Netscape Communications, для установки безопасного канала связи с целью предотвращения перехвата важной информации, например такой, как номера кредитных карт. Изначально он разрабатывался для обеспечения безопасности цифрового обмена финансовыми данными через сеть Интернет, но теперь он может применяться и в других Интернет-службах. |
| 5 | Протокол TLS (Transport Layer Security, TLS) является стандартным протоколом, используемым для обеспечения защищенных веб-соединений в сети Интернет и интрасетях. Он позволяет клиентам осуществлять проверку подлинности серверов или серверам выполнять проверку подлинности клиентов (вторая возможность является опцией). В целях конфиденциальности он также обеспечивает безопасность канала путем шифрования. |
| 6 | Файловая система EFS является новой возможностью в Windows 2000, которая защищает секретные данные, хранящиеся в файлах на NTFS-разделах. Для обеспечения конфиденциальности этих файлов EFS использует шифрование с симметричным ключом совместно с технологией открытых ключей. |
| 7 | Центр распределения ключей Kerberos (Key Distribution Center, KDC) является сетевой службой, поставляющей билеты сессии и временные ключи сессии, используемые в протоколе аутентификации Kerberos. В ОС Windows 2000 KDC работает в качестве привилегированного процесса на всех контроллерах домена. KDC использует Active Directory для управления секретной учетной информацией, такой как пароли учетных записей. |
| 8 | Контекст безопасности обращается к атрибутам безопасности или правилам, действующим в данный момент. Например, правила, определяющие, какие действия пользователь может совершать над защищенным объектом, указаны информацией безопасности в маркере доступа пользователя и в дескрипторе безопасности объекта. Вместе маркер доступа и дескриптор безопасности формируют контекст безопасности для действий пользователя над объектом. |
| 9 | Для получения общих сведений о репликации Active Directory обратитесь к официальному документу ("Active Directory Architecture") (EN), ссылка на который приведена выше в данном разделе. Для получения подробной информации обратитесь к документу "Репликация Active Directory" ("Active Directory Replication") (EN) в сети Интернет. |
| 10 | URI представляет собой строку символов, используемых для указания ресурса (например, файла) по его типу и местонахождению из любой точки сети Интернет. URI включают в себя единое название ресурса (Uniform Resource Names, URN) и единый указатель местоположения ресурса (Uniform Resource Locators, URL). |
| 11 | SGC обычно доступны для сертифицированных банковских и финансовых учреждений во всем мире. Исключением являются банки и финансовые институты, расположенные в странах, в отношении которых действует эмбарго США (список эмбарго включает в себя Кубу, Иран, Ирак, Ливию, Северную Корею, Сирию и Судан), а также несколько других направлений (в списке которых присутствует Россия и Китайская народная республика). |
| 12 | Безопасный канал (schannel - Secure Channel) пакета безопасности поддерживает протоколы на основе открытых ключей SSL (Secure Sockets Layer, SSL) версии 2 и 3, а также TLS (Transport Layer Security, TLS). Протокол TLS является стандартом IETF для SSL и для протокола PCT (PCT- Private Communication Technology). Schannel определяет, какой из этих протоколов необхоимо использовать при осуществлении связи с другим компьютером. Протоколы SSL, TLS и PCT используют сертификаты для подтверждения подлинности. IIS 5.0 поставляется международным клиентам с файлом SCHANNEL.DLL, поддерживающим стандартные 40-битные схемы шифрования. Кроме этого, если сервер IIS получает от центра сертификации (CA) сертификат SGC, то SCHANNEL.DLL поддерживает создание 128-битного канала, с помощью ключей сертификата SGC. |
| 13 | Каждый объект Active Directory имеет различаемое имя LDAP (иногда используется аббревиатура DN - distinguished name). Для получения информации о том, как Active Directory обрабатывает DN-имена LDAP, обратитесь к официальному документу "Архитектура Active Directory" ("Active Directory Architecture") (EN), ссылка на который дана выше в данном разделе. |
Установка сертификата и закрытого ключа
Мы опишем установку сертификата электронной подписи и закрытого ключа для ОС семейства 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. Установка сертификата из закрытого ключа
Теперь нам нужно получить сертификат, сделать это можно следующим образом:
- Открываем КриптоПро CSP
- Заходим на вкладку Сервис
- Нажимаем кнопку Просмотреть сертификаты в контейнере , нажимаем Обзор и здесь (если на предыдущих шагах сделали все правильно) у нас появится наш контейнер. Нажимаем кнопку Далее , появятся сведения о сертификате и тут нажимаем кнопку Установить (программа может задать вопрос проставить ли ссылку на закрытый ключ, ответьте "Да")
- После этого сертификат будет установлен в хранилище и станет возможным подписание документов (при этом, в момент подписания документа, нужно будет чтобы флешка или токен были вставлены в компьютер)
5. Использование электронной подписи без токена или флешки (установка в реестр)
Если скорость и удобство работы для вас стоит чуть выше чем безопасность, то можно установить ваш закрытый ключ в реестр Windows. Для этого нужно сделать несколько простых действий:
- Выполните подготовку закрытого ключа, описанную в пунктах (2) или (3)
- Далее открываем КриптоПро CSP
- Заходим на вкладку Сервис
- Нажимаем кнопку Скопировать
- С помощью кнопки Обзор выбираем наш ключ
- Нажимаем кнопку Далее , потом придумаем какое-нибудь имя, например "Пупкин, ООО Ромашка" и нажимаем кнопку Готово
- Появится окно, в котором будет предложено выбрать носитель, выбираем Реестр, жмем Ок
- Система попросит Установить пароль для контейнера, придумываем пароль, жмем Ок
Важное замечание: портал OpenSRO не "увидит" сертификат, если вышел срок его действия.