Электронная цифровая подпись это набор специальных символов, предназначенных для:
- Обеспечения контроля целостности информации и данных, передаваемых в электронных документах
- Обеспечение защиты информации от перехвата и несанкционированного использования
- Возможность идентификации автора и отправителя документа
Для того, что начать пользоваться сертификатом ключа электронной подписи по его прямому назначению – как юридически значимого реквизита электронного документа необходимо установить сертификат ЭЦП на компьютер или компьютеры, где будет осуществлять работа с электронными документами и непосредственно с электронной подписью.
Открытые и закрытые ключи
Необходимо пояснить, что любая ЭЦП состоит из двух видов ключей - закрытого, его еще называют ключевым контейнером, именно за счет него происходит подписание документа и его шифрование и отрытого ключа или говоря проще личного сертификата.
Личный сертификат, представлен в виде файлов с расширением.cer здесь можно просмотреть все данные о владельце электронной подписи. Такой открытый ключ необходим для того, что бы провести проверку подлинности документов. Установить сертификат ЭЦП для открытого ключа можно и нужно на все компьютеры, на которые будет поступать электронная корреспонденция.
В состав закрытого ключа входит шесть файлов, каждый из них имеет расширение.key. В том случае если эта папка утеряна или повреждена, закрытый ключ работать не будет, и придется обращаться в УЦ за перевыпуском сертификата электронной подписи.
Хранение ЭЦП
Ключи ЭЦП, как правило, хранится на специальных ключевых носителях, раньше с этой целью использовались обычные магнитные дискеты, но время показало их ненадежность и недолговечность, поэтому сегодня все чаще используются такие сертифицированные носители как RuToken. Рутокен защищается специальным паролем, благодаря чему доступ к информации на нем обеспечивается только непосредственно владельцу сертификата, которому известен этот код.
Установка сертификата ЭЦП
Для того, что бы установить сертификат ЭЦП на свой компьютер пользователю необходимо зайти в закладку Панель Управления в программе КриптоПро, там выбрать вкладку под названием Сервис, после чего щелкнуть по Просмотр сертификатов в контейнере. В появившемся окне выбираем кнопку Обзор и выбираем сертификат, который необходимо добавить. Нажимаем кнопку Далее, в окне Свойства появляется всплывающая вкладка Сертификата, нажимаем Установить сертификат.
Затем перед пользователем появляется Мастер импорта сертификата, в нем выбираем значение Поместить и отбираем сертификаты и хранилище для них, если все удалось сделать правильно перед пользователем должно появиться окно в котором сообщается, что сертификат был успешно установлен.
Все
тарифы на электронные подписи Вы можете посмотреть
в разделе .
Для установки личного сертификата с проставленной ссылкой на закрытый ключ используется приложение КриптоПро CSP. Запустить его в ОС Windows можно выполнив Пуск >> Все программы >> КРИПТО-ПРО >> КриптоПро CSP. В появившемся окне приложения нужно выбрать вкладку Сервис и в ней нажать на кнопку Установить личный сертификат . Далее следует указать расположение файла сертификата (файл с расширением.cer) и нажать кнопку Далее . Окно просмотра свойств сертификата позволяет убедиться, что выбран правильный сертификат; после проверки снова нажмите на кнопку Далее .
В следующем окне необходимо задать ключевой контейнер, содержащий в себе закрытые ключи пользователя.
ВАЖНО! В этом шаге используются только съемные USB-носители или смарт-карты, а также реестр операционной системы.
Приложение КриптоПРО CSP версии 3.9 позволяет найти контейнер автоматически путем проставления соответствующего флажка; более ранние версии после нажатия кнопки Обзор предоставляют список имеющихся носителей, из которых требуется выбрать нужный. После выбора контейнера нажмите Далее . Следующее окно позволяет задать параметры установки сертификата в хранилище. Выбрав необходимое хранилище, нажмите на кнопку Далее .
Следующий шаг финальный и не требует каких-либо действий, кроме нажатия кнопки Готово .
Данные для установки SSL-сертификата отправляются после его выпуска и активации . Они высылаются на контактный e-mail сертификата. Некоторые данные (CSR-запрос и приватный ключ) генерируются только во время покупки SSL-сертификата и не высылаются в письме..
Как узнать, на какой контактный e-mail отправлено сообщение?
Если SSL-сертификат заказывался через партнёра сайт, контактный e-mail указан на сайте партнёра.
Готово! Вы узнали e-mail, на который были высланы данные SSL-сертификата.
Данные для установки в письме
Начало письма с данными для установки
В письме вы найдёте:
- SSL-сертификат (указан после слов «Ваш сертификат предоставлен ниже»);
- Корневой сертификат ;
- Промежуточный сертификат (используется в цепочке с корневым сертификатом. Это значит, что при установке сначала вставляется корневой сертификат, а затем промежуточный с новой строки);
- Запрос на получение сертификата — на базе него центр сертификации сгенерировал и выпустил SSL-сертификат;
- Приватный ключ (для бесплатного сертификата) — после слов «Сохраните приватный ключ на локальном компьютере». Приватный ключ для платного сертификата нужно сохранить на этапе заказа.
Внимание!
Приватный ключ (Private Key) сертификата не хранится на серверах сайт. Скопируйте приватный ключ из письма, вставьте в пустой текстовый файл и сохраните его в формате .txt или .key .
Если вы потеряли или скомпрометировали приватный ключ, текущий SSL-сертификат использовать не удастся. Чтобы решить проблему, переиздайте SSL-сертификат по инструкции: .
Данные в Личном кабинете
Некоторые данные (Сертификат, Корневой + Промежуточный сертификат и CSR-запрос ) дублируются в Личном кабинете. Они представлены в виде файлов, которые вы можете скачать, а затем загрузить при установке SSL-сертификата на сервер.
В данном приложении описаны стандарты, которых придерживаются службы сертификации 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), ссылка на который дана выше в данном разделе. |
Я рассказывал о не очевидных причинах возникновения ошибки "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 .
Напоследок приведу пример команды, позволяющей сгенерировать тестовый сертификат, который можно применять в операциях шифрования.
