Работа с сертификатами
Для программирования безопасности Windows Communication Foundation (WCF) обычно используются цифровые сертификаты X.509, с помощью которых выполняется проверка подлинности клиентов и серверов, шифрование, а сообщения подписываются цифровой подписью. В этом разделе содержится краткое описание функций для работы с цифровыми сертификатами X.509 и порядка использования этих функций в WCF. Кроме того, этот раздел включает ссылки на другие разделы с более подробным объяснением основных понятий и порядка выполнения общих задач с использованием WCF и сертификатов.
Вкратце, цифровой сертификат является частью инфраструктуры открытых ключей (PKI), представляющей собой систему цифровых сертификатов, центров сертификации и других центров регистрации, которые используются для проверки подлинности каждой стороны, участвующей в электронной транзакции, посредством использования асимметричного шифрования. Сертификаты выдаются центрами сертификации, и каждый сертификат имеет набор полей, в которых содержатся такие данные, как субъект (сущность, которой выдается сертификат), срок действия (период времени, в течение которого сертификат является действительным), издатель (лицо, выдавшее сертификат) и открытый ключ. В WCF каждое из этих свойств обрабатывается как утверждение Claim, и каждое утверждение затем подразделяется на два типа: удостоверение и право. Дополнительные сведения сертификатах X.509 см. в разделе Сертификаты открытого ключа X.509. Дополнительные сведения утверждениях и авторизации в WCF см. в разделе Управление утверждениями и авторизацией с помощью модели удостоверения. Дополнительные сведения реализации PKI см. в разделе Windows Server 2008 R2 ― службы сертификации.
Основной функцией сертификата является удостоверение подлинности владельца сертификата для других сторон. В сертификате содержится открытый ключ владельца, в то время как закрытый ключ хранится у владельца. Открытый ключ можно использовать для зашифровывания сообщений, передаваемых владельцу сертификата. Доступ к закрытому ключу имеет только владелец сертификата, поэтому только он может расшифровать эти сообщения.
Сертификаты должны выдаваться центром сертификации, который обычно является сторонним издателем сертификатов. Домен Windows включает центр сертификации, который можно использовать для выдачи сертификатов компьютерам домена.
Просмотр сертификатов
При работе с сертификатами зачастую необходимо просматривать их и проверять определенные свойства. Это легко выполняется с помощью консоли управления (MMC). Дополнительные сведения см. в разделе Как просматривать сертификаты с помощью оснастки консоли MMC.
Хранилища сертификатов
Сертификаты хранятся в хранилищах. Существует два основных хранилища, которые подразделяются на вложенные хранилища. Администратор компьютера может просматривать оба основных хранилища с помощью средства MMC. Пользователи, не являющиеся администраторами, могут просматривать только хранилище текущего пользователя.
Хранилище локального компьютера. Содержит сертификаты, доступ к которым осуществляется выполняющимися на компьютере процессами, такими как ASP.NET. Это расположение используется для хранения сертификатов, удостоверяющих подлинность сервера для клиентов.
Хранилище текущего пользователя. Интерактивные приложения обычно помещают сертификаты в это хранилище для текущего пользователя компьютера. В случае клиентского приложения в это хранилище обычно помещаются сертификаты, используемые для проверки подлинности пользователя при подключении к службе.
Эти два хранилища подразделяются на вложенные хранилища. Ниже представлены наиболее важные вложенные хранилища, используемые при программировании с WCF.
Доверенные корневые центры сертификации. Сертификаты из этого хранилища можно использовать для создания цепочки сертификатов, которую можно проследить до сертификата центра сертификации в этом хранилище.
.gif "ms731899.Important(ru-ru,VS.100).gif")
ПримечаниеЛокальный компьютер полностью доверяет любому сертификату, помещенному в это хранилище, даже если он поступил не из доверенного стороннего центра сертификации. Поэтому в данное хранилище не следует помещать сертификаты, к издателям которых нет полного доверия, или если последствия не до конца ясны. Личное Это хранилище используется для хранения сертификатов, связанных с пользователем компьютера. Обычно в этом хранилище хранятся сертификаты, выданные одним из центров сертификации, сертификаты которых находятся в хранилище «Доверенные корневые центры сертификации». С другой стороны, сертификат, находящийся в этом хранилище, может быть самостоятельно выданным, и ему будет доверять приложение.
Дополнительные сведения хранилищах сертификатов см. в разделе Хранилища сертификатов.
Выбор хранилища
Выбор расположения для хранения сертификата зависит от режима и места выполнения клиента или службы. Действуют следующие общие правила.
Если служба WCF в службе Windows, используйте хранилище локального компьютера. Обратите внимание, что для установки сертификатов в хранилище локального компьютера требуются привилегии администратора.
Если служба или клиент является приложением, выполняющимся от имени учетной записи пользователя, используйте хранилище текущего пользователя.
Доступ к хранилищам
Хранилища защищаются с помощью списков управления доступом (ACL) аналогично папкам на компьютере. При создании службы, размещаемой в IIS, процесс ASP.NET выполняется от имени учетной записи ASP.NET. Эта учетная запись должна иметь доступ к хранилищу, в котором содержатся используемые службой сертификаты. Каждое основное хранилище защищается с помощью списка управления доступом по умолчанию, однако списки можно изменять. При создании отдельной роли для доступа к хранилищу необходимо предоставить ей разрешение на доступ. Сведения об изменении списков управления доступом с помощью средства WinHttpCertConfig.exe см. в разделе Как создать временные сертификаты для использования во время разработки. Дополнительные сведения применении сертификатов клиентов с IIS см. в разделе Вызов веб-службы с помощью сертификата клиента для проверки подлинности в веб-приложении ASP.NET.
Цепочка доверия и центры сертификации
Сертификаты создаются в иерархии, где каждый отдельный сертификат связан с выдавшим его органом сертификации. Эта ссылка указывает на сертификат органа сертификации. Далее сертификат органа сертификации связан с органом сертификации, выдавшим исходный сертификат. Процесс повторяется до тех пор, пока не будет достигнут корневой сертификат органа сертификации. Сертификат корневого органа сертификации является изначально доверенным.
Цифровые сертификаты используются для удостоверения подлинности сущности на основе этой иерархии, которая также называется цепочкой сертификатов. Цепочку любого сертификата можно просмотреть с помощью оснастки MMC, дважды щелкнув сертификат и выбрав вкладку Путь сертификата. Дополнительные сведения импорте цепочек сертификатов для органа сертификации см. в разделе Как указать цепочку сертификатов центра сертификации, используемую для проверки сигнатур (WCF).
.gif "ms731899.note(ru-ru,VS.100).gif") Примечание |
|---|
| Любой издатель может быть сделан доверенным корневым центром; для этого необходимо поместить сертификат издателя в хранилище сертификатов доверенных корневых центров. |
Отключение механизма проверки цепочки доверия
При создании новой службы пользователь может использовать сертификат, который был выдан центром сертификации, отличным от доверенного, или сертификат издателя может отсутствовать в хранилище «Доверенные корневые центры сертификации». Предусмотрена возможность временного отключения механизма, проверяющего цепочку сертификатов для заданного сертификата; эта возможность должна использоваться только в процессе разработки. Чтобы отключить данный механизм, задайте для свойства CertificateValidationMode значение PeerTrust или PeerOrChainTrust. Эти режимы определяют, что сертификат может быть либо самостоятельно выданным (доверие одноранговой группы), либо являться частью цепочки доверия. Указанное свойство можно задать для любого из следующих классов.
Свойство также можно задать с использованием конфигурации. Для задания режима проверки используются следующие элементы.
Пользовательская проверка подлинности
Свойство CertificateValidationMode также позволяет настроить способ проверки сертификатов. По умолчанию задано значение ChainTrust. Чтобы использовать значение Custom, необходимо также установить атрибут CustomCertificateValidatorType для сборки и типа, которые используются при проверке сертификата. Для создания пользовательского проверяющего элемента управления необходимо наследование от абстрактного класса X509CertificateValidator.
При создании пользовательской структуры проверки подлинности наиболее важным методом, который необходимо переопределить, является метод Validate. Образец создания пользовательской структуры проверки подлинности см. в разделе Проверяющий элемент управления для сертификатов X.509. Дополнительные сведения см. в разделе Пользовательские учетные данные и проверка учетных данных.
Использование программы Makecert.exe для создания цепочки сертификатов
Средство создания сертификатов (Makecert.exe) позволяет создавать сертификаты X.509, а также пары открытого и закрытого ключей. Закрытый ключ можно сохранить на диск, а затем использовать его для выдачи и подписи новых сертификатов, что позволяет имитировать иерархию цепочки сертификатов. Данное средство предназначено для использования только в качестве вспомогательного инструмента при разработке служб; его не следует использовать с целью создания сертификатов для фактического развертывания. При разработке службы WCF, используйте следующую процедуру для создания цепочки доверия с помощью программы Makecert.exe.
Создание цепочки доверия с помощью программы Makecert.exe
Создайте временный сертификат корневого центра (самозаверяющий) с помощью программы MakeCert.exe. Сохраните закрытый ключ на диск.
Воспользуйтесь новым сертификатом для выдачи другого сертификата, содержащего открытый ключ.
Импортируйте сертификат корневого центра в хранилище «Доверенные корневые центры сертификации».
Пошаговые инструкции см. в разделе Как создать временные сертификаты для использования во время разработки.
Выбор сертификата для использования
Наиболее распространенными вопросами о сертификатах являются следующие: какой сертификат использовать и почему? Ответ зависит от того, что программирует пользователь — клиент или службу. Ниже представлены общие рекомендации; следует иметь виду, что они не являются исчерпывающими ответами на поставленные вопросы.
Сертификаты служб
Основной задачей сертификатов служб является удостоверение подлинности сервера для клиентов. При проверке подлинности сервера клиентом одной из исходных проверок является сравнение значения поля Субъект с универсальным кодом ресурса (URI), используемым для обращения к службе: DNS-имена должны совпадать. Например, если универсальным кодом ресурса службы является «https://www.contoso.com/endpoint/», в поле Субъект должно также содержаться значение «www.contoso.com».
Обратите внимание, что в этом поле может содержаться несколько значений с отдельными префиксами. Чаще всего префикс "CN" используется для указания общего имени, например, "CN = www.contoso.com". Кроме того, поле Субъект может быть пустым; в этом случае в поле Альтернативное имя субъекта может содержаться значение поля DNS-имя.
Также обратите внимание, что поле Назначения сертификата должно включать соответствующее значение, например «Проверка подлинности сервера» или «Проверка подлинности клиента».
Сертификаты клиентов
Сертификаты клиентов, как правило, выдаются не сторонними центрами сертификации. В хранилище «Личное» текущего пользователя обычно содержатся сертификаты, выданные корневым центром; в поле «Назначения» этих сертификатов задано значение «Проверка подлинности клиента». Клиент может использовать такой сертификат, когда требуется взаимная проверка подлинности.
Проверка отзыва сертификатов в режиме подключения к сети и автономном режиме
Срок действия сертификата
Каждый сертификат действителен только в течение заданного периода времени, который называется сроком действия. Срок действия определяется значениями полей Действителен с и Действителен по сертификата X.509. Во время проверки подлинности проверяется, не истек ли срок действия сертификата.
Список отзыва сертификатов
Центр сертификации может отозвать действующий сертификат в любой момент. Это может произойти по многим причинам, например при компрометации закрытого ключа сертификата.
В этом случае все цепочки, происходящие от отозванного сертификата, также становятся недействительными и механизмы проверки подлинности перестают им доверять. Для обозначения отозванных сертификатов каждый издатель публикует список отзыва сертификатов, имеющий отметку даты и времени. Этот список можно проверить с помощью режима с подключением к сети или автономного режима, задав одно из значений перечисления X509RevocationMode для свойства RevocationMode или DefaultRevocationMode следующих классов: X509ClientCertificateAuthentication, X509PeerCertificateAuthentication, X509ServiceCertificateAuthentication и IssuedTokenServiceCredential. Значение по умолчанию для всех свойств — Online.
Режим можно также задать в конфигурации с помощью атрибута revocationMode элементов <authentication> of <clientCertificate> ElementserviceBehaviors section<authentication> of <clientCertificate> Element(endpointBehaviors section) и ().
Метод SetCertificate
В WCF часто требуется задать сертификат или набор сертификатов, который служба или клиент будет использовать для проверки подлинности, шифрования или подписи сообщения. Это можно сделать программно с помощью метода SetCertificate различных классов, представляющих сертификаты X.509. Следующие классы используют метод SetCertificate для задания сертификата.
| Класс | Метод |
|---|---|
Метод SetCertificate позволяет задать хранилище и его расположение, тип поиска (параметр x509FindType), определяющий поле сертификата, и значение, которое требуется найти в данном поле. Например, следующий код создает экземпляр ServiceHost и задает сертификат службы, используемый с целью удостоверения подлинности службы для клиентов, с помощью метода SetCertificate .
Dim baseAddress As New Uri("http://cohowinery.com/services")
Dim sh As New ServiceHost(GetType(CalculatorService), baseAddress)
sh.Credentials.ServiceCertificate.SetCertificate( _
StoreLocation.LocalMachine, StoreName.My, _
X509FindType.FindBySubjectName, "cohowinery.com")
Uri baseAddress = new Uri("http://cohowinery.com/services");
ServiceHost sh = new ServiceHost(typeof(CalculatorService), baseAddress );
sh.Credentials.ServiceCertificate.SetCertificate(
StoreLocation.LocalMachine, StoreName.My,
X509FindType.FindBySubjectName, "cohowinery.com");
Несколько сертификатов с одинаковыми значениями полей
В хранилище может содержаться несколько сертификатов с одним и тем же именем субъекта. Поэтому если для параметра x509FindType задано значение FindBySubjectName или FindBySubjectDistinguishedName, и существует несколько сертификатов с таким значением, возникает исключение, поскольку в этом случае невозможно определить, какой именно сертификат требуется использовать. Это можно подавить, задав для параметра x509FindType значение FindByThumbprint. В поле отпечатка содержится уникальное значение, которое можно использовать для поиска конкретного сертификата в хранилище. Однако у данного подхода есть свой недостаток: если сертификат был отозван или обновлен, метод SetCertificate выполнить не удастся, поскольку исходный отпечаток на будет найден. А если сертификат является недействительным, проверка подлинности не будет пройдена. Это можно подавить, задав для параметра x590FindType значение FindByIssuerName и указав имя издателя. Если указывать издателя не требуется, можно также задать одно из значений перечисления X509FindType, например FindByTimeValid.
Сертификаты в конфигурации
Сертификаты также можно задать с использованием конфигурации. В случае создания службы учетные данные, включая сертификаты, указываются в разделе serviceBehaviors section. В случае программирования клиента сертификаты указываются в разделе endpointBehaviors section.
Сопоставление сертификата с учетной записью пользователя
В IIS и Active Directory предусмотрена функция сопоставления сертификата с учетной записью Windows. Дополнительные сведения данной функции см. в разделе Сопоставление сертификатов с учетными записями пользователей.
Дополнительные сведения сопоставлении Active Directory см. в разделе Сопоставление сертификатов клиентов с помощью функции сопоставления службы каталогов.
Если эта функция включена, можно задать для свойства MapClientCertificateToWindowsAccount класса X509ClientCertificateAuthentication значение true. В конфигурации можно задать для атрибута mapClientCertificateToWindowsAccount элемента <authentication>true значение , как показано в следующем примере кода.
<serviceBehaviors>
<behavior name="MappingBehavior">
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="None" mapClientCertificateToWindowsAccount="true" />
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
Сопоставление сертификата X.509 с маркером, представляющим учетную запись пользователя Windows, считается повышением привилегий, поскольку после сопоставления маркер Windows может использоваться для получения доступа к защищенным ресурсам. Поэтому перед сопоставлением необходимо проверить, что сертификат X.509 соответствует политике домена. Проверку этого требования обеспечивает пакет безопасности SChannel .
При использовании .NET Framework, версия 3.5 или более поздней версии WCF позволяет убедиться, что сертификат соответствует политике домена перед его сопоставлением с учетной записью Windows.
В первом выпуске WCF сопоставление выполняется без обращения к политике домена. Поэтому более старые приложения, которые работали при использовании первого выпуска, могут не работать, если включено сопоставление и сертификат X.509 не удовлетворяет требованиям политики домена.
См. также
Справочник
System.ServiceModel.Channels
System.ServiceModel.Security
System.ServiceModel
X509FindType