WCF, проверка подлинности сертификата - распространенные ошибки и запутанные аргументы

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

Я устанавливаю центр сертификации и сертификат на сервере под управлением Windows 2008 R2. Когда я открываю оснастку сертификатов MMC, я выбираю Учетная запись компьютера. Это правильно? Я делаю это, потому что моя служба WCF будет работать в службе Windows и будет работать, даже если ни один пользователь не вошел в систему. Но, по общему признанию, я не знаю, в чем разница между тремя вариантами:

  1. Моя учетная запись пользователя
  2. Сервисный аккаунт
  3. Учетная запись компьютера

После загрузки оснастки я импортирую сертификат центра сертификации в доверенные корневые центры сертификации. Затем я импортирую сертификат в доверенных издателей. Я при этом не сталкиваюсь с ошибками. Когда я выполняю импорт как сертификата органа, так и сертификата, подписанного этим органом, я не делаю никаких ссылок на файл .pvk. Насколько я понимаю, закрытый ключ встроен либо в сертификат, либо в авторитетный сертификат. Вот команды, которые я использую для создания каждого сертификата:

MakeCert.exe
  -n “CN=InternalCA”
  -r
  -sv InternalCA.pvk InternalCA.cer
  -cy authority


MakeCert.exe
  -sk InternalWebService
  -iv InternalCA.pvk
  -n “CN=InternalWebService”
  -ic InternalCA.cer InternalWebService.cer
  -sr localmachine
  -ss root
  -sky exchange
  -pe

Обратите внимание, я использовал -ss root. Я видел много сообщений с использованием -ss My. Я действительно не понимаю, в чем разница и когда уместно использовать каждое значение.

Моя служба WCF работает на этом компьютере внутри управляемой службы (службы Windows). Когда я запускаю свою службу Windows, в которой размещена служба WCF, она сразу дает сбой, и в средстве просмотра событий отображается, казалось бы, общая ошибка:

System.ArgumentException: вполне вероятно, что сертификат CN = TempCertName может не иметь закрытого ключа, способного к обмену ключами, или процесс может не иметь прав доступа к закрытому ключу.

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

Кажется, это популярный ответ здесь, в stackoverflow: Предоставить доступ со всеми задачами / Управление закрытыми ключами

Но у меня нет опции Все задачи / Управление закрытыми ключами.

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

Пожалуйста помоги :)


certificate x509certificate certificate-store wcf-authentication makecert
person essedbl    schedule 15.03.2011    source источник
comment
Я посмотрю, поможет ли это: stackoverflow.com/questions/893336/   -  person essedbl    schedule 15.03.2011

Ответы (2)


arrow_upward
1
arrow_downward

Вот лучшая ссылка, которая поможет вам настроить автономную службу SSL WCF для работы с вашим собственным ЦС / сертификатами: SSL с автономной службой WCF.

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

Я считаю, что проверить мою конфигурацию HTTP.SYS с помощью инструмента HTTPCfgUI проще, чем с помощью команды строка _1 _ / _ 2_ команд.

Затем, если вы по-прежнему сталкиваетесь с ошибками, вы можете продолжить отладку с помощью трассировки WCF. Кроме того, вам также следует включить трассировку сообщений WCF. Вы также можете отслеживать сетевой стек .NET, если не предоставляет достаточно информации.

Вы можете проверить, работает ли ваша пара сертификат / CA в службе, нажав URL-адрес службы в браузере на другом компьютере. Сначала следует указать, что сертификат недействителен. Затем импортируйте ЦС на машине в доверенный корень и снова нажмите URL-адрес службы. На этот раз страница с описанием службы должна отображаться как обычно, без предупреждений.

person Mike Atlas    schedule 16.03.2011

arrow_upward
1
arrow_downward

Думаю, вы близки. Вот несколько предложений:

  1. Убедитесь, что на втором этапе вы получаете закрытый ключ, прикрепленный к вашему сертификату. Вы должны запустить команду в процессе с повышенными правами - даже если у вас есть права администратора, вам нужно, например, щелкнуть правой кнопкой мыши и «Запуск от имени администратора», чтобы запустить командную оболочку, которую вы используете для этой команды. В противном случае вы не получите закрытый ключ в магазине localMachine.

  2. Я бы использовал -ss my и поместил сертификат (с закрытым ключом) в личное хранилище. Вот я вижу следующее:

    cc.ClientCredentials.ClientCertificate.SetCertificate (StoreLocation.CurrentUser, StoreName.My, X509FindType.FindBySubjectName, contoso.com);

и поэтому куда бы вы ни указывали в своем эквиваленте, поместите сертификат туда.

  1. Вам не нужно импортировать закрытый ключ сертификата CA (первого, который вы создали). Это осталось только для подписания дополнительных сертификатов с помощью MakeCert. Вам понадобится копия этого сертификата CA (без закрытого ключа!) На клиенте, который подключается, иначе клиент не сможет проверить сертификат InternalWebService.

  2. Вам действительно не нужен сертификат CA локально на сервере, потому что он будет нужен только клиенту. Но это не повредит и понадобится, если что-либо на сервере подключится к службе локально. Кроме того, это позволяет сертификату InternalWebService хорошо выглядеть в оснастке MMC. Вы можете попробовать с CA и без него в магазине Trusted Root, и вы поймете, что я имею в виду. Но в любом случае я бы не помещал закрытый ключ ЦС в хранилище локального компьютера.

  3. Проверьте разрешения закрытого ключа для InternalWebService из оснастки MMC (щелкните правой кнопкой мыши сертификат, затем Задачи, Управление закрытыми ключами ...). Если вы выполняете импорт под другой учетной записью пользователя, чем служба, под которой работает служба, то она, безусловно, победит. У меня еще нет доступа, и вы должны пойти и дать ему доступ. В противном случае служба получит сертификат, но окажется, что у сертификата нет закрытого ключа.

Обобщить:

  • Запустите с правами администратора, чтобы убедиться, что закрытый ключ InternalWebService действительно попадает в хранилище сертификатов. (Вы увидите небольшой ключ на сертификате в оснастке MMC, и при щелчке правой кнопкой мыши по сертификату появится опция «Управление закрытыми ключами ...», которая отсутствует, если закрытый ключ не прикреплен.)

  • Поместите InternalWebService в то место, где его ищет веб-служба. Я бы предположил "Личный" (он же "мой"), но вы знаете, где это находится в конфигурации вашей службы. Независимо от того, текущий пользователь или локальный компьютер, посмотрите в файле config.

  • Предоставьте доступ к закрытому ключу сертификата InternalWebService.

  • Поместите сертификат CA - без его закрытого ключа - в Trusted Root, и вам также нужно будет поместить его на клиент (или иначе попросите клиента принять "ненадежный сертификат" на своем конец.)

person Jim Flood    schedule 09.04.2011