Работа с сертификатами
Для программирования безопасности Windows Communication Foundation (WCF) обычно используются цифровые сертификаты X.509, с помощью которых выполняется проверка подлинности клиентов и серверов, шифрование и создание цифровой подписи для сообщений. В этом разделе содержится краткое описание возможностей для работы с цифровыми сертификатами X.509 и порядка использования этих возможностей в WCF. Кроме того, этот раздел включает ссылки на другие разделы с более подробным объяснением основных понятий и порядка выполнения общих задач с использованием WCF и сертификатов.
Вкратце, цифровой сертификат является частью инфраструктуры открытых ключей (PKI), представляющей собой систему цифровых сертификатов, центров сертификации и других центров регистрации, которые используются для проверки подлинности каждой стороны, участвующей в электронной транзакции, посредством использования шифрования с открытым ключом. Сертификаты выдаются центрами сертификации, и каждый сертификат имеет набор полей, в которых содержатся такие данные, как субъект (сущность, которой выдается сертификат), срок действия (период времени, в течение которого сертификат является действительным), издатель (лицо, выдавшее сертификат) и открытый ключ. В WCF каждое из этих свойств обрабатывается как утверждение Claim, и каждое утверждение затем подразделяется на два типа: удостоверение и право. Дополнительные сведения о сертификатах X.509 см. в разделе Сертификаты открытого ключа X.509. Дополнительные сведения об утверждениях и авторизации в WCF см. в разделе Управление утверждениями и авторизацией с помощью модели удостоверения. Дополнительные сведения о реализации PKI см. в разделе "Корпоративный PKI" со службами сертификатов Active Directory Windows Server 2012 R2.
Основной функцией сертификата является удостоверение подлинности владельца сертификата для других сторон. В сертификате содержится открытый ключ владельца, в то время как закрытый ключ хранится у владельца. Открытый ключ можно использовать для зашифровывания сообщений, передаваемых владельцу сертификата. Доступ к закрытому ключу имеет только владелец сертификата, поэтому только он может расшифровать эти сообщения.
Сертификаты должны выдаваться центром сертификации, который обычно является сторонним издателем сертификатов. Домен Windows содержит центр сертификации, который можно использовать для выдачи сертификатов компьютерам домена.
Просмотр сертификатов
При работе с сертификатами зачастую необходимо просматривать их и проверять определенные свойства. Это легко выполняется с помощью консоли управления (MMC). Дополнительные сведения см. в разделе Практическое руководство. Просмотр сертификатов с помощью оснастки MMC.
Хранилища сертификатов
Сертификаты хранятся в хранилищах. Существует два основных хранилища, которые подразделяются на вложенные хранилища. Администратор компьютера может просматривать оба основных хранилища с помощью средства MMC. Пользователи, не являющиеся администраторами, могут просматривать только хранилище текущего пользователя.
Хранилище локального компьютера. Это содержит сертификаты, к которым обращаются процессы компьютера, такие как ASP.NET. Это расположение используется для хранения сертификатов, удостоверяющих подлинность сервера для клиентов.
Хранилище текущего пользователя. Интерактивные приложения обычно помещают сертификаты в это хранилище для текущего пользователя компьютера. В случае клиентского приложения в это хранилище обычно помещаются сертификаты, используемые для проверки подлинности пользователя при подключении к службе.
Эти два хранилища подразделяются на вложенные хранилища. Ниже представлены наиболее важные вложенные хранилища, используемые при программировании с помощью WCF.
Доверенные корневые центры сертификации. Сертификаты из этого хранилища можно использовать для создания цепочки сертификатов, которую можно проследить до сертификата центра сертификации в этом хранилище.
Внимание
Локальный компьютер полностью доверяет любому сертификату, помещенному в это хранилище, даже если он поступил не из доверенного стороннего центра сертификации. Поэтому в данное хранилище не следует помещать сертификаты, к издателям которых нет полного доверия, или если последствия не до конца ясны.
Личное. Это хранилище используется для хранения сертификатов, связанных с пользователем компьютера. Обычно в этом хранилище хранятся сертификаты, выданные одним из центров сертификации, сертификаты которых находятся в хранилище «Доверенные корневые центры сертификации». С другой стороны, сертификат, находящийся в этом хранилище, может быть самостоятельно выданным, и ему будет доверять приложение.
Дополнительные сведения о хранилищах сертификатов см. в разделе Хранилища сертификатов.
Выбор магазина
Выбор расположения для хранения сертификата зависит от режима и места выполнения клиента или службы. Действуют следующие общие правила.
Если служба WCF размещается в службе Windows, используйте хранилище локального компьютера. Обратите внимание, что для установки сертификатов в хранилище локального компьютера требуются привилегии администратора.
Если служба или клиент является приложением, выполняющимся от имени учетной записи пользователя, используйте хранилище текущего пользователя.
Доступ к хранилищам
Хранилища защищаются с помощью списков управления доступом (ACL) аналогично папкам на компьютере. При создании службы, размещенной службы IIS (IIS), процесс ASP.NET выполняется в учетной записи ASP.NET. Эта учетная запись должна иметь доступ к хранилищу, в котором содержатся используемые службой сертификаты. Каждое основное хранилище защищается с помощью списка управления доступом по умолчанию, однако списки можно изменять. При создании отдельной роли для доступа к хранилищу необходимо предоставить ей разрешение на доступ. Сведения о том, как изменить список доступа с помощью средства WinHttpCertConfig.exe, см. в разделе Практическое руководство. Создание временных сертификатов для использования во время разработки.
Цепочки доверия и центров сертификации
Сертификаты создаются в иерархии, где каждый отдельный сертификат связан с выдавшим его органом сертификации. Эта ссылка указывает на сертификат органа сертификации. Затем сертификат ЦС связывается с ЦС, выдавшего исходный сертификат ЦС. Процесс повторяется до тех пор, пока не будет достигнут корневой сертификат органа сертификации. Сертификат корневого органа сертификации является изначально доверенным.
Цифровые сертификаты используются для удостоверения подлинности сущности на основе этой иерархии, которая также называется цепочкой сертификатов. Вы можете просмотреть цепочку любого сертификата с помощью оснастки MMC, дважды щелкнув любой сертификат, а затем щелкнув вкладку "Путь к сертификату". Дополнительные сведения об импорте цепочек сертификатов для центра сертификации см. в разделе "Практическое руководство. Указание цепочки сертификатов центра сертификации, используемой для проверки подписей".
Примечание.
Любой издатель может быть сделан доверенным корневым центром; для этого необходимо поместить сертификат издателя в хранилище сертификатов доверенных корневых центров.
Отключение доверия цепочки
При создании новой службы пользователь может использовать сертификат, который был выдан центром сертификации, отличным от доверенного, или сертификат издателя может отсутствовать в хранилище «Доверенные корневые центры сертификации». Предусмотрена возможность временного отключения механизма, проверяющего цепочку сертификатов для заданного сертификата; эта возможность должна использоваться только в процессе разработки. Чтобы отключить данный механизм, задайте для свойства CertificateValidationMode значение PeerTrust или PeerOrChainTrust. Эти режимы определяют, что сертификат может быть либо самостоятельно выданным (доверие одноранговой группы), либо являться частью цепочки доверия. Указанное свойство можно задать для любого из следующих классов.
Свойство также можно задать с использованием конфигурации. Для задания режима проверки используются следующие элементы.
Нестандартная проверка подлинности
Свойство CertificateValidationMode также позволяет настроить способ проверки сертификатов. По умолчанию задано значение ChainTrust. Чтобы использовать значение Custom, необходимо также установить атрибут CustomCertificateValidatorType для сборки и типа, которые используются при проверке сертификата. Для создания пользовательского проверяющего элемента управления необходимо наследование от абстрактного класса X509CertificateValidator.
При создании пользовательской структуры проверки подлинности наиболее важным методом, который необходимо переопределить, является метод Validate. Образец создания пользовательской структуры проверки подлинности см. в разделе Проверяющий элемент управления для сертификатов X.509. Дополнительные сведения см. в разделе Пользовательские учетные данные и проверка учетных данных.
Использование командлета PowerShell New-SelfSignedCertificate для создания цепочки сертификатов
Командлет PowerShell New-SelfSignedCertificate создает сертификаты X.509 и пары закрытых ключей и открытых ключей. Закрытый ключ можно сохранить на диск, а затем использовать его для выдачи и подписи новых сертификатов, что позволяет имитировать иерархию цепочки сертификатов. Командлет предназначен только для использования в качестве помощи при разработке служб и никогда не должен использоваться для создания сертификатов для фактического развертывания. При разработке службы WCF выполните следующие действия, чтобы создать цепочку доверия с помощью командлета New-SelfSignedCertificate.
Создайте временный корневой сертификат (самозаверяющий) с помощью командлета New-SelfSignedCertificate. Сохраните закрытый ключ на диск.
Воспользуйтесь новым сертификатом для выдачи другого сертификата, содержащего открытый ключ.
Импортируйте сертификат корневого центра в хранилище «Доверенные корневые центры сертификации».
Подробные инструкции см. в разделе Практическое руководство. Создание временных сертификатов для использования во время разработки.
Какой сертификат следует использовать?
Наиболее распространенными вопросами о сертификатах являются следующие: какой сертификат использовать и почему? Ответ зависит от того, что программирует пользователь - клиент или службу. Ниже представлены общие рекомендации; следует иметь виду, что они не являются исчерпывающими ответами на поставленные вопросы.
Сертификаты службы
Основной задачей сертификатов служб является удостоверение подлинности сервера для клиентов. При проверке подлинности сервера клиентом одной из исходных проверок является сравнение значения поля Субъект с универсальным кодом ресурса (URI), используемым для обращения к службе: DNS-имена должны совпадать. Например, если универсальный код ресурса (URI) службы являетсяhttp://www.contoso.com/endpoint/, поле Subject также должно содержать значениеwww.contoso.com.
Обратите внимание, что в этом поле может содержаться несколько значений с отдельными префиксами. Чаще всего инициализация — "CN" для общего имени, например CN = www.contoso.com. Кроме того, поле Субъект может быть пустым; в этом случае в поле Альтернативное имя субъекта может содержаться значение DNS-имя.
Также обратите внимание, что поле Назначения сертификата должно включать соответствующее значение, например "Проверка подлинности сервера" или "Проверка подлинности клиента".
Сертификаты клиентов
Сертификаты клиентов, как правило, выдаются не сторонними центрами сертификации. В хранилище «Личное» текущего пользователя обычно содержатся сертификаты, выданные корневым центром; в поле «Назначения» этих сертификатов задано значение «Проверка подлинности клиента». Клиент может использовать такой сертификат, когда требуется взаимная проверка подлинности.
Отзыв в Сети и автономная отмена
Срок действия сертификата
Каждый сертификат действителен только в течение заданного периода времени, который называется сроком действия. Срок действия определяется значениями полей Действителен с и Действителен по сертификата X.509. Во время проверки подлинности проверяется, не истек ли срок действия сертификата.
Список отзыва сертификатов
Центр сертификации может отменить действующий сертификат в любой момент. Это может произойти по многим причинам, например при компрометации закрытого ключа сертификата.
В этом случае все цепочки, происходящие от отозванного сертификата, также становятся недействительными и механизмы проверки подлинности перестают им доверять. Для обозначения отозванных сертификатов каждый издатель публикует список отзыва сертификатов, имеющий отметку даты и времени. Этот список можно проверить с помощью режима с подключением к сети или автономного режима, задав одно из значений перечисления RevocationMode для свойства DefaultRevocationMode или X509RevocationMode следующих классов: X509ClientCertificateAuthentication, X509PeerCertificateAuthentication, X509ServiceCertificateAuthentication и IssuedTokenServiceCredential. Значение по умолчанию для всех свойств - Online.
Вы также можете задать режим конфигурации с помощью revocationMode атрибута <проверки подлинности (<serviceBehaviors) и< проверки подлинности>> (<конечных точекBehaviors).>>
Метод SetCertificate
В WCF часто требуется задать сертификат или набор сертификатов, который служба или клиент будут использовать для проверки подлинности, шифрования или подписи сообщения. Это можно сделать программно с помощью метода SetCertificate различных классов, представляющих сертификаты X.509. Следующие классы используют метод SetCertificate для задания сертификата.
Метод SetCertificate позволяет задать хранилище и его расположение, тип поиска (параметр x509FindType), определяющий поле сертификата, и значение, которое требуется найти в данном поле. Например, следующий код создает экземпляр ServiceHost и задает сертификат службы, используемый с целью удостоверения подлинности службы для клиентов, с помощью метода SetCertificate.
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");
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")
Несколько сертификатов с одинаковым значением
В хранилище может содержаться несколько сертификатов с одним и тем же именем субъекта. Поэтому если для параметра x509FindType задано значение FindBySubjectName или FindBySubjectDistinguishedName и существует несколько сертификатов с таким значением, возникает исключение, поскольку в этом случае невозможно определить, какой именно сертификат требуется использовать. Это можно подавить, задав для параметра x509FindType значение FindByThumbprint. В поле отпечатка содержится уникальное значение, которое можно использовать для поиска конкретного сертификата в хранилище. Однако у данного подхода есть свой недостаток: если сертификат был отозван или обновлен, метод SetCertificate выполнить не удастся, поскольку исходный отпечаток на будет найден. А если сертификат является недействительным, проверка подлинности не будет пройдена. Это можно подавить, задав для параметра x590FindType значение FindByIssuerName и указав имя издателя. Если указывать издателя не требуется, можно также задать одно из значений перечисления X509FindType, например FindByTimeValid.
Сертификаты в конфигурации
Сертификаты также можно задать с использованием конфигурации. Если вы создаете службу, учетные данные, включая сертификаты, указываются в serviceBehaviors>.< При программировании клиента сертификаты указываются в конечной <точкеBehaviors>.
Сопоставление сертификата с учетной записью пользователя
Службы IIS и Active Directory предусматривают возможность сопоставления сертификата с учетной пользовательской записью Windows. Дополнительные сведения об этой возможности см. в разделе Сопоставление сертификатов с учетными записями пользователей.
Дополнительные сведения о сопоставлении Active Directory см. в разделе Сопоставление сертификатов клиентов с помощью функции сопоставления службы каталогов.
Если эта функция включена, можно задать для свойства MapClientCertificateToWindowsAccount класса X509ClientCertificateAuthentication значение true. В конфигурации можно задать mapClientCertificateToWindowsAccount для атрибута <элемента 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 не удовлетворяет требованиям политики домена.