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

Question

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

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

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

После загрузки оснастки я импортирую сертификат авторизации в Сертификат доверенного корняВласти .Затем я импортирую сертификат в Trusted Publishers .Я не сталкиваюсь с ошибками при этом.Когда я выполняю импорт сертификата авторизации и сертификата, подписанного этим полномочным органом, я не делаю никаких ссылок на файл .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: Предоставить доступ со всеми задачами / Управление личными ключами

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

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

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

Answer 1

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

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

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

Подведем итог:

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

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

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

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

Answer 2

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

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

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

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

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