1.7.Регистрация сертификатов.

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

Существуют два типа регистрации.

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

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

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

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

Обычные запросы сертификатов, посылаемые серверу ЦС через сеть, могут выда­ваться с помощью Web-приложения или электронной почты. Данные запросы обычно форматируются в стандарте шифрования методом открытого ключа (PKCS #10— Public Key Cryptography Standard). Они поддерживаются не только серверами ЦС ком­пании Microsoft, но и большинством других ЦС.

В ответ на запрос сертификата сервер ЦС может либо ответить отказом, либо вер­нуть сертификат. Сервер ЦС может также вернуть сообщение PKCS #7, что является способом возврата сертификата вместе с родительским сертификатом или цепью сер­тификатов, имеющей отношение к данному сертификату. Сообщение PKCS #7 под­писывается сервером ЦС с целью подтверждения его подлинности и того, что оно пришло с запрашиваемого ЦС.

1.8.ПРОВЕРКА ПОДЛИННОСТИ СЕРТИФИКАТА. Чтобы гарантировать подлинность сертификата, его необходимо проверять. Про­верка сертификата требует выполнения многих действий. Клиент должен построить цепь от сертификата конечного компонента (самый нижний уровень) до доверенного самоподписывающегося корневого сертификата. Чтобы построить цепь, клиент снача­ла пытается найти родительский сертификат. В сертификате клиент использует такую информацию, как имя эмитента, которому необходим родительский сертификат, объ­ектное имя которого соответствует имени эмитента. Помимо того, клиент может ис­пользовать поле, называемое Authority Key Identifier (Идентификатор ключа удостовере­ния), которое явно определяет родительские сертификаты. Если у клиента нет серти­фикатов в локальном хранилище, он может использовать другую информацию. В данном случае логика построения цепи может распространяться на сеть, в результате чего происходят попытки поиска родительского сертификата, используя определен­ную сертификатную информацию, например, доступ к информации удостоверения.

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

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