Поделиться через

Работа с сертификатами

Для программы безопасности 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 включен центр сертификации, используемый для выдачи сертификатов компьютерам в домене.

Просмотр сертификатов

Для работы с сертификатами часто необходимо просматривать их и проверять их свойства. Это легко сделать с помощью оснастки Microsoft Management Console (MMC). Дополнительные сведения см. в разделе "Практическое руководство. Просмотр сертификатов с помощью оснастки MMC".

Хранилища сертификатов

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

  • Локальное хранилище компьютеров. Это содержит сертификаты, к которым обращаются процессы компьютера, такие как ASP.NET. Используйте это расположение для хранения сертификатов, удостоверяющих сервер перед клиентами.

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

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

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

    Это важно

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

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

Дополнительные сведения о хранилищах сертификатов см. в разделе "Хранилища сертификатов".

Выбор магазина

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

  • Если служба WCF размещена в службе Windows, используйте локальное хранилище компьютеров . Обратите внимание, что для установки сертификатов в локальное хранилище компьютеров требуются права администратора.

  • Если служба или клиент — это приложение, которое выполняется под учетной записью пользователя, используйте текущее хранилище пользователей .

Доступ к магазинам

Хранилища защищены списками управления доступом (ACL), как и папки на компьютере. При создании службы, размещенной службами IIS, процесс ASP.NET выполняется в учетной записи ASP.NET. Эта учетная запись должна иметь доступ к хранилищу, в котором содержатся сертификаты, которые использует служба. Каждый из основных магазинов защищен списком доступа по умолчанию, но их можно изменить. Если вы создаете отдельную роль для доступа к магазину, вы должны предоставить права доступа для этой роли. Чтобы узнать, как изменить список доступа с помощью средства WinHttpCertConfig.exe, см. статью "Практическое руководство. Создание временных сертификатов для использования во время разработки".

Цепочки доверия и центры сертификации

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

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

Замечание

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

Отключить доверие цепочки

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

Класс Недвижимость
X509ClientCertificateAuthentication X509ClientCertificateAuthentication.CertificateValidationMode
X509PeerCertificateAuthentication X509PeerCertificateAuthentication.CertificateValidationMode
X509ServiceCertificateAuthentication X509ServiceCertificateAuthentication.CertificateValidationMode
IssuedTokenServiceCredential IssuedTokenServiceCredential.CertificateValidationMode

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

Настраиваемая проверка подлинности

Это CertificateValidationMode свойство также позволяет настроить проверку подлинности сертификатов. По умолчанию для уровня задано значение ChainTrust. Чтобы использовать значение Custom, необходимо также задать атрибут CustomCertificateValidatorType на сборку и тип, которые используются для проверки сертификата. Чтобы создать пользовательский валидатор, необходимо наследовать от абстрактного X509CertificateValidator класса.

При создании пользовательского средства проверки подлинности наиболее важным методом для переопределения является метод Validate. Для примера специальной проверки подлинности, см. пример проверки сертификата X.509. Дополнительные сведения см. в разделе "Настраиваемые учетные данные" и "Проверка учетных данных".

Использование командлета PowerShell New-SelfSignedCertificate для создания цепочки сертификатов

Командлет PowerShell New-SelfSignedCertificate создает сертификаты X.509 и пары закрытых и открытых ключей. Вы можете сохранить закрытый ключ на диск, а затем использовать его для выдачи и подписывания новых сертификатов, что позволяет имитировать иерархию цепочки сертификатов. Командлет предназначен только для использования в качестве вспомогательного средства при разработке служб и никогда не должен использоваться для создания сертификатов для реального развертывания. При разработке службы WCF выполните следующие действия, чтобы создать цепочку доверия с помощью командлета New-SelfSignedCertificate.

  1. Создайте временный корневой сертификат (самоподписанный) с помощью командлета New-SelfSignedCertificate. Сохраните закрытый ключ на диске.

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

  3. Импортируйте сертификат корневого удостоверяющего центра в хранилище доверенных корневых удостоверяющих центров сертификации.

  4. Пошаговые инструкции см. в разделе "Практическое руководство. Создание временных сертификатов для использования во время разработки".

Какой сертификат следует использовать?

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

Сертификаты службы

Сертификаты службы имеют основную задачу проверки подлинности сервера клиентам. Одна из первоначальных проверок, когда клиент проверяет подлинность сервера, заключается в сравнении значения поля subject с универсальным идентификатором ресурса (URI), используемым для связи со службой: DNS обоих должны совпадать. Например, если универсальный код ресурса (URI) службы является http://www.contoso.com/endpoint/ , поле Subject также должно содержать значение www.contoso.com.

Обратите внимание, что поле может содержать несколько значений, причем каждое значение имеет префикс с инициализацией для указания значения. Чаще всего инициализация — "CN" для общего имени, например CN = www.contoso.com. Поле "Тема " также может быть пустым, в этом случае поле "Альтернативное имя субъекта " может содержать значение DNS-имени .

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

Сертификаты клиентов

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

Онлайн-отзыв и автономный отзыв

Срок действия сертификата

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

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

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

При этом все цепочки, которые нисходят от отозванного сертификата, также недействительны и не являются доверенными во время процедур аутентификации. Чтобы узнать, какие сертификаты отзываются, каждый издатель публикует список отзыва сертификатов с меткой даты и времени (CRL). Список можно проверить с помощью онлайн-отзыва или автономного аннулирования, задав свойство RevocationMode или DefaultRevocationMode следующих классов одному из значений перечисления X509RevocationMode: X509ClientCertificateAuthentication, X509PeerCertificateAuthentication, X509ServiceCertificateAuthentication и IssuedTokenServiceCredential классов. Значением по умолчанию для всех свойств является Online.

Вы также можете задать режим в конфигурации с помощью атрибута revocationMode как для <проверки подлинности> (в <serviceBehaviors>), так и для <проверки подлинности> (в <endpointBehaviors>).

Метод SetCertificate

В WCF часто необходимо указать сертификат или набор сертификатов, используемых службой или клиентом для проверки подлинности, шифрования или цифрового подписывания сообщения. С помощью программного метода SetCertificate различных классов, которые представляют сертификаты X.509, это можно сделать. Следующие классы используют SetCertificate метод для указания сертификата.

Класс Метод
PeerCredential SetCertificate
X509CertificateInitiatorClientCredential SetCertificate
X509CertificateRecipientServiceCredential SetCertificate
X509CertificateInitiatorServiceCredential
SetCertificate

Метод SetCertificate работает путем указания местоположения магазина и самого хранилища, типа "find" (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>. При программировании клиента сертификаты указываются в <endpointBehaviors>.

Сопоставление сертификата с учетной записью пользователя

Функция IIS и Active Directory — это возможность сопоставления сертификата с учетной записью пользователя Windows. Дополнительные сведения о функции см. в разделе "Сопоставление сертификатов с учетными записями пользователей".

Дополнительные сведения об использовании сопоставления Active Directory см. в разделе "Сопоставление сертификатов клиентов" с сопоставлением служб каталогов.

Если эта возможность включена, можно задать значение свойства MapClientCertificateToWindowsAccount класса X509ClientCertificateAuthentication на true. В конфигурации можно задать для атрибута mapClientCertificateToWindowsAccount значение <, как показано в следующем коде.

<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 не удовлетворяет политике домена.

См. также

  • Last updated on