Войти
Образовательный портал. Образование
  • Как приготовить классические вареники с творогом
  • Как сделать тесто для яблочной шарлотки Как приготовить шарлотку с яблоками песочное тесто
  • Отечественной войны 2 степени
  • День полного освобождения Ленинграда от фашистской блокады
  • Манная каша на молоке: пропорции и рецепты приготовления Манная каша 1 порция
  • Суп-пюре из брокколи с сыром Рецепт крем супа из брокколи с сыром
  • X 509 версия 3. Электронный сертификат X.509 обзор. Системы, использующие сертификаты, и PKI

    X 509 версия 3. Электронный сертификат X.509 обзор. Системы, использующие сертификаты, и PKI

    Необходимость защиты информации

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

    В настоящее время, например, средства электронной почты, используются не только для общения между людьми, а для передачи контрактов и конфиденциальной финансовой информации. Web сервера используются не только для рекламных целей, но и для распространения программного обеспечения и электронной коммерции. Электронная почта, доступ к Web серверу, электронная коммерция, VPN требуют применения дополнительных средств для обеспечения конфиденциальности, аутентификации, контроля доступа, целостности и идентификации. В настоящее время в качестве таких средств повсеместно используются средства криптографической защиты и Инфраструктура Открытых Ключей (ИОК).

    Для чего нужна криптография

    Система криптографической защиты должна обеспечивать:

    • Конфиденциальность - Информация должна быть защищена от несанкционированного прочтения как при хранении, так и при передаче. Если сравнивать с бумажной технологией, то это аналогично запечатыванию информации в конверт. Содержание становится известно только после того, как будет открыт запечатанный конверт. В системах криптографической защиты обеспечивается шифрованием.
    • Контроль доступа - Информация должна быть доступна только для того, для кого она предназначена. Если сравнивать с бумажной технологией, то только разрешенный получатель может открыть запечатанный конверт. В системах криптографической защиты обеспечивается шифрованием.
    • Аутентификацию - Возможность однозначно идентифицировать отправителя. Если сравнивать с бумажной технологией, то это аналогично подписи отправителя. В системах криптографической защиты обеспечивается электронной цифровой подписью и сертификатом.
    • Целостность - Информация должна быть защищена от несанкционированной модификации как при хранении, так и при передаче. В системах криптографической защиты обеспечивается электронной цифровой подписью и имитозащитой.
    • Неотрекаемость - Отправитель не может отказаться от совершенного действия. Если сравнивать с бумажной технологией, то это аналогично предъявлению отправителем паспорта перед выполнением действия. В системах криптографической защиты обеспечивается электронной цифровой подписью и сертификатом.

    Что такое криптография с открытыми ключами

    Криптографическое преобразование (шифрование)- взаимно-однозначное математическое преобразование, зависящее от ключа (секретный параметр преобразования), которое ставит в соответствие блоку открытой информации (представленной в некоторой цифровой кодировке) блок шифрованной информации, также представленной в цифровой кодировке. Термин шифрование объединяет в себе два процесса: зашифрование и расшифрование информации.

    Криптография делится на два класса: с симметричными ключами и открытыми ключами.

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

    Преимущества криптографии с симметричными ключами:

    • Производительность - Производительность алгоритмов с симметричными ключами очень велика.
    • Стойкость - Криптография с симметричными ключами очень стойкая, что делает практически невозможным процесс дешифрования. При прочих равных условиях (общий алгоритм) стойкость определяется длиной ключа. При длине ключа 256 бит необходимо произвести 10 в 77 степени переборов для определения ключа.

    Недостатки криптографии с симметричными ключами:

    • Распределение ключей - Так как для шифрования и расшифрования используется один и тот же ключ, при использовании криптографии с симметричными ключами требуются очень надежные механизмы для распределения ключей.
    • Масштабируемость - Так как используется единый ключ между отправителем и каждым из получателей, количество необходимых ключей возрастает в геометрической прогрессии. Для 10 пользователей нужно 45 ключей, а для 100 уже 499500.
    • Ограниченное использование - Так как криптография с симметричными ключами используется только для шифрования данных и ограничивает доступ к ним, при ее использовании невозможно обеспечить аутентификацию и неотрекаемость.

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

    Криптография с открытыми ключами обеспечивает все требования, предъявляемые к криптографическим системам. Но реализация алгоритмов требует больших затрат процессорного времени. Поэтому в чистом виде криптография с открытыми ключами в мировой практике обычно не применяется. Для шифрования данных используются симметричные (сеансовые) ключи, которые в свою очередь шифруются с использованием открытых для передачи сеансовых ключей по сети.

    Криптография с открытыми ключами требует наличия Инфраструктуры Открытых Ключей (PKI - Public Key Infrastructure) - неотъемлемого сервиса для управления электронными сертификатами и ключами пользователей, прикладного обеспечения и систем.

    Верификация открытого ключа

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

    Электронный сертификат представляет собой цифровой документ, который связывает открытый ключ с определенным пользователем или приложением. Для заверения электронного сертификата используется электронная цифровая подпись доверенного центра - Центра Сертификации (ЦС). Исходя из функций, которые выполняет ЦС, он является основной компонентой всей Инфраструктуры Открытых Ключей. Используя открытый ключ ЦС, каждый пользователь может проверить достоверность электронного сертификата, выпущенного ЦС, и воспользоваться его содержимым.

    Верификация цепочки сертификатов

    Как описывалось ранее, доверие любому сертификату пользователя определяется на основе цепочки сертификатов. Причем начальным элементом цепочки является сертификат центра сертификации, хранящийся в защищенном персональном справочнике пользователя.

    Процедура верификации цепочки сертификатов описана в рекомендациях X.509 и RFC 2459 и проверяет связанность между именем Владельца сертификата и его открытым ключом. Процедура верификации цепочки подразумевает, что все "правильные" цепочки начинаются с сертификатов, изданных одним доверенным центром сертификации. Под доверенным центром понимается главный ЦС, открытый ключ которого содержится в самоподписанном сертификате. Такое ограничение упрощает процедуру верификации, хотя наличие самоподписанного сертификата и его криптографическая проверка не обеспечивают безопасности. Для обеспечения доверия к открытому ключу такого сертификата должны быть применены специальные способы его распространения и хранения, так как на данном открытом ключе проверяются все остальные сертификаты.

    Алгоритм верификации цепочек использует следующие данные:

    • Х.500 имя Издателя сертификата;
    • Х.500 имя Владельца сертификата;
    • открытый ключ Издателя;
    • срок действия открытого (секретного) ключа Издателя и Владельца;
    • ограничивающие дополнения, используемые при верификации цепочек (basicConstraints, nameConstraints, policyConstrains);
    • СОС для каждого Издателя (даже если он не содержит отзываемых сертификатов).

    Цепочка сертификатов представляет собой последовательность из n сертификатов, в которой:

    • для всех x в {1, (n-1)}, Владелец сертификата x есть Издатель сертификата x+1;
    • сертификат x=1 есть самоподписанный сертификат;
    • сертификат x=n есть сертификат конечного пользователя;

    Одновременно с цепочкой сертификатов используется цепочка СОС, представляющая собой последовательность из n СОС, в которой:

    • для всех СОС x в {1, n}, Издатель сертификата x есть Издатель СОС x;
    • СОС x=1 есть СОС, изданный Владельцем самоподписанного сертификата;
    • СОС x=n есть СОС, изданный Издателем сертификата конечного пользователя;

    После построения двух цепочек (сертификатов и СОС) выполняется:

    • криптографическая проверка сертификатов и СОС в цепочках;
    • проверка сроков действия сертификатов и СОС;
    • проверка соответствия имен Издателя и Владельца с использованием дополнения nameConstraints ;
    • проверка длины цепочки с использованием дополнения basicConstraints ;
    • проверка на отзыв сертификатов, причем, если сертификат промежуточного центра был отозван СОС вышестоящего центра, все сертификаты, изданные промежуточным центром, считаются недействительными;
    • проверка приемлемых регламентов использования сертификата и приемлемых областей использования ключа с использованием дополнений certificatesPolicies и extendedKeyUsage .

    Компоненты ИОК и их функции

    В состав компонент ИОК входят следующие компоненты:

    • Центр Сертификации;
    • Центр Регистрации;
    • Конечные пользователи;
    • Сетевой справочник.

    Центр Сертификации

    Центр Сертификации (или Удостоверяющий Центр) - основная управляющая компонента ИОК, предназначенная для формирования электронных сертификатов подчиненных Центров и конечных пользователей. Кроме сертификатов, ЦС формирует список отозванных сертификатов X.509 CRL (СОС) с регулярностью, определенной Регламентом системы.

    К основным функция ЦС относятся:

    • Формирование собственного секретного ключа и сертификата ЦС;
    • Формирование сертификатов подчиненных Центров;
    • Формирование сертификатов открытых ключей конечных пользователей;
    • Формирование списка отозванных сертификатов;
    • Ведение базы всех изготовленных сертификатов и списков отозванных сертификатов;

    Центр Регистрации

    Опциональная компонента ИОК, предназначенная для регистрации конечных пользователей. Основная задача ЦР - регистрация пользователей и обеспечение их взаимодействия с ЦС. В задачи ЦР может также входить публикация сертификатов и СОС в сетевом справочнике LDAP.

    Пользователи

    Пользователь, приложение или система, являющиеся Владельцами сертификата и использующие ИОК.

    Сетевой справочник

    Опциональная компонента ИОК, содержащая сертификаты и списки отозванных сертификатов и служащая для целей распространения этих объектов среди пользователей с использованием протокола LDAP (HTTP, FTP).

    Использование ИОК в приложениях

    ИОК используется для управления ключами и электронными сертификатами в приложениях (таких как электронная почта, Web приложения, электронная коммерция), использующих криптографию для установления защищенных сетевых соединений (S/MIME, SSL, IPSEC), или для формирования ЭЦП электронных документов, приложений и т.д. Кроме того, ИОК может быть использована для корпоративных приложений.

    Электронная почта и документооборот

    Защищенные электронная почта и документооборот используют криптографию для шифрования сообщений или файлов и формирования ЭЦП. Из наиболее известных и распространенных стандартов стоит отметить протокол S/MIME (Secure Multipurpose Internet Mail Extensions), который является расширением стандарта Internet почты MIME (Multipurpose Internet Mail Extensions).

    Web приложения

    Web броузеры и сервера используют ИОК для аутентификации и конфиденциальности сессии, а также для онлайновых банковских приложений и электронных магазинов. Наиболее распространенным протоколом в этой сфере является протокол SSL (Secure Sockets Layer). Протокол SSL не ограничивается применением только для защиты HTTP (Hypertext Transfer Protocol), а также может быть использован для FTP (File Transfer Protocol) и Telnet.

    ЭЦП файлов и приложений

    Использование ЭЦП для подписи приложений и файлов позволяет безопасно распространять их по сети Internet. При этом пользователь уверен в корректности полученного приложения от фирмы-разработчика.

    Стандарты в области ИОК

    Стандарты в области ИОК делятся на две группы: часть из них описывает собственно реализацию ИОК, а вторая часть, которая относится к пользовательскому уровню, использует ИОК, не определяя ее. На приведенном рисунке показана связь приложений со стандартами. Стандартизация в области ИОК позволяет различным приложениям взаимодействовать между собой с использованием единой ИОК.

    В особенности стандартизация важна в области:

    • процедуры регистрации и выработки ключа;
    • описания формата сертификата;
    • описания формата СОС;
    • описания формата криптографически защищенных данных;
    • описания онлайновых протоколов.

    Основным центром по выпуску согласованных стандартов в области ИОК является рабочая группа ИОК (PKI working group) организации IETF (Internet Engineering Task Force), известная как группа PKIX (от сокращения PKI for X.509 certificates).

    Стандарты PKIX

    Спецификации PKIX основаны на двух группах стандартов: X.509 ITU-T (Международный комитет по телекоммуникациям) и PKCS (Public Key Cryptography Standards) firmy RSA Data Security. X.509 изначально был предназначен для спецификации аутентификации при использовании в составе сервиса X.500 директории. Фактически же, синтаксис электронного сертификата, предложенный в X.509 признан стандартом де-факто и получил всеобщее распространение независимо от X.500. Однако X.509 ITU-T не был предназначен для полного определения ИОК. В целях применения стандартов X.509 в повседневной практике пользователи, поставщики и комитеты по стандартизации обращаются к стандартам PKCS. PKIX группа издала следующие стандарты Internet (RFC).

    Формат сертификата Х.509

    Х.509 - это другой очень распространённый формат. Все сертификаты Х.509 соответствуют международному стандарту ITU-T X.509; таким образом (теоретически), сертификат Х.509, созданный для одного приложения, может быть использован в любом другом, поддерживающем этот стандарт. На практике, однако, сложилась ситуация, что разные компании создают собственные расширения для Х.509, не все из которых между собой совместимы.

    Всякий сертификат требует, чтобы кто-то заверил взаимосвязность открытого ключа и идентифицирующей владельца ключа информации. Имея дело с PGP-сертификатом, каждый может выступать в качестве заверителя содержащихся в нём сведений (за исключением случаев, когда эта возможность намеренно ограничена политикой безопасности). Но в случае сертификатов Х.509 заверителем может быть только Центр сертификации или некто, специально уполномоченный им на эту роль. (Имейте в виду, что PGP-сертификаты также в полной мере поддерживают иерархическое структурирование системы доверия, использующее ЦС для удостоверения сертификатов.)

    Сертификат Х.509 - это набор стандартных полей, содержащих сведения о пользователе или устройстве, и их соответствующий открытый ключ. Стардарт Х.509 определяет, какие сведения входят в сертификат и как они кодируются (формат данных).

    Сертификат Х.509 содержит следующие сведения:

    Версия Х.509 - указывает, на основе какой версии стандарта Х.509 построен данный сертификат, что определяет, какая информация может в нём содержаться.

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

    Серийный номер сертификата - организация-издатель сертификата обязана присвоить ему уникальный серийный (порядковый) номер для его опознавания среди прочих сертификатов, выданных данной организацией. Эта информация применяется в ряде случаев; например, при аннулировании сертификата, его серийный номер помещается в список аннулированных сертификатов (Certificate Revocation List, CRL).

    Уникальный опознаватель владельца ключа (или DN, distinguished name - уникальное имя) - это имя должно быть уникальным и единственным во всём Интернете. DN состоит из нескольких подпунктов и может выглядеть примерно так:

    CN=Bob Davis, [email protected], OU=PGP Engineering,

    O=PGP Corporation, C=US

    (Что обозначает Понятное имя субъекта, Электронную почту, Подразделение организации, Организацию и Страну соответственно.)

    Период действия сертификата - дата начала действия сертификата и дата окончания его действия; указывает на то, когда сертификат станет недействителен.

    Уникальное имя издателя - уникальное имя организации, подписавшей сертификат. Обычно, это наименование Центра сертификации. Использование сертификата подразумевает доверие организации, его подписавшей. (В случаях с корневыми сертификатами выдавшая организация - этот же ЦС - подписывает его сама.)

    ЭЦП издателя - электронная подпись, созданная закрытым ключом организации, выдавшей сертификат. Идентификатор алгоритма подписи - указывает алгоритм, использованный ЦС для подписания сертификата.

    Существует ряд фундаментальных различий между форматами сертификатов Х.509 и PGP:

    вы можете лично создать собственный сертификат PGP;

    вы должны запросить и получить сертификат Х.509 от Центра сертификации; сертификаты Х.509 содержат только одно имя владельца сертификата;

    сертификаты Х.509 содержат только одну ЭЦП, подтверждающую подлинность сертификата.

    Чтобы получить сертификат Х.509, вы должны попросить ЦС выдать его вам. Вы предоставляете системе свой открытый ключ, чем доказываете, что обладаете соответствующим закрытым, а также некоторые идентифицирующие вас сведения. Затем вы электронно подписываете эти сведения и отправляете весь пакет - запрос сертификата - в Центр сертификации. ЦС выполняет определённый процесс по проверке подлинности предоставленной информации и, если всё сходится, создаёт сертификат, подписывает и возвращает вам.

    Вы можете представить сертификат Х.509, как обычный бумажный сертификат или аттестат с приклеенным к нему открытым ключом. На нём указано ваше имя, а также некоторые сведения о вас, плюс подпись издателя сертификата.

    Вероятно, наибольшая польза от сертификатов Х.509, это их применение в Веб-браузерах.

    Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

    Из книги Windows Script Host для Windows 2000/XP автора Попов Андрей Владимирович

    Способы получения цифрового сертификата Различаются цифровые сертификаты трех типов: созданные разработчиком, выданные разработчику организацией и полученные от центра сертификации.Цифровой сертификат, созданный разработчиком, обычно используют те пользователи,

    Из книги Инфраструктуры открытых ключей автора Полянская Ольга Юрьевна

    Создание собственного сертификата Наиболее быстрым способом создания собственного цифрового сертификата является использование программы SelfCert.exe, входящей в состав Microsoft Office 2000/ХР. Запустив эту утилиту, мы получим диалоговое окно, позволяющее задать имя создаваемого

    Из книги Яндекс для всех автора Абрамзон М. Г.

    Дополнения сертификата Важная информация находится также в дополнениях сертификата. Они позволяют включать в сертификат информацию, которая отсутствует в основном содержании, определять валидность сертификата и наличие у владельца сертификата прав доступа к той или

    Из книги Введение в криптографию автора Циммерманн Филипп

    Онлайновый протокол статуса сертификата Онлайновый протокол статуса сертификата OCSP - относительно простой протокол (типа "запрос-ответ") для получения информации об аннулировании от доверенного субъекта, называемого OCSP-респондером. OCSP-запрос состоит из номера версии

    Из книги Операционная система UNIX автора Робачевский Андрей М.

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

    Из книги автора

    Проверка срока действия сертификата Эта проверка завершается успешно, если текущие дата и время на момент валидации находятся в пределах срока действия

    Из книги автора

    Проверка статуса сертификата Эта проверка завершается успешно, если издатель не аннулировал данный сертификат. Основным средством проверки статуса сертификата являются списки САС, но могут использоваться и другие альтернативные средства

    Из книги автора

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

    Из книги автора

    Подготовка следующего сертификата Сначала выполняется некоторая простая проверка сертификата УЦ. Затем обновляются переменные состояния, для того чтобы они могли отражать значения полей дополнений сертификата. Существует несколько дополнений, которые встречаются

    Из книги автора

    Завершение обработки сертификата Когда завершается обработка сертификата конечного субъекта, на основании значений переменных состояния устанавливаются выходные значения.Корректировка переменных состояния верификации цифровой подписи. В поле информации об

    Из книги автора

    3.3.1. Формат RSS Читать новости сайтов можно по-разному. Самый простой способ - заходить время от времени на сайт и просматривать новые сообщения. Можно поставить программу, которая подключается к новостному каналу и сама получает заголовки или аннотации новостей, по

    Из книги автора

    Формат сертификата Х.509 Х.509 - это другой очень распространённый формат. Все сертификаты Х.509 соответствуют международному стандарту ITU-T X.509; таким образом (теоретически), сертификат Х.509, созданный для одного приложения, может быть использован в любом другом,

    Из книги автора

    Аннулирование сертификата Применение сертификата допустимо только пока он достоверен. Опасно полагаться на то, что сертификат будет защищён и надёжен вечно. В большинстве организаций и во всех PKI сертификат имеет ограниченный срок "жизни". Это сужает период, в который

    Из книги автора

    Уведомление об аннулировании сертификата После аннулирования сертификата крайне важно оповестить всех потенциальных корреспондентов, что он более недействителен. Наиболее простой способ оповещения в среде PGP - это размещение аннулированного сертификата на

    Из книги автора

    Формат ELF Формат ELF имеет файлы нескольких типов, которые до сих пор мы называли по-разному, например, исполняемый файл или объектный файл. Тем не менее стандарт ELF различает следующие типы:1. Перемещаемый файл (relocatable file), хранящий инструкции и данные, которые могут быть

    инфраструктура управления привилегиями PMI " (Privilege Management Infrastructure). Главное отличие между ними заключается в том, что PKI управляет , а PMI - атрибутными сертификатами . Сертификат открытого ключа можно сравнить с паспортом субъекта, а атрибутный сертификат - с визой, первый обеспечивает идентификацию личности, а второй дает определенное разрешение. Основные термины и аббревиатуры, используемые в стандартах PKIX, а также их аналоги на русском языке приведены в табл. 15.5 .
    Системы, использующие сертификаты, и PKI

    Результатом усилий технических специалистов по повышению безопасности Интернета стала разработка группы протоколов безопасности, таких как S/MIME, TLS и IPsec. Все эти протоколы используют криптографию с открытыми ключами для обеспечения сервисов конфиденциальности, целостности данных, аутентификации источника данных и неотказуемости.

    Цель PKI состоит в обеспечении надежного и эффективного управления ключами и сертификатами открытых ключей . Пользователи систем, основанных на PKI, должны быть уверены, что в любой момент времени при коммуникации с определенным субъектом они полагаются на открытый ключ, связанный с секретным ключом, владельцем которого является именно этот субъект. Эта уверенность возникает в результате использования сертификатов открытых ключей , связывающих значения открытых ключей с их владельцами. Связывание происходит в результате проверки доверенным УЦ идентичности субъекта и заверения цифровой подписью каждого сертификата открытого ключа.

    Таблица 15.5. Термины PKIX
    Термин на английском языке Аббревиатура Термин на русском языке
    Attribute Authority AA Атрибутный центр
    Attribute Certificate AC Атрибутный сертификат
    Certificate Сертификат
    Certification Authority CA Удостоверяющий центр (УЦ)
    Certificate Policy CP Политика применения сертификатов (ППС)
    Certification Practice Statement CPS Регламент УЦ
    End-Entity EE Конечный субъект
    Public Key Certificate PKC Сертификат открытого ключа
    Public Key Infrastructure PKI Инфраструктура открытых ключей
    Privilege Management Infrastructure PMI Инфраструктура управления привилегиями
    Registration Authority RA Регистрационный центр (РЦ)
    Relying Party Доверяющая сторона
    Root CA Корневой УЦ
    Subordinate CA Подчиненный УЦ
    Subject Субъект
    Top CA УЦ верхнего уровня

    Согласно стандартам PKIX, PKI представляет собой комплекс программного и аппаратного обеспечения, персонала, а также политик и процедур, необходимых для создания, управления, хранения, распространения и аннулирования сертификатов открытых ключей . Компоненты PKI представлены в табл. 15.6 . Сертификат открытого ключа имеет ограниченный период действия , который зафиксирован в содержании сертификата. Поскольку клиент должен иметь возможность самостоятельно проверить подпись сертификата открытого ключа и его срок действия, сертификаты должны открыто публиковаться и распространяться посредством даже ненадежных коммуникаций и систем серверов.

    Таблица 15.6. Компоненты PKI
    Компонент Описание
    Удостоверяющие центры (УЦ) Выпускают и аннулируют сертификаты
    Регистрационные центры (РЦ) Подтверждают связывание открытых ключей и личностей владельцев сертификатов и других атрибутов
    Владельцы сертификатов Подписывают и шифруют электронные документы
    Клиенты Проверяют подлинность цифровых подписей и соответствующих цепочек сертификатов при помощи открытого ключа доверенного УЦ
    Репозитории Хранят и предоставляют информацию о сертификатах и списках САС

    Создание сертификатов

    Первое, что сделаем, это создадим серверный и клиентские сертификаты. Нужна програмка openssl.exe (у меня установлен xampp , в нём есть всё, что нужно – вам его тоже советую). Итак, в папке /сервер/apache/bin находим openssl.exe и создаём файлы ca.config и openssl.cnf. Также, создадим папку db, а в ней папки certs, newcerts, пустые текстовые файлы index.txt и serial (внутри этого файла написать “01” без ковычек.)

    Содержимое файла ca.config

    [ ca ]
    default_ca = CA_CLIENT # При подписи сертификатов
    # использовать секцию CA_CLIENT

    [ CA_CLIENT ]
    dir = ./db # Каталог для служебных файлов
    certs = $dir/certs # Каталог для сертификатов
    new_certs_dir = $dir/newcerts # Каталог для новых сертификатов
    database = $dir/index.txt # Файл с базой данных
    # подписанных сертификатов
    serial = $dir/serial # Файл содержащий серийный номер
    # сертификата
    # (в шестнадцатиричном формате)
    certificate = ./ca.crt # Файл сертификата CA
    private_key = ./ca.key # Файл закрытого ключа CA

    default_days = 365 # Срок действия подписываемого
    # сертификата
    default_crl_days = 7 # Срок действия CRL (см. $4)
    default_md = md5 # Алгоритм подписи

    policy = policy_anything # Название секции с описанием
    # политики в отношении данных
    # сертификата

    [ policy_anything ]
    countryName = optional # Код страны – не обязателен
    stateOrProvinceName = optional # ……
    localityName = optional # ……
    organizationName = optional # ……
    organizationalUnitName = optional # ……
    commonName = supplied # …… – обязателен
    emailAddress = optional # ……

    Содержимое файла openssl.cnf

    # =================================================
    # OpenSSL configuration file
    # =================================================
    RANDFILE = .rnd
    [ ca ]
    default_ca = CA_default
    [ CA_default ]
    dir = .
    certs = $dir
    new_certs_dir = $dir
    crl_dir = $dir
    database = $dir/db/index.txt
    private_key = $dir/ca.key
    certificate = $dir/ca.crt
    serial = $dir/db/serial
    crl = $dir/crl.pem
    RANDFILE = $dir/db/private/.rand
    default_days = 365
    default_crl_days = 30
    default_md = sha1
    preserve = no
    policy = policy_anything
    name_opt = ca_default
    cert_opt = ca_default
    [ policy_anything ]
    countryName = optional
    stateOrProvinceName = optional
    localityName = optional
    organizationName = optional
    organizationalUnitName = optional
    commonName = supplied
    emailAddress = optional
    [ req ]
    default_bits = 1024
    default_md = sha1
    default_keyfile = privkey.pem
    distinguished_name = req_distinguished_name
    x509_extensions = v3_ca
    string_mask = nombstr
    [ req_distinguished_name ]
    countryName = Country Name (2 letter code)
    countryName_min = 2
    countryName_max = 2
    stateOrProvinceName = State or Province Name (full name)
    localityName = Locality Name (eg, city)
    0.organizationName = Organization Name (eg, company)
    organizationalUnitName = Organizational Unit Name (eg, section)
    commonName = Common Name (eg, YOUR name)
    commonName_max = 64
    emailAddress = Email Address
    emailAddress_max = 64
    [ usr_cert ]
    basicConstraints = CA:FALSE
    # nsCaRevocationUrl = https://url-to-exposed-clr-list/crl.pem
    [ ssl_server ]
    basicConstraints = CA:FALSE
    nsCertType = server

    extendedKeyUsage = serverAuth, nsSGC, msSGC
    nsComment = «OpenSSL Certificate for SSL Web Server»
    [ ssl_client ]
    basicConstraints = CA:FALSE
    nsCertType = client
    keyUsage = digitalSignature, keyEncipherment
    extendedKeyUsage = clientAuth
    nsComment = «OpenSSL Certificate for SSL Client»
    [ v3_req ]
    basicConstraints = CA:FALSE
    keyUsage = nonRepudiation, digitalSignature, keyEncipherment
    [ v3_ca ]
    basicConstraints = critical, CA:true, pathlen:0
    nsCertType = sslCA
    keyUsage = cRLSign, keyCertSign
    extendedKeyUsage = serverAuth, clientAuth
    nsComment = «OpenSSL CA Certificate»
    [ crl_ext ]
    basicConstraints = CA:FALSE
    keyUsage = digitalSignature, keyEncipherment
    nsComment = «OpenSSL generated CRL»

    открываем cmd.exe (Пуск –> Выполнить –> cmd –> enter), далее запускаем через cmd программу openssl.exe и приступаем непосредственно к созданию наших сертификатов.

    1) создаём серверный ключ и сертификат

    req -new -x509 -days 365 -sha1 -newkey rsa:1024 -nodes -keyout server.key -out server.crt -subj ‘/O=НазваниеКомпании/OU=Подразделение/CN=localhost’

    Укажите здесь название вашей компании, подразделения, а также доменное имя.

    req -config openssl.cnf -new -x509 -days 3652 -sha1 -newkey rsa:1024 -keyout ca.key -out ca.crt -subj ‘/O=Организация/OU=Подразделение’

    Укажите здесь название вашей компании, подразделения.

    3) создаём пользовательские сертификаты

    • req -new -sha1 -newkey rsa:1024 -nodes -keyout server.key -out request.pem -subj ‘/O=Skif Grid/OU=PSI RAS/CN=localhost’
    • ca -config openssl.cnf -policy policy_anything -extensions ssl_server -out signed.pem -infiles request.pem
    • x509 -in signed.pem -out server.crt
    • openssl pkcs12 -export –in signed.pem –inkey server.key -certfile ca.crt -name «Имя\Отчество» -out user.p12

    Получившееся ca.crt и user.p12 импортируем в браузер. С сертификатами покончено, теперь пришло время Apach’a.

    Настройка Apache

    Открываем файл /сервер/apache/conf/extra/httpd-ssl.conf, стираем всё, что там есть и копируем туда следующее:

    ErrorLog D:/www/apache/logs/ssl_error.log
    LogLevel warn

    AddType application/x-x509-ca-cert .crt .pem
    AddType application/x-pkcs7-crl .crl
    AddType application/x-pkcs12-cert .p12

    SSLPassPhraseDialog builtin
    SSLSessionCache dbm:logs/ssl.scache
    SSLSessionCacheTimeout 300
    SSLMutex default
    SSLOptions +StdEnvVars +ExportCertData +StrictRequire

    NameVirtualHost *:443

    AddDefaultCharset utf-8
    AddCharset utf-8 *

    DocumentRoot «D:/www/htdocs»
    ServerName http://www.youhost.ru:443
    ServerAdmin [email protected]
    ErrorLog D:/www/apache/logs/ssl_error1.log

    SSLEngine on
    SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
    SSLProtocol all -SSLv2
    SSLOptions +StdEnvVars +ExportCertData

    SSLCertificateFile conf/ssl/server.crt
    SSLCertificateKeyFile conf/ssl/server.key
    SSLCACertificateFile conf/ssl/ca/ca.crt

    SSLVerifyClient require
    SSLVerifyDepth 1

    SSLProxyEngine off


    SetEnvIf User-Agent ..*MSIE.*. nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

    Если мы хотим сделать авторизацию не обязательной (скажем, чтобы, если у пользователя не будет сертификата, то показать ему красивую страничку с надписью, скажем – получите сначала сертификат), то SSLVerifyClient поставьте как optional.

    Х.509 -- это другой очень распространённый формат. Все сертификаты Х.509 согласованы с международным стандартом ITU-T X.509; таким образом (теоретически), сертификат Х.509, созданный для одного приложения, может быть использован в любом другом, поддерживающим этот стандарт. На деле, однако, выясняется, что разные компании создали собственные расширения Х.509, многие из которых друг с другом никак не совместимы.

    Имея дело с PGP-сертификатом, каждый может выступать в качестве заверителя содержащейся в нём информации (за исключением случаев, когда эта возможность намеренно ограничена системным администратором). Однако, в случае сертификатов Х.509, заверителем может быть только Центр сертификации или некто, специально уполномоченный им. (Имейте в виду, что PGP-сертификаты также в полной мере поддерживают иерархическое структурирование системы доверия, использующее ЦС для удостоверения сертификатов.)

    Сертификат Х.509 -- это набор стандартных полей, содержащих сведения о пользователе или устройстве, и их соответствующий открытый ключ. Стардарт Х.509 определяет, какие сведения входят в сертификат и как они кодируются (формат данных).

    Сертификат Х.509 содержит следующие сведения:

  • Версия Х.509 -- указывает, на основе какой версии стандарта Х.509 построен данный сертификат, что определяет, какая информация может в нём содержаться.
  • Открытый ключ обладателя сертификата -- открытый ключ совместно с идентификатором используемого алгоритма (указывающим криптосистему, к которой принадлежит данный ключ) и прочая аналогичная информация о параметрах ключа.
  • Серийный номер сертификата -- сообщество (программа или лицо), создавшее сертификат, обязано снабдить его уникальным серийным номером для его выделения среди прочих сертификатов, выданных данным сообществом. Эта информация применяется в ряде случаев; например, при ревокации сертификата, его серийный номер помещается в реестр аннулированных сертификатов (Certificate Revocation List, CRL).
  • Уникальный опознаватель обладателя ключа (или DN, distinguished name -- уникальное имя) -- это имя должно быть уникальным и единственным во всём Интернете. DN состоит из нескольких подсекций и может выглядеть примерно так:
  • CN=Bob Davis, [email protected], OU=PGP Security Division, O=Network Associates, Inc., C=US
    (Что обозначает Понятное имя субъекта, Электронную почту, Подразделение организации, Органицию и Страну соответственно.)
  • Срок действия сертификата -- дата/время начала действия сертификата и дата/время окончания его действия; указывает на то, когда сертификат станет просрочен.
  • Уникальное имя выдавшего сертификат -- уникальное имя сообщества, подписавшего сертификат. Обычно, это наименование Центра сертификации. Использование сертификата подразумевает доверие сообществу, его подписавшему. (Учтите, что иногда, в частности, в случаях с корневыми сертификатами и сертификатами высших уровней Центров сертификации, выдающий его -- как правило, этот же ЦС -- сам его и подписывает.)
  • ЭЦП выдавшего сертификат -- электронная подпись, созданная частным ключом сообщества, выдавшего сертификат.
  • Идентификатор алгоритма подписи -- указывает алгоритм, использованный ЦС для подписания сертификата.

    Существует ряд различий между форматами сертификатов Х.509 и PGP, но наиболее выделяются следующие:

  • вы можете лично создать собственный PGP-сертификат; вы должны запросить и получить сертификат Х.509 от Центра сертификации;
  • сертификаты Х.509 поддерживают только одно имя обладателя сертификата;
  • сертификаты Х.509 поддерживают только одну ЭЦП, подтверждающую достоверность сертификата.

    Чтобы получить сертификат Х.509, вы должны попросить ЦС выдать его вам. Вы предоставляется свой открытый ключ, тем самым доказывая, что обладаете соответствующим частным, а также некоторые идентифицирующие вас сведения. Затем вы электронно подписываете эти сведения и отправляете весь пакет -- запрос сертификата -- в Центр сертификации. ЦС выполняет определённый процесс по проверке подлинности предоставленной вами информации и, если всё сходится, создаёт сертификат и возвращает его вам.

    Вы можете представить сертификат Х.509, как обычный бумажный сертификат или аттестат с прилепленным к нему общественным ключом. На нём написано ваше имя, а также некоторые сведения о вас, плюс подпись лица, выдавшего сертификат.

    Рис. Сертификат Х.509

    Вероятно, наибольшая польза от сертификатов Х.509, это их применение в Веб-браузерах.