что такое инфраструктура открытых ключей pki

Про PKI «на пальцах» за 10 минут

Предложил коллегам провести внутреннюю мини-лекцию по сабжу — идея зашла. Сел писать план лекции и… чот психанул — в итоге очнулся, дописывая небольшой гайд. Подумал, что будет полезно добавить сюда что-то для быстрого понимания, что такое PKI, зачем она нужна и как работает, так как пока готовился, чтобы освежить память, искал информацию в том числе на полюбившемся «Хабрахабре», но статей в таком формате не нашел.

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

Без теории не обойтись

PKI (Public Key Infrastructure, инфраструктура открытых ключей) — это про безопасность. Подразумевается, что у каждой сущности в инфраструктуре есть свой ключ, которым она однозначно идентифицируется. То есть, если ключ украден, пострадавшей сущностью может представиться укравший. PKI нужна для того, чтобы оперативно минимизировать последствия такой кражи. Ключ представлен двумя частями: публичной и приватной.

Аналог — это RSA ключи для SSH, но инфраструктурой их назвать сложно, так как отсутствует централизованный механизм управления ими. Также разница в том, что публичная часть ключа в паре ключей для SSH неизменна, а сертификат (публичную часть ключа участника PKI) можно перевыпустить в любой момент.

В PKI существует один (на самом деле, должно быть минимум два) или несколько Certification Authority — центров сертификации (удостоверяющих центров), отдающих публичные части своих ключей клиентам, которым выдают подписанные ими сертификаты. Таким образом, участники инфраструктуры «понимают», кто ими управляет, и действителен ли сертификат, выданный им или их «товарищам», в настоящий момент времени (одним из важнейших атрибутов сертификатов является срок их действия). Либо же сервер, у которого есть публичная часть ключа CA инфраструктуры, в которой он и его клиенты работают, понимает, что к нему пришел клиент с действительным сертификатом, и разрешает ему что-то, или запрещает в противном случае.

OpenVPN: как это бывает

На самом деле во многих компаниях на этот случай уже есть «PKI» и у него есть имя, потому что это кто-то из сотрудников. Назовем такого человека, к примеру, Полуэкт (с) и расскажем, как обычно это работает, а потом я расскажу, как это должно быть в идеале.

При появлении в компании нового сотрудника Полуэкт создает и присылает ему архив, в котором, помимо конфигурации собственно OpenVPN клиента, находятся файлы (на примере сотрудника Иванова А.А.):

В компании Acme все эти файлы генерирует Полуэкт…

А теперь как должно быть

На моем примере, упрощенно:

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

(пароль в конце лучше не указывать, а то придется его вводить каждый раз при подключении, а VPN у нас по сертификатам как раз, чтобы этого не было; тем более у нас в Pixonic есть OTP от Google);

Нужна ли вам эта фишка — вопрос для обсуждения. Соответственно, то, как ее внедрить, пока что выходит за рамки этой статьи.

И про срок действия клиентского сертификата: если предположить, что я устроился в Pixonic по временному контракту на 3 месяца, и мы его не продлили, то в описанной ситуации мой доступ к VPN автоматически отключится через 90 дней с момента выпуска сертификата. Чего не случится с SSH-доступом, если коллеги забудут отключить аккаунт во FreeIPA или удалить строчку из authorized_keys руками. C — сесуриту.

Теперь по Борщеву HTTPS

Предположим, вы хотите «включить SSL» для вашего сайта, чтобы у посетителей появился красивый замочек в браузере. Тут, собственно, все то же самое, но с некоторыми нюансами:

Источник

Инфраструктура открытых ключей

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

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

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

Типичная PKI состоит из следующих элементов.

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

В следующих разделах инфраструктура открытых ключей Майкрософт обсуждается более подробно:

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

OpenVPN и инфраструктура открытых ключей (PKI)

OpenVPN пользуется заслуженной популярностью у системных администраторов, находя широкое применения в самых разнообразных сценариях. Но очень часто внедрение OpenVPN происходит посредством повторения инструкций, без глубокого понимания смысла выполняемых действий. Особенно это касается «генерации ключей», эта простая с виду операция имеет достаточно глубокий скрытый пласт, формируя собственную инфраструктуру открытых ключей. Отсутствие понимания структуры PKI, как показывает отклик наших читателей, способно приводить к различного рода затруднениям и проблемам при использовании OpenVPN.

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

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

Но как сервер определит, что именно этот клиент имеет право доступа? Существует ошибочное мнение, что сертификаты выдает именно сервер и поэтому он знает, кто из клиентов имеет право подключаться, а кто нет. Однако это не так и данное заблуждение часто приводит к разного рода затруднениям при работе с OpenVPN.

В нашем случае таким «бюро пропусков» служит Центр сертификации (CA, Certification authority), вокруг которого складывается инфраструктура открытых ключей. Авторитет CA неоспорим и доверие к нему не подвергается сомнению. Именно CA осуществляет всё управление сертификатами, как для клиентов, так и для серверов.

Это абсолютно отдельная сущность, хотя физически она может находиться на одном узле с сервером OpenVPN. Чаще всего в роли центра сертификации используется Easy-RSA, хотя можно использовать любое другое ПО, скажем, в роли CA вполне может выступать Mikrotik. Но общий смысл от этого не меняется, создав центр сертификации мы вместе с ним создаем область доверия, которая называется инфраструктурой открытых ключей.

Давайте рассмотрим следующую схему:

При создании центра сертификации мы генерируем ключевую пару из открытого и закрытого ключей. Открытый ключ, вместе с другой информацией о нашем CA содержится в корневом сертификате ca.crt, который должен иметь самое широкое распространение в нашей инфраструктуре, так как именно он составляет основу доверительных отношений. Имея на руках корневой сертификат, мы можем проверить сертификат любого другого субъекта и убедиться, что он выдан нашим CA и следовательно мы можем ему доверять.

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

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

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

Таким образом на каждом из узлов нашей OpenVPN-сети должен присутствовать закрытый ключ, сертификат узла и корневой сертификат CA. При этом ни клиенты, ни сервера не знают кому именно выпущены сертификаты и в каком количестве.

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

Чтобы получить доступ клиент предъявляет серверу собственный сертификат, сервер, при помощи корневого сертификата CA убеждается, что данный сертификат действительно выдан нашим центром сертификации и ему можно доверять, затем проверяется срок его действия и при успешной проверке начинается процесс установления защищенного соединения.

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

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

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

Но OpenVPN так не умеет, что влечет за собой некоторые дополнительные действия. Рассмотрим еще одну схему:

После того, как CA обновил список отозванных сертификатов (CRL) его нужно распространить на все сервера OpenVPN в нашей инфраструктуре, после чего они будут понимать, что данный сертификат отозван и отказывать в соединении. Если мы не выполним данное условие, то те сервера, которые не получили обновленный CRL будут по-прежнему разрешать доступ клиенту сертификат которого отозван.

Что касается практики, то правильный сценарий предусматривает в пределах одной организации один центр сертификации, создание для нескольких OpenVPN-серверов нескольких CA является достаточно грубой ошибкой. Единственный CA позволяет иметь одну точку управления доверием для всей вашей сети вне зависимости от количества серверов и клиентов в ней.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Инфраструктура открытых ключей на базе российской криптографии: GnuTLS как альтернатива OpenSSL

OpenSSL — это набор полноценных криптографических библиотек и утилиты с открытым исходным кодом, который поддерживает почти все низкоуровневые алгоритмы хеширования, шифрования и электронной подписи, а также реализует большинство популярных криптографических стандартов. Однако, в число этих криптографических стандартов не входит российская криптография. Для полноценной работы с российской криптографией в OpenSSL необходимо дополнительно подключать движок (engine) gost-engine.

Мы уже писали, что альтернативой openssl может быть библиотека gcrypt. И вот теперь поддержка российской криптографии и криптографических механизмов реализована в проекте GnuTLS. GnuTLS поддерживает как старые криптографическе алгоритмы, так и новые — ГОСТ Р 34.10-2012 (электронная подпись), ГОСТ Р 34.11-2012 (хэширование), ГОСТ Р 34.12-2015 и ГОСТ Р 34.13-2015 (алгоритмы шифрования Кузнечик и Магма).

По аналогии с утилитой openssl в проекте OpenSSL, в проекте GnuTLS имеется утилита certtool, которая по своим функциональным возможностям не уступает утилите openssl.

Именно об этой утилите и её возможностях пойдет речь.

Общие сведения об утилите certtool

Как уже было отмечено, утилита certtool имеет много общего с утилитой openssl.

Первым параметром утилиты certtool, как правило, идет флаг, который определяет какую функцию необходимо выполнить. Например, флаг «—certificate-info», указывает на необходимость разобрать сертификат, а флаг «—generate-privkey» предписывает провести генерацию закрытого ключа. Входные данные, являющиеся объектами ИОК (ключи, сертификаты, списки отозванных сертификатов и т.д.), необходимые для выполнения команды, на вход поступают как ASN1-структуры в формате PEM (base64) или DER. По умолчанию используется формат PEM.

Если данные будут поступать в формате DER, то необходимо задать опцию «—inder».

Результатом выполнения соответствующей функции является ASN1-структура (тот же сертификат, например). По умолчанию, выходная ASN1-структура представляется в PEM-формате. Если её необходимо получить в DER-формате, то добавляется опция «—outder». Вместе с ASN1-структурой по умолчанию (опция «—text») выводится и её содержимое в текстовом виде. Если нет необходимости выводить текстовый вид, то задается опция «—no-text».

Все это можно продемонстрировать на примере конвертации файлов с сертификатами из формата PEM в DER и наоборот:

Для получения справки по утилите certtool выполните команду:

Теперь переходим к основным функциям утилиты certtool

Генерация и просмотр пары

Для генерации закрытого ключа по алгоритму ГОСТ Р 34.10 2012 используется следующая команда:

Криптопараметры (—curve) при генерации ключевой пары задаются OID-ами. В настоящее время TK-26 определил следующие oid-ы для криптопараметров алгоритма подписи ГОСТ Р 34.10-2012 с ключом 256:

1.2.643.7.1.2.1.1.1 (id-tc26-gost-3410-12-256-paramSetA) [TC26-256-A];
1.2.643.7.1.2.1.1.2 (id-tc26-gost-3410-12-256-paramSetB) [TC26-256-B];
1.2.643.7.1.2.1.1.3 (id-tc26-gost-3410-12-256-paramSetC) [TC26-256-C];
1.2.643.7.1.2.1.1.4 (id-tc26-gost-3410-12-256-paramSetD) [TC26-256-D].

При этом продолжают действовать так называемые OID-ы параметров от КриптоПро:

1.2.643.2.2.35.1 (id-GostR3410-2001-CryptoPro-A-ParamSet) [CryptoPro-A];
1.2.643.2.2.35.2 (d-GostR3410-2001-CryptoPro-B-ParamSet) [CryptoPro-B];
1.2.643.2.2.35.3 (id-GostR3410-2001-CryptoPro-C-ParamSet) [CryptoPro-C];
1.2.643.2.2.36.0 (id-GostR3410-2001-CryptoPro-XchA-ParamSet) [CryptoPro-XchA];
1.2.643.2.2.36.1 (id-GostR3410-2001-CryptoPro-XchB-ParamSet) [CryptoPro-XchB].

Напомним, что параметры КриптоПро с OID-ами 1.2.643.2.2.35.1, 1.2.643.2.2.35.2, 1.2.643.2.2.35.3 соответствуют параметрам ТК-26 с OID-ами 1.2.643.7.1.2.1.1.1, 1.2.643.7.1.2.1.1.2, 1.2.643.7.1.2.1.1.3 соответственно.

С криптопараметрами для алгоритма подписи ГОСТ Р 34.10-2012 с ключом 512 проще:

1.2.643.7.1.2.1.2.1 (id-tc26-gost-3410-2012-512-paramSetA) [TC26-512-A];
1.2.643.7.1.2.1.2.2 (id-tc26-gost-3410-2012-512-paramSetB) [TC26-512-B];
1.2.643.7.1.2.1.2.3 (id-tc26-gost-3410-2012-512-paramSetC) [TC26-512-C];

В информации о ключе мы имеем полную информацию как о приватном (закрытом) ключе, включая его asn1-структуру, так и публичном ключе, включая его значение (x и y).
Теперь посмотрим на asn1-структуру приватного ключа. Для этого воспользуемся утилитой cryptoarmpkcs:

Конечно, приватный ключ надо хранить надежно, по крайней мере зашифрованным на пароле. Для безопасного хранения приватного ключа используется контейнер PKCS8, который предоставляет возможность шифрования закрытого ключа с помощью шифрования на основе пароля пользователя. Поскольку здесь речь идет об использовании российской криптографии и рекомендаций ТК-26, то команда генерации закрытого ключа в защищенном контейнере PKCS8 будет иметь вид:

Если опция «—password» не задана, то пароль для шифрования закрытого ключа будет запрошен в командной строке:

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

Имея закрытый ключ, можно приступить к созданию запроса на сертификат.

Рассмотрим создание запроса на сертификат для физического лица. Сертификат планируется использовать для формирования и проверки электронной подписи. В этом случае файл с шаблоном запроса может содержать только отличительное имя (DN — distinguished name) владельца сертификата, которое включает следующие типы атрибутов/oid-ов и их значения:

Как видно из шаблона, атрибуты для DN (отличительного имени) могут задаваться как с использованием символьного имени атрибута, принятого в GnuTLS (например, country = RU), так и использованием oid-а атрибута:

.
В этом случае указать страну можно и так:

Итак, пусть закрытый ключ хранится в файле privkey.pem, а шаблон — в файле templateP10.txt. Тогда запрос может быть сформирован и просмотрен следующей командой:

Сохраним запрос на сертификат в файле request.pem, и отправимся с ним в УЦ за сертификатом.
Справедливости ради, стоит отметить, что утилита certtool имеет большие возможности по формированию не только запросов на сертификат, но самих сертификатов. Эти возможности ничем не уступают возможностям ни openssl ни nss.

Получение, просмотр и проверка сертификатов

Для выпуска сертификата всё же воспользуемся утилитой CAFL63:

Предположим, что выданный сертификат хранится в файле certfromreq.pem. Вместе с сертификатом пользователи, как правило, получают и сертификат самого удостоверяющего центра, т.е. сертификат, закрытым ключом которого подписан полученный сертификат. Наличие сертификата УЦ позволяет проверить пользовательский сертификат:

Например, есть пользовательский сертификат сохранен в файле certfromreq.pem, а сертификат УЦ в файле rootca_12_256_TC26.pem, то для проверки достаточно выполнить следующую команду:

Теперь, когда есть сертификат и его закрытый ключ, а также сертификат УЦ, можно их все вместе положить в один защищенный контейнер PKCS#12.

Работа с защищенным контейнером PKCS#12

Работая с российской криптографией, при создании защищенного контейнера PKCS#12, естественно руководствоваться Рекомендациями ТК-26, описывающими формирование транспортных ключевых контейнеров для ключей, созданных в соответствии с ГОСТ Р 34.10.

Исходя из этого, команда создания контейнера PKCS#12 будет выглядеть следующим образом:

Создадим контейнер PKCS#12:

Надо отметить, что сегодня защищенный контейнер PKCS#12 пользуется популярностью.
Контейнер PKCS#12, созданный утилитой certtool, успешно был разобран утилитой openssl с поддержкой ГОСТ. После этого решили воспользоваться утилитой cryptoarmpkcs, которая позволяет извлекать из контейнера PKCS#12 сертификат и его закрытый ключ и устанавливать их на токен PKCS#11, а также, используя сам контейнер, подписывать документы.

И тут пришлось столкнуться с неприятным сюрпризом:

Сюрприз заключается в том, что при создании контейнера PKCS#12 GnuTLS не учитывает последние требования ТК-26, которые гласят:

Целостность ТКК обеспечивается с использованием алгоритма HMAC_GOSTR3411_2012_512 в соответствии с Р 50.1.113— 2016.

/gnutls-xxx/lib/x509/pkcs7-crypt.c) поменять строку

После внесения этой правки всё встало на свои места и контейнер PKCS#12 от GnuTLS был принят утилитой cryptoarmpkcs:

Итак, имея контейнер PKCS#12 и утилиту cryptoarmpkcs, можно формировать различные виды подписи для документов (см. скриншот). Но нас сейчас интересует формирование электронной подписи утилитой certtool.

Электронная подпись PKCS#7

Команда формирования электронной подписи выглядит следующим образом:

Кстати, для тестирования формирования электронной подписи сертификат и его закрытый ключ можно взять из контейнера PKCS#12, приведенного в предыдущем разделе:

Если закрытый ключ был сохранён в файле privkey.pem, а сертификат пользователя в файле usercert.pem, то подписание документа из файла doc.txt с сохранением подписи в файле signdoc.sig будет выглядеть так:

Если подпись присоединённая (а по умолчанию именно она и создаётся), то извлечь подписанный документ можно следующей командой:

Для проверки самой электронной подписи необходим сертификат подписанта:

Послесловие

Я не ставил целью дать полное описание утилиты certtool и тем более написать документацию по GnuTLS. Это авторы и без меня хорошо сделали.

Целью было показать, что есть такое средство как GnuTLS и его можно использовать наряду с OpenSSL или GCrypt для работы с ИОК на базе российской криптографии. Насколько это удалось, судить читателю.

Источник

Инфраструктуры открытых ключей

6.2.2 Компоненты инфраструктуры открытых ключей (PKI)

Перед тем как мы подробно коснемся отдельных, предлагаемых PKI служб, в этом разделе мы дадим описание компонентов PKI.

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

Давайте рассмотрим, что необходимо для обеспечения этих служб, а также те компоненты, которые требуются современной инфраструктуре открытых ключей.

Основные компоненты инфраструктуры открытых ключей (PKI), как показано на рис. 6.17, включают:

Далее следуют подробные определения этих компонентов.

Конечный объект [End-Entity (EE)]

Центр сертификации [Certificate Authority (CA)]

Центр сертификации [ Certificate Authority (CA) ] по существу, является подписчиком сертификатов. Центр сертификации, зачастую совместно с центром регистрации (описанным далее), имеет своей обязанностью обеспечивать надлежащую идентификацию сертификата конечного объекта ( ЕЕ ). Логический домен, в котором СА выпускает сертификаты и управляет ими, называется доменом безопасности (security domain), который может быть реализован для защиты множества различных групп разных размеров, начиная от одного контрольного пользователя вплоть до департамента и далее до уровня всей организации. Основные проводимые СА операции включают: выпуск сертификатов, обновление сертификатов и аннулирование сертификатов.

Выпуск сертификатов

СА создает цифровой сертификат путем подписывания его цифровой подписью. По существу пара открытого и секретного ключей генерируется запрашивающим клиентом ( ЕЕ ). После этого клиент передает СА на рассмотрение запрос на выпуск сертификата.

Запрос на выпуск сертификата содержит по меньшей мере открытый ключ клиента и некоторую другую информацию, такую, как имя клиента, адрес электронной почты, почтовый адрес или другую относящуюся к делу информацию. Когда установлен центр регистрации ( RA ), СА делегирует ему процесс верификации клиента и другие функции управления. После подтверждения запроса клиента СА создает цифровой сертификат и подписывает его.

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

СА способен выпускать определенное количество различных типов сертификатов, таких, как:

Обновление сертификатов

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

Аннулирование сертификатов

Максимальный срок службы сертификата ограничен датой истечения его срока действия. Однако в некоторых случаях возникает необходимость аннулировать сертификаты до наступления этой даты. Когда это случается, CA включает сертификат в список аннулированных сертификатов [Certificate Revocation List ( CRL )]. На самом деле, если быть более точным, CA включает в этот список серийный номер сертификата вместе с некоторой другой информацией. Клиенты, которым необходимо знать о достоверности сертификата, могут осуществлять в CRL поиск по любому уведомлению об аннулировании.

Репозиторий сертификатов (CR)

Так как формат сертификатов X.509 нормально приспособлен к каталогу X.500, то соответственно наилучшим образом будет реализовать CR как каталог (Directory), который затем может быть доступен посредством наиболее общего протокола доступа – облегченного протокола доступа к каталогам LDAP ( Lightweight Directory Access Protocol ), последней версией которого является LDAP v3.

Центр регистрации (RA)

6.2.3 Сертификаты X.509

Ключевой частью инфраструктуры открытых ключей (и достойной собственного раздела для описания) является сертификат X.509.

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

Сертификаты X.509 обычно используются в защищенных интернет-протоколах, таких, как те, которые мы рассматриваем в настоящей лекции, а именно:

Что такое стандарт X.509?

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

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

Краткая история сертификатов X.509

Эти поля предоставляют большую гибкость по причине того, что они могут сообщать дополнительную информацию вдобавок к наличию только ключа и связанного с ним имени. Стандартизация основного формата v3 была завершена в июне 1996 г.

Содержимое сертификата X.509

Сертификат X.509 состоит из следующих полей:

Стандартные расширения включают среди прочих атрибуты субъекта и выпускающего сертификат, информацию о политике сертификации, ограничения в использовании ключей. Структура сертификата X.509 V3 проиллюстрирована на рис. 6.18.

Данные сертификата записываются согласно правилу синтаксиса системы обозначений для описания абстрактного синтаксиса 1 (ASN. 1), как это можно увидеть на рис. 6.19.

После этого они конвертируются в двоичные данные в соответствии с характерными правилами кодирования ASN.1, который является языком описания данных и определен организацией ITU-T как стандарты X.208 и X.209. Эта операция позволяет сделать данные сертификата независимыми от правил кодирования каждой конкретной платформы.

Источник