Как просмотреть содержимое ключей и сертификатов SSL –

Описание политик

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

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

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

Второй ответ вытекает из первого: описание политик выдачи сертификатов в конечном итоге станет документацией на всю PKI и будет иметь своё фирменное название – Certificate Practice Statement или CPS (к сожалению, не нашёл подходящего термина на русском языке, поэтому буду использовать англоязычную аббревиатуру).

Для унификации описания политик выдачи существует рекомендованный (но не обязательный) шаблон, описанный в RFC 3647. По сути, этот документ является фреймворком по написанию политик и освещает всевозможные аспекты работы PKI. Совершенно не обязательно описывать все имеющиеся разделы в документе. Можно документировать только то, что применимо к вашей ситуации, или добавлять что-то своё.

В общем случае CPS будет состоять из двух частей:

1. Описание иерархий PKI, общих для всех процедур и положений, которые будут общими для всех конкретных политик выдачи.
2. Описание положения специфичные для конкретной политики выдачи. В зависимости от размерности PKI, её особенностей, на каждую политику может составляться отдельный CPS, но чаще всего это сводится к составлению единого документа, который будет описывать всё.

Документация

Клиент

В нашей системе во внешний мир смотрит сервер IIS с ASP.NET web-api с методом, выдающим сертификат по запросу PKCS#10. На клиенте, то-есть на самих демо-площадках, крутится приложение на AngularJs, работающее с

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

— передаем функции плагина createPkcs10 данные полей для формирования запроса PKCS#10, получаем текст запроса.— текст запроса PKCS#10 передаем post-запросом на метод апи, получаем сертификат или ошибку в случае невозможности выписать сертификат.— передаем функции плагина importCertificate полученный сертификат, импортируем его на устройство.

Обработка цепочки списков ctl

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

Формирование списка CTL выполняется через выпадающее меню контейнера объекта групповой политики Enterprise Trust Group Policy Object. Доступ к данному контейнеру осуществляется последовательным выбором Windows SettingsSecurity SettingsPublic Key Policies.

Объекты GPO также выполняют автоматическую загрузку списков CTL в контейнер Enterprise Trust хранилища содержимого сертификатов. Отметим, что контейнер Enterprise Trust не является контейнером трастовых якорей — его содержимое не считается заслуживающим абсолютного доверия по умолчанию.

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

Гарантией успешной проверки цифровой подписи служит наличие сертификата из контейнера Trusted Root Certification Authorities в цепочке того сертификата, который использовался для подписи сертификата списка CTL. Как уже говорилось выше, определить, является ли цепочка сертификатов составной частью действительного списка CTL, можно путем просмотра каждого из сертификатов цепочки с помощью закладки Certification Path окна свойств сертификата.

Общие вопросы планирования

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

Например, срок действия сертификатов CA составляет порядка 10-20 лет. Одна из причин такого долгого срока жизни в том, что перевыпуск этих сертификатов является несколько трудоёмкой операцией и могут потребовать изменений на большом количестве клиентов.

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

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

Учитывая указанные моменты, к планированию PKI следует подходить самым серьёзным образом. И только тогда PKI будет успешно выполнять свои функции в обеспечении цифровой безопасности в течении продолжительного срока.

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

Определение политик

Для начала необходимо ввести определение политик выдачи сертификатов. Любой процесс выдачи/получения сертификата по сути является контрактом между получателем сертификата и издающим ЦС. Этот контракт определяет множество аспектов, таких как порядок выдачи, использования и зоны ответственности.

В каждой компании могут существовать различные методы проверки заявок и выдачи сертификатов. Рассмотрим несколько типовых случаев:

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

Вот эти различия в процедурах и являются политиками выдачи, и эти политики должны регистрироваться в сертификатах. Конечные приложения могут использовать политики выдачи для определения доступа к ресурсу. Наиболее известными примерами таких приложений являются Network Policy Server (NPS) и Active Directory Dynamic Access Control.

В NPS можно настроить правило, что будет приниматься не просто сертификат входа, а тот, который был выдан в соответствии с политикой выдачи сертификатов для смарт-карт. Поскольку эта информация отражена в сертификате, NPS может различить два похожих сертификата (оба для аутентификации пользователя) по политикам выдачи.

Если сертификат не содержит свидетельств, что он был выдан в соответствии с указанной политикой выдачи, то доступ к сети не будет разрешён. Похожий принцип заложен и в Active Directory Dynamic Access Control, где можно указать критерии для различных уровней доступа.

Планирование аппаратных требований

Службы сертификатов AD CS в целом нетребовательны к аппаратным ресурсам (на фоне других серверных служб). Основная нагрузка ложится на центральный процессор для выполнения криптографических операций (хэширование, шифрование и подпись). Кроме того, есть определённая нагрузка на диски для работы базы данных сертификатов (AD CS использует JET Database Engine). Это в теории.

На практике аппаратных ресурсов даже бюджетных линеек серверов будет более чем достаточно для функционирования служб сертификатов, поскольку реальные потребности весьма малы на фоне требований ОС к аппаратным ресурсам. В эпоху Windows Server 2003 была написана статья Evaluating CA Capacity, Performance, and Scalability (ссылка на архивную копию, т.к. оригинал удалён с сайта TechNet), освещающую общие моменты, которые нужно учитывать при планировании аппаратных ресурсов.

В 2021 году, Windows PKI Team провела тесты производительности с использованием более современного оборудования (образца 2007 года) под управлением Windows Server 2008. С результатами можно ознакомиться в их блоге: Windows CA Performance Numbers.

Данные в этих статьях, говорят о том, что сервер AD CS на аппаратном сервере выпуска 2007 года позволяет выпускать порядка 150 сертификатов в секунду. Реальная же потребность в скорости выдачи сертификатов на порядки ниже. Поэтому для ЦС общего назначения советую ориентироваться на рекомендуемые аппаратные требования к самой ОС.

Здесь следует отметить, что в конфигурации для корневого ЦС будет отсутствовать (или должен быть отключен) сетевой интерфейс (поскольку он не будет подключен к сети) и присутствовать хотя бы один интерфейс для съёмных носителей.

Планирование имён цс

Имя ЦС – это имя, которое будет отображено в поле

Subject

конкретного ЦС. Не путать с именем хоста, на котором работает служба сертификатов. Полное имя ЦС будет состоять из двух компонентов, самого имени (атрибут CN или Common Name) и опционального суффикса в формате X.500. По умолчанию ADCS назначает имя в следующем формате:

Для Standalone CA: <ComputerName>-CA

Для Enterprise CA: <DomainShortName>-<ComputerName>-CA, <X500DomainSuffix>

Хорошо это или плохо? Технически, вы можете выбрать любое имя, функционально оно ни на что влиять не будет. Есть мнение, что имя вашего ЦС является в некотором роде визитной карточкой вашей PKI, отражая ваше отношение к деталям, которые не имеют непосредственного отношения к функциональности, но обеспечивают достаточный уровень информативности и открытости. Поэтому при выборе полного имени сертификата следует руководствоваться несколькими рекомендациями:

Предположим, что вы подбираете имя для корневого ЦС компании Contoso Pharmaceuticals Ltd., которая находите в городе Рига, Латвия и управление обеспечивается отделом информационных технологий. В этом случае имя ЦС может иметь следующий вид:

CN=Contoso Pharm Root Certification Authority, OU=Division Of IT (DoIT), O=Contoso Pharmaceuticals Ltd., L=Riga, C=LV

Следует помнить, что атрибут Country поддерживает только двухбуквенный индекс страны. Например, LV, GB, RU, US и т.д. В качестве дополнительных примеров, можете обратиться к сертификатам ЦС коммерческих провайдеров, как VeriSign/Symantec, DigiCert и т.д.

Для подчинённого ЦС это имя будет похожим, за исключением того, что слово Root в имени будет заменено на Subordinate или Issuing. В случае трёхуровневой иерархии, где явно выделяется ЦС политик, слово Root будет заменено на Policy. Как я выше отмечал, в вашей компании могут применяться другие правила, и вы можете их внедрить в имена ЦС, на функциональность это влиять не будет. При этом следует избегать:

• Чрезмерно длинных имён в атрибуте CN (не более 50 символов). При длине атрибута CN свыше 51 символа, оно будет укорочено с пристыковкой хэша отброшенного фрагмента имени в конец имени. Это называется процессом «санитизации» имени, который описан в §3.1.1.4.1.1 протокола [MS-WCCE]. Т.е. может случиться так, что при слишком длинном имени слово оборвётся на середине и будет иметь неприглядный вид.
• Использовать буквы, которые не входят в состав латинского алфавита, т.е. никакой криллицы или диактрических букв (например, ā, ž, Ü, ẞ). ADCS поддерживает только однобайтовые кодировки для атрибута CN и для ограниченного набора символов. Неподдерживаемые символы будут преобразованы в другую кодировку и станут нечитаемыми. Полный список запрещённых символов представлен в §3.1.1.4.1.1.2 протокола [MS-WCCE]. Здесь работает принцип «лучшее – враг хорошему», поэтому имена должны быть достаточно лаконичными и информативными.

Планирование сроков действия crl

Это всё было о составе списков отзыва для каждого ЦС. Теперь следует определить сроки:

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

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

Можно понять желание администраторов уменьшить это время (в идеале – мгновенно), чтобы клиенты не признавали отозванный сертификат действительным. Однако, уменьшение одного риска приводит к увеличению другого риска. Представьте, что по какой-то причине отказал сервер ЦС в момент, когда предыдущий CRL близок к истечению срока действия, а новый CRL невозможно опубликовать.

Microsoft CA по умолчанию уже закладывает некоторый резерв по времени на непредвиденные случаи и когда распространение списков отзыва по всем точкам публикации занимает некоторое время (например, вызваны латентностью репликации). Этот резерв в английской терминологии называется CRL overlap.

Это достигается использованием двух полей в списке отзыва: Next CRL Publish и Next Update. Поле Next CRL Publish указывает на время, когда ЦС опубликует обновлённый список отзыва (автоматически). Next Update указывает на время, когда срок действия текущего списка истечёт.

Поле Next Update будет всегда выставлен на несколько позднее время, чем Next CRL Publish. Другими словами, ЦС опубликует обновлённый список отзыва до истечения срока предыдущего. Алгоритм вычисления автоматических значений для этих полей нетривиален и описан в следующей статье:

How ThisUpdate, NextUpdate and NextCRLPublish are calculated (v2). Если значения по умолчанию вас не устраивают по тем или иным причинам, их можно отредактировать. Необходимо учитывать, что запас по времени имеет нижние и верхние границы.

Например, верхняя граница не может превышать срока действия самого CRL. Так, если срок действия CRL составляет 1 день, то запас может составлять максимум 1 день, и тогда ЦС будет публиковать списки отзыва ежедневно, но срок действия будет составлять 2 дня. Тем самым достигается запас времени на восстановление ЦС в случае непредвиденных обстоятельств.

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

При планировании сроков действия CRL и периодичности следует руководствоваться следующими рекомендациями:

Построение диаграммы pki

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

На диаграмме представлены следующие компоненты и их логические связи:

Физическая топология будет несколько отличаться и иметь следующий вид:

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

Проверка подписанного cms на сервере

Будем генерировать CMS на клиенте и отправлять его на сервер, где проверим подпись и цепочку сертификатов.

Из BouncyCastle задействуем:— Проверку подписи signed CMS— Построение цепочки сертификатов

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

Проверку подписанного CMS делаем так:

// сторим цепочку сертификатов
public void verifyCert(X509Certificate cert)
		{
			try
			{
				// читаем корневой сертификат
				var pRd = new PemReader(new StringReader(cCACert));
				var _cCACert = (X509Certificate)pRd.ReadObject();
				pRd.Reader.Close();


				// список сертификатов для цепочки
				IList certList = new ArrayList();
				certList.Add(_cCACert);
				certList.Add(cert);

				IX509Store x509CertStore = X509StoreFactory.Create( "Certificate/Collection",
			   new X509CollectionStoreParameters(certList));

				//делаем список корневых сертификатов, в данном случае один
				ISet trust = new HashSet();
				trust.Add(new TrustAnchor(_cCACert, null));

				PkixCertPathBuilder cpb = new PkixCertPathBuilder();
				X509CertStoreSelector targetConstraints = new X509CertStoreSelector();
				targetConstraints.Subject = cert.SubjectDN;
				PkixBuilderParameters parameters = new PkixBuilderParameters(trust, targetConstraints);

				parameters.AddStore(x509CertStore);
				// отключаем проверку crl
				parameters.IsRevocationEnabled = false;

				// строим цепочку, если построилась - ок
				PkixCertPathBuilderResult result = cpb.Build(parameters);


			}
			catch (PkixCertPathBuilderException certPathEx)
			{
				throw new PkixCertPathBuilderException(string.Format("Ошибка проверки цепочки, {0}", certPathEx.Message));
			}
			catch (Exception ex)
			{
				throw new Exception(string.Format("Ошибка проверки сертификата: {0}", cert.SubjectDN), ex);
			}
		}

// проверка signed CMS
		public string verifyCms(string cmsText)
		{
			CmsSignedData cms = new CmsSignedData(Base64.Decode(cmsText));
			SignerInformationStore sif = cms.GetSignerInfos();
			var signers = sif.GetSigners();
			var ucrts = cms.GetCertificates("collection");
			//var crl = cms.GetCrls("collection");
			
			// нужно проверять все, но у нас один signer и один сертификат
			foreach (SignerInformation signer in signers)
			{

				ICollection certCollection = ucrts.GetMatches(signer.SignerID);
				IEnumerator certEnum = certCollection.GetEnumerator();

				certEnum.MoveNext();
				X509Certificate cert = (X509Certificate)certEnum.Current;

				if (!signer.Verify(cert))
				{
					throw new CertificateException("проверка подписи не прошла");
				}

				verifyCert(cert);
			}

			return "ok";
		}

Еще раз повторюсь, пример подходит для тестирования или демонстрации решений, работающих с российскими сертификатами.

Проверка работоспособности crl

Итак, наступает ответственный момент, в котором нам необходимо проверить работает ли список отозванных сертификатов в нашем случае. Для этого после установки CRL зайдите в систему DIRECTUM и попытайтесь подписать какой-либо объект системы отозванным сертификатом.
Если все действия были проделаны верно, то мы получим сообщение следующего вида:

А теперь проверим данные в компоненте “Пользователи”, действительно ли ИД сертификата в сообщении равен тому, что указан в карточке пользователя:

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

Дополнительную информацию о процедуре формирования CRL, а также необходимых команд, вы можете найти на следующем ресурсе:

Программирование политик

В процессе составления CPS будет определена одна или несколько уникальных политик выдачи (как минимум одна будет обязательно). Каждая политика выдачи должна иметь уникальный идентификатор и указатель на CPS (гиперссылка или текстовая строка).

Идентификаторы политик должны быть представлены в формате ITU-T и ISO. В своё время я написал небольшую вводную статью про объектные идентификаторы: Что в OID’е тебе моём? В ней есть информация о том, как получить в IANA (Internet Assigned Numbers Authority) свою ветку идентификаторов.

Далее вы назначаете конкретные политики выдачи для ЦС, которые будут их поддерживать. Например, у вас может быть несколько издающих ЦС, каждый из которых будет поддерживать только определённые политики. Список поддерживаемых политик будет содержаться в расширении Certificate Policies сертификата ЦС, а также в сертификатах конечных потребителей.

Просмотр содержимого ключей и сертификатов

Мы можем подробно изучить содержимое всех созданных в OpenSSL файлов, а также при необходимости конвертировать их в другие форматы.

В следующих командах используются тестовые файлы со следующими именами:

Обратите внимание на расширения файлов — они могут отличаться от тех, которые используются в других инструкциях. Например, вместо .key и .crt может использоваться расширение .pem. Расширение файла не имеет особого значения кроме как служить подсказкой пользователю, что именно находится в этом файле. Это же самое касается и имён файлов — вы можете выбирать любые имена.

Все эти файлы являются текстовыми:

cat rootCA.key

Там мы увидим примерно следующее:

-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDJBKkr6XzzAcXD
eyDQdvB0SWE2Fl3nqlX/c2RgqMgScXtgidEzOu9ms3Krju5UKLokkQJrZFPMtiIL
MuPJFdYjVyfkfnqlZiouBVgJ60s8NQBBI8KnyyAoJCIFdASoW4Kv5C5LT8pX9eRa
/huJaRJL5XsFUGnTOLvW2ZLN52iAux9CoZlmH6ZF4nuQpblwN0MHULAhze52VNFT
…………………………………………………..
…………………………………………………..
…………………………………………………..
…………………………………………………..
…………………………………………………..
…………………………………………………..
-----END PRIVATE KEY-----

Процедуры сличения

В процессе проверки подлинности сертификата для него выполняются процедуры сличения по следующим критериям: цифровая подпись (digital signature), параметры отношений доверия (trust), временные параметры (time), информация об аннулировании сертификата (revocation) и параметры формата (formatting).

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

Для проверки подлинности подписи недостаточно просто наличия открытого ключа, он должен быть заслуживающим доверия. В инфраструктурах PKI систем Windows Server 2003 и Windows 2000 Server сертификат и открытый ключ заслуживающего абсолютного доверия центра CA называются трастовыми якорями (trust anchor), а доступ к ним осуществляется через контейнер Trusted Root Certification Authorities хранилища сертификатов клиента Windows PKI.

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

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

Во время выполнения процедуры сличения срока действия (revocation check) проверяется, не аннулирован ли данный сертификат выдавшим его центром CA. В средах PKI систем Windows 2003 и Windows 2000 Server реализована поддержка работы с абсолютными списками аннулированных сертификатов (complete CRL) и узлами распространения списков CRL (CRL Distribution Point, CDP).

Помимо этого, служба Windows 2003 Certificate Services может работать и со списками изменений (delta CRL). Используя списки CRL, списки изменений CRL и узлы CDP, можно обеспечить проверку срока действия сертификатов в автоматическом режиме. Более подробно вопросы, связанные с аннулированием сертификатов, рассмотрены в статье «Процедуры аннулирования сертификатов в инфраструктуре Windows PKI», опубликованной в журнале Windows IT Pro/RE № 4 за 2006 г.

Сервер

Но вернемся на серверную часть. Итак, у нас есть корневой сертификат в формате PEM и закрытый ключ к нему. Будем выдавать пользовательский сертификат по запросу PKCS#10. Сам запрос также приходит от клиента в текстовом виде, в формате PEM.

		/* тестовый корневой сертификат */
		const string cCACert = @"-----BEGIN CERTIFICATE-----
*** сам сертификат ***
-----END CERTIFICATE-----";

		/* ключ корневого сертификата*/
		const string cCAKey = @"-----BEGIN PRIVATE KEY-----
*** ключ ***
-----END PRIVATE KEY-----";

// выписываем тестовый сертификат
public string generateTestCert(string pkcs10text)
		{
			// читаем приватный ключ
			PemReader pRd = new PemReader(new StringReader(cCAKey));
			AsymmetricKeyParameter _cCAKey = (AsymmetricKeyParameter)pRd.ReadObject();
			pRd.Reader.Close();

			// читаем корневой сертификат
			pRd = new PemReader(new StringReader(cCACert));
			var _cCACert = (X509Certificate)pRd.ReadObject();
			pRd.Reader.Close();

			// как вариант:
			//X509CertificateParser certParser = new X509CertificateParser();
			//var _caCert = certParser.ReadCertificate(Base64.Decode(cCACert.Replace("-----BEGIN CERTIFICATE-----", string.Empty).Replace("-----END CERTIFICATE-----",string.Empty)));

			Pkcs10CertificationRequest _pkcs10;
			// читаем pkcs10
			using (StringReader _sr = new StringReader(pkcs10text))
			{
				pRd = new PemReader(_sr);
				_pkcs10 = (Pkcs10CertificationRequest)pRd.ReadObject();
				pRd.Reader.Close();
			}


			// выпускаем сертификат
			X509V3CertificateGenerator v3CertGen = new X509V3CertificateGenerator();

			var requestInfo = _pkcs10.GetCertificationRequestInfo();
			var subPub = _pkcs10.GetPublicKey();
			var issPub = _cCACert.GetPublicKey();

			// серийный номер
			var randomGenerator = new CryptoApiRandomGenerator();
			var random = new SecureRandom(randomGenerator);
			var serialNumber =
				BigIntegers.CreateRandomInRange(
					BigInteger.One, BigInteger.ValueOf(Int64.MaxValue), random);

			v3CertGen.Reset();
			v3CertGen.SetSerialNumber(serialNumber);
			v3CertGen.SetIssuerDN(_cCACert.IssuerDN);
			v3CertGen.SetNotBefore(DateTime.UtcNow);
			// сертификат на год
			v3CertGen.SetNotAfter(DateTime.UtcNow.AddYears(1));
			v3CertGen.SetSubjectDN(requestInfo.Subject);
			v3CertGen.SetPublicKey(subPub);

			if (issPub is ECPublicKeyParameters)
			{

				// в тестовых примерах можно посмотреть на генерацию с различными алгоритмами, на нужен только GOST3411withECGOST3410
				ECPublicKeyParameters ecPub = (ECPublicKeyParameters)issPub;
				if (ecPub.AlgorithmName == "ECGOST3410")
				{
					v3CertGen.SetSignatureAlgorithm("GOST3411withECGOST3410");
				}
				else
				{
					throw new Exception("нужен алгоритм подписи GOST3411withECGOST3410");
				}
			}
			else
			{
				throw new Exception("нужен GOST3411withECGOST3410");
			}

			// extensions
			v3CertGen.AddExtension(
				X509Extensions.SubjectKeyIdentifier,
				false,
				new SubjectKeyIdentifier(SubjectPublicKeyInfoFactory.CreateSubjectPublicKeyInfo(subPub)));

			v3CertGen.AddExtension(
				X509Extensions.AuthorityKeyIdentifier,
				false,
				new AuthorityKeyIdentifier(SubjectPublicKeyInfoFactory.CreateSubjectPublicKeyInfo(issPub)));

			v3CertGen.AddExtension(
				X509Extensions.BasicConstraints,
				false,
				new BasicConstraints(false));

			X509Certificate _cert = v3CertGen.Generate(_cCAKey);

			_cert.CheckValidity();
			_cert.Verify(issPub);

			var s = new StringWriter();
			PemWriter pw = new PemWriter(s);

			pw.WriteObject(_cert);
			pw.Writer.Close();

			return s.ToString();
		}

Стандартная процедура обработки цепочки сертификатов

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

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

При использовании иерархической модели доверительных отношений каждый сертификат содержит указатель на родительский (или выдавший сертификат) центр CA, который хранится в поле issuer сертификата X.509. На рис. 1 показан пример цепочки для пользовательского сертификата, выданного центром CA при наличии двухуровневой иерархии в инфраструктуре PKI. Рис.

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

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

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

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

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

Проверка подлинности цепочки сертификатов.

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

Для идентификации сертификата центра CA во время процедуры проверки подлинности цепочки используется расширение Authority Key Identifier (AKI) проверяемого сертификата. В поле AKI содержится информация следующих типов.

• Имя центра, выдавшего сертификат и серийный номер сертификата данного центра. Если эта информация имеется в поле AKI, тогда программа проверки подлинности выполняет поиск совпадающего сертификата, используя поля Serial number и Subject. Данный метод идентификации сертификата называется строгим совпадением.
• Идентификатор открытого ключа (KeyID) сертификата центра, выдавшего проверяемый сертификат. Если эта информация имеется в поле AKI, тогда программа проверки подлинности выполняет поиск совпадающего сертификата, используя расширение сертификата Subject Key Identifier (SKI), в котором хранится уникальный идентификатор открытого ключа сертификата субъекта. Данный метод идентификации сертификата называется совпадением ключей.

Если в проверяемом сертификате поле AKI отсутствует, программа проверки подлинности пытается идентифицировать сертификат выдавшего центра CA с помощью проверки совпадения имени, взятого из поля Issuer проверяемого сертификата, с содержимым поля Subject сертификата. Данный метод идентификации сертификата называется совпадением имен.

Состав списков отзыва

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

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

базовый (Base CRL) и дифференциальные (Delta CRL). Базовый список включает полный список отзыва. Дифференциальный список включает в себя только список отозванных сертификатов, которые были отозваны с момента последней публикации базового CRL. Это позволяет вам публиковать базовый список реже и на более длительный срок, а для ускорения времени реакции клиентов на отозванные сертификаты в промежутке выпускать несколько короткоживущих дифференциальных CRL.

Подбор параметров зависит от несколько факторов. Например, планируемый объём издаваемых сертификатов и планируемый объём отзыва. Рассмотрим типовые сценарии.

Корневой ЦС

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

Справка: как посчитать планируемый размер файла CRL исходя из объёмов отзыва? Типичный пустой CRL занимает примерно 600-800 байт. Каждая запись об отозванном сертификате занимает 88 байт. Исходя из этих значений можно высчитать размер CRL в зависимости от количества отозванных сертификатов.

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

Издающий ЦС

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

Как следствие, список отзыва может достигать серьёзных размеров. Например, если заложить 10% риск отзыва, то на миллион изданных сертификатов приходится порядка 100к отозванных. 100к записей по 88 байт будет составлять немногим меньше 10мб. Очень часто обновлять файл на 10мб не очень практично, целесообразней его публиковать реже, а в интервале между публикациями основного CRL распространять несколько облегчённых дифференциальных Delta CRL. Т.е. если для корневого ЦС достаточно только базового списка отзыва, то для ЦС, выпускающих сертификаты конечным потребителям, следует применять и дельты.