Обзор инфраструктуры открытых ключей Цифровой сертификат

Некоторые обсуждаемые в данном курсе протоколы и технологии используют для своей работы алгоритмы асимметричного шифрования и цифровой подписи. Эти алгоритмы используют два разных, но математически связанных, ключа для шифрования и расшифровывания. При этом данные, зашифрованные одним ключом, могут быть расшифрованы только другим ключом (и наоборот). Один ключ называется секретным (private), он известен только его владельцу. Другой ключ называется открытым (public) и доступен всем. Любой желающий может воспользоваться открытым ключом получателя для шифрования сообщения, но только получатель сможет расшифровать его своим секретным ключом.
При использовании асимметричного шифрования для защиты данных и цифровой подписи слабым местом остается обмен открытыми ключами. Открытый ключ не связан с пользователем или компьютером, поэтому может быть легко подменен при передаче. Чтобы избежать этих проблем, принадлежность открытого ключа и его неизменность при передаче подтверждается третьей стороной, которой доверяет получатель, путем включения открытого ключа в цифровой сертификат (digital certificate).
Цифровой сертификат состоит из следующих частей:

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

Формат цифрового сертификата описан стандартом Х.509 версии 3 (RFC 2459).

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

Центр сертификации или Удостоверяющий Центр (certification authority, СА) — та самая третья сторона, которая выдает цифровые сертификаты пользователям и компьютерам. Центр сертификации имеет свою собственную пару ключей (открытый и секретный ключи). Открытый ключ УЦ оформлен в виде сертификата (СА certificate), который доступен всем. Секретный ключ центра сертификации используется для генерации цифровой подписи для пользовательских сертификатов. Цифровая подпись представляет собой хэш сертификата пользователя, зашифрованный секретным ключом центра сертификации. Цифровая подпись сертификата позволяет:

• обнаружить неавторизованные изменения в сертификате;
• убедиться, что сертификат выдан именно этим центром сертификации.

Любой пользователь, имеющий открытый ключ центра сертификации (СА certificate), может вычислить собственный хэш сертификата и сравнить его с расшифрованным хэшем. Если значения хэшей совпали, значит сертификат был «подписан» именно закрытым ключом СА и сертификат не был изменен.
Можно также сказать, что наличие у сертификата цифровой подписи показывает, что центр сертификации успешно произвел проверку подлинности пользователя перед выдачей ему цифрового сертификата.

Основные области применения цифровых сертификатов
В таблице описаны основные области применения цифровых сертификатов. Таблица 3.1. Основные области применения цифровых сертификатов

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

Планирование структуры центров сертификации
Центральный компонент инфраструктуры открытых ключей — служба сертификации (Certification Authority) — входит в состав серверных операционных систем Microsoft. Следует заметить, что наибольшей функциональностью обладает служба сертификации в Windows Server 2003 Enterprise Edition. Например, только в Windows Server 2003 Enterprise Edition доступны функции автоматического архивирования ключей или автоматического развертывания сертификатов пользователя.» (certificate autoenrollment for users).
В Windows поддерживается два типа центров сертификации — Stand-alone Certification Authority и Enterprise Certification Authority. В таблице 3.2 представлены основные отличия этих типов.
Таблица 3.2. Основные отличия типов центров сертификации Windows Server 2003

Если требуется выдавать сертификаты пользователям и компьютерам только в пределах организации, рекомендуется использование Enterprise СА, так как этот вариант гораздо более удобен в использовании и управлении и обладает большей функциональностью.

При построении PKI часто выбирают иерархическую (hierarchical) модель центров сертификации. В иерархической модели центры сертификации выстроены в древовидную структуру с корневым центром сертификации (root CA). Корневой центр сертификации имеет сертификат (root CA certificate), снабженный собственной цифровой подписью. Сертификат подчиненного центра (subordinate CA) выдан вышестоящим центром и подписан его цифровой подписью. Корневой и промежуточные (intermediate) CA не выдают сертификаты непосредственно пользователям — этим занимаются лишь самые нижние в иерархии центры сертификации. В такой модели, если пользователь доверяет (trust) корневому центру сертификации, то он доверяет всем сертификатам, выданным любым центром сертификации из этой иерархии.
В пределах иерархии допускается использование разных типов СА. Например, корневой СА может быть типа Stand-alone, а подчиненный — Enterprise и наоборот.
Для повышения безопасности PKI после выдачи сертификатов подчиненным центрам сертификации корневой центр сертификации часто отключают от сети (так называемый offline СА). Компания Microsoft рекомендует использовать в качестве offline СА вариант Stand-alone СА.

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

1. Выдан ли этот сертификат центром сертификации, которому доверяет сторона-получатель?

В сценарии с Web-севером Web-браузер клиента прослеживает всю цепочку центров сертификации снизу вверх от сертификата Web-сервера до корневого центра сертификации и собирает сертификаты самих СА. Далее проверяется, находится ли сертификат корневого центра сертификации в списке доверенных С А (список Trusted Root Certification Authorities). Если сертификат корневого центра сертификации присутствует в доверенном списке, то и сертификат Web-сервера признается доверенным. В ОС Windows список доверенных СА изначально содержит набор корневых сертификатов крупнейших коммерческих компаний, занимающихся выдачей сертификатов (Verisign, Entrust, Thawte, GTE CyberTrust и других).
Таким образом, при планировании центров сертификации следует учитывать степень доверия к сертификатам. Если выданные вашим центром сертификаты будут оцениваться внешними по отношению к вашей организации пользователями (как в данном сценарии), то следует рассмотреть вариант установки в вашей организации подчиненного СА по отношению к известному коммерческому СА.

2. Не были ли сертификаты в цепочке доверия изменены в транзите?
Каждый сертификат (кроме корневого) имеет цифровую подпись вышестоящего центра сертификации. Например, на рисунке 3.2 сертификат web-сервера имеет цифровую подпись, проставленную центром сертификации Microsoft Secure Server Authority. Загрузив сертификат самого СА Microsoft Secure Server Authority, можно проверить целостность сертификата Web-сервера. Так прослеживается целостность всех сертификатов в цепочке. Корневой сертификат имеет собственную цифровую подпись (self-signed certificate).

3. Не истек ли срок действия сертификатов в цепочке?
Каждый сертификат имеет определенный срок действия, который определяется двумя полями сертификата — Valid from и Valid to. Для того чтобы сертификат успешно прошел проверку, необходимо, чтобы все сертификаты в цепочке имели не истекший срок действия.

4.  Не были ли отозваны сертификаты?
Отзыв цифрового сертификата (certificate revocation) — это метод признания сертификата недействительным до окончания его срока действия. Каждый центр сертификации периодически публикует список серийных номеров сертификатов, признанных недействительными — так называемый список отозванных сертификатов (certificate revocation list, CRL). Для того чтобы сертификат успешно прошел проверку необходимо, чтобы ни один сертификат в цепочке не был отозван. Следует заметить, что эта проверка часто бывает отключена, так как она может привести к дополнительным задержкам при проверке сертификатов и повышенному трафику. Например, в браузере Microsoft Internet Explorer эта проверка выключена. Ее можно включить в настройках IE на закладке Advanced (опция Check for server certificate revocation).

Поля сертификата AIA и CDP
Критическую роль при проверке сертификатов играют поля сертификата Authority Information Access (AIA) и CRL Distribution Point (CDP).
Поле AIA сертификата указывает, где можно найти сертификат «родительского» СА. Например, в поле AIA сертификата Web-сервера partnering.one.microsoft.com можно загрузить сертификат самого центра сертификации Microsoft Secure Server Authority. В качестве примера на рисунке 3.3 приведено содержимое поля AIA для сертификата Web-сервера.
Поле CDP сертификата указывает, где найти список отозванных сертификатов (CRL) соответствующего центра сертификации. В качестве примера на рисунке 3.4 приведено содержимое поля CDP для сертификата Web-сервера.

Установка центра сертификации в Windows Server 2003
Перед установкой Службы сертификации в Windows Server 2003 необходимо зарегистрироваться как пользователь, имеющий права на установку службы. Для установки Stand-alone СА достаточно прав локального администратора, но для установки Enterprise СА кроме административных прав на локальном компьютере необходимо также иметь права Enterprise Administrator (член группы Enterprise Admins).
Чтобы клиенты могли получать цифровые сертификаты через web-интерфейс перед установкой Службы сертификации необходимо установить на компьютер службу Internet Information Services (компонент Web Server).

Примечание: получение сертификатов через web-интерфейс — единственный способ получения сертификатов при использовании варианта Stand-alone СА.

Для задания дополнительных настроек СА администратором перед установкой может быть вручную создан файл CAPolicy.inf, который должен располагаться в папке systemroot (обычно C:\Windows). Описание этого файла приведено в разделе Installing and configuring a certification authority (Windows Server 2003 Help). Создание этого файла не является обязательным, но требуется в ряде случаев. Например, необходимо создавать этот файл перед установкой корневого центра сертификации, который планируется использовать в варианте Offline. В этом случае файл используется для того, чтобы в корневом сертификате не были заполнены поля А1А и CDP (создание Offline Root СА рассматривается в практической работе ЗА).
Пример содержимого файла приведен ниже. При использовании такого файла будет создан корневой сертификат с длиной ключа  2048 бит, сроком на 16 лет и с пустыми полями AIA и CDP.

[Version]
Signature="$windows NT$" [Certsrv_Server]
RenewalKeyLength=2048
RenewalvalidityPeriod=Years
RenewalValidityPe ri oduni ts=16
[CRLDistributionPoint]
Empty=true
[AuthoritylnformationAccess]
Empty=true

Установка самой Службы сертификации выполняется с помощью значка Add/Remove Programs (Add/Remove Windows Components - Certificate Services). При установке требуется задать тип СА (Enterprise Root, Enterprise Subordinate, Stand-alone Root, Stand-alone Subordinate) и параметры сертификата CA. Для случаев Subordinate на этапе установки формируется запрос (certificate request), который используется вышестоящим центром сертификации для выдачи сертификата подчиненному СА. Следует отметить, что без сертификата, выданного вышестоящим СА, подчиненный СА стартовать не может.

Модификация AIA и CDP
После установки центра сертификации может потребоваться модификация полей AIA и CDP. Дело в том что ссылки в этих полях должны быть доступны для клиентов, получивших сертификат. Например, если домен использует имя внутреннее test.firm, то после установки СА поля А1А и CDP могли бы содержать ссылку на http://server1.test.firm. Если сертификат с такими значениями полей AIA и CDP будет выдан внешним клиентам, то эта ссылка будет недоступной и клиенты не смогут построить цепочку доверия или получить список отозванных сертификатов.
Для изменения полей AFA и CDP используется административное средство Certification Authority (в свойствах службы сертификации нужно перейти на закладку Extensions).
Особенно внимательно нужно отнестись к изменению этих полей у корневого центра сертификации, который будет работать в варианте Offline. Необходимо указать в этих полях ссылки, которые будут доступны подчиненным центрам сертификации, даже когда корневой центр будет отключен от сети. Обычно следует указать ссылки на отдельный web-сервер, куда следует вручную положить корневой сертификат и список отозванных сертификатов. Поскольку список отозванных сертификатов действителен по умолчанию всего 7 дней, то без дополнительных настроек корневого центра подчиненный центр сертификации не сможет стартовать позже этого срока, поскольку не сможет определить, был ли его сертификат отозван корневым центром. Чтобы этого не произошло необходимо действовать следующим образом:
изменить на корневом СА период публикации списка отозванных сертификатов (например, сделать его равным времени жизни корневого сертификата);
опубликовать новый список отозванных сертификатов;
вручную переместить этот список и корневой сертификат в местоположение, указанное в полях AIA и CDP сертификата подчиненного центра сертификации.

Настройка «доверия» к сертификату

При установке Enterprise СА автоматически настраивается доверие к выданным этим центром сертификатам. При этом сертификат корневого центра сертификации автоматически добавляется в хранилище Trusted Root Certification Authorities на каждом компьютере, являющемся членом домена.
В тех случаях, когда требуется настроить доверие к сертификатам, выданным каким-либо частным (например, партнерским) центром сертификации, можно воспользоваться групповой политикой. Корневой сертификат СА импортируется в GPO, который связан с OU или доменом. При этом все компьютеры, которые подпадают под действие GPO, автоматически устанавливают корневой сертификат в хранилище Trusted Root Certification Authorities.

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

Настройка шаблонов сертификатов
Для Enterprise СА большую роль играют шаблоны сертификатов (certificate templates). Шаблон — это набор настроек, которые определяют содержимое сертификата (срок действия, назначение сертификата, и т.д.), а также разрешения на получение сертификата.
Например, в Windows Server 2003 СА существует встроенный шаблон User, который определяет:

• назначение сертификата (шифрование и электронная подпись для e-mail, шифрование EFS, и клиентская аутентификация);
• срок действия сертификата (1 год);
• разрешения (получить сертификат такого типа может любой пользователь домена).

Также существует множество других шаблонов, наиболее часто используемые из которых приведены в таблице 3.3. Важно отметить, что при использовании СА на основе Windows Server 2003 Standard Edition нельзя создавать собственные шаблоны, но эта возможность есть в Windows Server 2003 Enterprise Edition.
Таблица 3.3. Наиболее часто используемые шаблоны

В Windows Server 2003 Enterprise Edition поддерживается две версии шаблонов — шаблоны версии 1 и шаблоны версии 2. Шаблоны версии 1 — это встроенные шаблоны, параметры которых нельзя изменить. Например, для шаблона User, который является шаблоном версии 1, нельзя изменить длину ключа или срок действия сертификата. Шаблоны версии 2 обеспечивают большую функциональность — можно изменять их  параметры,  настраивать автоматическое развертывание (autoenrollment),  а также обеспечивать автоматическую архивацию ключей (key archival) для последующего восстановления. Сравнительные характеристики шаблонов версий 1 и 2 приведены в таблице 3.4.

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

Создание нового шаблона. Иногда может потребоваться создать новый шаблон, например, шаблон, пригодный для организации автоматического развертывания или архивации ключей. Обычно новый шаблон создается копированием существующего и изменением параметров. Все новые шаблоны — это шаблоны версии 2. Для управления шаблонами используется отдельное административное средство Certificate Templates (Certtmpl.msc). Также можно запустить консоль для управления шаблонами через административное средство Certification Authority.

Изменение разрешений на шаблоны. Чтобы предоставить возможность получить сертификат какой-либо группе пользователей, необходимо назначить разрешение на соответствующий шаблон. Для ручного получения сертификата достаточно разрешений Read и Enroll, для автоматического — Read, Enroll и Autoenroll. Для назначения разрешений используется административное средство Certificate Templates.

Подключение шаблона к центру сертификации. Для того чтобы Центр сертификации мог выдавать сертификаты на основе шаблона, недостаточно лишь назначить разрешения на этот шаблон. Вторым шагом является добавление этого шаблона в список шаблонов, на основе которых центр сертификации будет выдавать сертификаты.
Добавить шаблон к списку разрешенных шаблонов можно с помощью административного средства Certification Authority в разделе Certification Templates. Важно заметить, что команда New certificate to issue, используемая для добавления шаблона, не создает новый шаблон, а всего лишь добавляет шаблон к списку, на основе которого центр сертификации может выдавать сертификаты.

Развертывание сертификатов

В сетях Microsoft поддерживается несколько методов выдачи сертификатов пользователям и компьютерам: получение сертификата через web-интерфейс, запрос сертификата с помощью Мастера, автоматическое развертывание и получение сертификата через агента.
Получение сертификата через web-интерфейс (web-enrollment). Этот метод может применяться для получения компьютерных и пользовательских сертификатов от Enterprise или Stand-alone СА. Чтобы этот метод был доступен, перед установкой на сервер Службы сертификации необходимо сначала установить IIS.
Для получения сертификата клиент должен набрать в строке браузера адрес httр:///certsrv и следовать инструкциям Мастера. Если используется Enterprise СА, то после прохождения Мастера пользователь получает сертификат немедленно, если у него есть соответствующие разрешения на шаблон. В случае Stand-alone СА пользователю требуется обращаться дважды — один раз для отправки запроса на получение сертификата, а второй раз — для установки сертификата (если запрос был успешно подтвержден администратором).

Запрос сертификата с помощью Мастера получения нового сертификата (Request New Certificate wizard) может применяться для получения компьютерных и пользовательских сертификатов от Enterprise СА. Для его использования сначала нужно добавить в консоль ММС оснастку Certificates c нужным
вариантом, а затем запустить Мастер из контекстного меню раздела Personal (All tasks - Request New Certificate).

Автоматическое получение компьютерных сертификатов (Automatic certificate request). Этот метод развертывания применялся в сетях Windows 2000 для автоматической выдачи только компьютерных сертификатов при использовании Enterprise СА. Поддерживается он и в сетях Windows Server 2003, при этом могут быть использованы как шаблоны версии 1, так и шаблоны версии 2. Недостатком этого метода является то, что с его помощью нельзя организовать автоматическую выдачу пользовательских сертификатов.
Для настройки автоматического получения компьютерных сертификатов применяется Групповая политика (Computer Configuration - Windows Settings - Security Settings - Public Key Policies - Automatic Certificate Request Settings).

Автоматическое развертывание (Autoenrollment). С помощью этого метода можно организовать автоматическую выдачу компьютерных и пользовательских сертификатов, если в качестве клиентской операционной системы используется Windows ХР или Windows Server 2003. Для реализации автоматического развертывания требуется наличие Enterprise СА на основе Windows Server 2003 Enterprise Edition, так как требуются шаблоны версии 2. Настройка развертывания состоит из следующих шагов.

• Создание нужного шаблона версии 2 (обычно выполняется копированием существующего шаблона, например, такого как User или Smart Card Logon).
• Назначение разрешений на шаблон. Для выполнения автоматического развертывания необходимо наличие разрешений Read, Enroll и Autoenroll.
• Подключение нового шаблона к центру сертификации. Добавить шаблон к списку разрешенных шаблонов можно с помощью административного средства Certification Authority в разделе Certification Templates.
• Задание настроек автоматического развертывания в групповой политике (User Configuration или Computer Configuration - Windows Settings - Security Settings - Public Key Policies - свойства Autoenrollment Settings). Требуется установить флажки Renew expired certificates, update pending certificates, and remove revoked certificates и Select the Update certificates that use certificate templates.

Получение сертификата через агента (Enrollment Agent). Этот метод применяется для выдачи смарт-карт пользователям. Суть метода состоит в том, что сертификаты для смарт-карт запрашивает не сам пользователь, а специально уполномоченный агент от его имени. После получения пользовательского сертификата агент выполняет запись сертификата на смарт-карту и выдает ее пользователю. Настройка состоит из следующих шагов:

• Назначение соответствующих разрешений на шаблоны Smart Card User, Smart card Logon и Enrollment Agent,
• Подключение этих шаблонов к центру сертификации.
• Установка считывателя смарт-карт на рабочую станцию, которая будет использоваться агентом.
• Получение пользователем, выполняющим роль агента, сертификата на основе шаблона Enrollment Agent. Этот сертификат необходим для создания запросов к СА от имени других пользователей.

После такой настройки агент может запрашивать сертификаты, используя web-интерфейс к центру сертификации (http:///certsrv). Для запроса применяется опция Request a certificate for a smart card on behalf of another user using the smart card certificate enrollment station.

Отзыв сертификатов

Отзыв сертификата заключается в публикации серийного номера сертификата в списке отозванных сертификатов (CRL). Эта процедура состоит из двух шагов — непосредственно отзыва сертификата и публикации CRL.
CLR может быть опубликован по заданному расписанию (каждые 7 дней по умолчанию) или вручную вне расписания. Период автоматической публикации — важный параметр, влияющий на срок действия CRL. Клиенты, однажды загрузив CRL, кэшируют его на срок равный периоду публикации + 10%. Поэтому клиенты, ранее загрузившие CRL, не «увидят» новых отозванных сертификатов, пока CRL в их кэше не будет признан истекшим. Таким образом, ручная внеплановая публикация повлияет только на клиентов, не имеющих у себя в кэше действующей копии CRL.

Резервное копирование и восстановление сертификата и закрытого ключа
Поскольку сертификаты и секретные ключи пользователя обычно хранятся в профиле пользователя, существует риск их потери. Например, если пользователь зашифровал файлы на жестком диске и затем утерял секретный ключ, только Агент восстановления (если он задан) сможет расшифровать файлы. Поэтому должны быть приняты меры для сохранения ключей и сертификатов в резервной копии. Это можно сделать различными способами.
Экспорт сертификата и секретного ключа в файл на стороне клиента. Если секретный ключ допускает экспортирование (это задается в шаблоне или при запросе), можно провести экспорт в формат PKCS #12 (.pfx). В этом формате экспортируется сертификат или вся цепочка сертификатов от корневого сертификата СА и секретный ключ. Секретный ключ защищается паролем к файлу, который необходимо задать при экспорте. Для экспорта и последующего импорта применятся оснастка Certificates, которая добавляется в консоль ММС.
Резервное копирование ключей на стороне СА (Key archival). Эта возможность доступна только при использовании Enterprise СА на основе Windows Server 2003 Enterprise Edition и шаблонов версии 2. Включение автоматического резервирования ключей состоит из следующих шагов.

• Создание учетной записи для Агента восстановления и получение Агентом восстановления сертификата Агента восстановления ключей (Key Recovery Agent certificate)
• Настройка CA на архивирование ключей (настраивается в свойствах СА на закладке Recovery Agents).
• Создание нужного шаблона версии 2 для которого планируется архивирование ключей (обычно выполняется копированием существующего шаблона, например, такого как User или Smart Card Logon), и назначение разрешений на шаблон.
• Задание в свойствах шаблона параметров автоматического резервирования (закладка Request Handling, флажок Archive subject's encryption private key).
• Подключение шаблона к CA. Добавить шаблон к списку разрешенных шаблонов можно с помощью административного средства Certification Authority в разделе Certification Templates.

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

1. • С помощью административного средства Certification Authority записать серийный номер секретного ключа (серийный номер сертификата) для которого предполагается восстановление.
   • Выполнить команду Certutil -getkey serialnumber outputfile
   • Выполнить команду Certutil -recoverkey outputfile resultfile.pfx
   • На компьютере пользователя выполнить импорт .pfx-файла, указав пароль password.