Размещенная в IIS служба SSL WCF - проблема с сертификатом или разрешениями

Прежде чем кто-либо пометит это как дубликат из другой бочки, полной вопросов о WCF, мне не нужны ссылки MSDN и ссылки на статьи в блогах. Я могу использовать Google для себя, и занимаюсь этим уже 3 дня, поэтому, если все, что у вас есть, - это ссылки Google, пожалуйста, воздержитесь.

У меня чертовски много времени с размещенной в IIS службой WCF с использованием wsHttpBinding и настраиваемого аутентификатора пароля. IIS отлично работает с моими стандартными незащищенными службами ASPX и WCF (с использованием wsHttpBinding с режимом безопасности = "None", но для попытки режима безопасности = "Сообщение" или "Транспорт" требуется сертификат SSL в сочетании. Я к делу что я получаю эту ошибку: «Сертификат CN = SignedByCA должен иметь закрытый ключ, способный к обмену ключами. У процесса должны быть права доступа к закрытому ключу».

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

Я сгенерировал ключи, используя:

  makecert -n "CN=TempCA" -r -sv TempCA.pvk TempCA.cer
  makecert -sk SignedByCA -iv TempCA.pvk -n "CN=SignedByCA" -ic TempCA.cer SignedByCA.cer -sr currentuser -ss My

Затем я импортировал сертификат TempCA в хранилище доверенного корневого центра сертификации и импортировал SignedByCA.cer в свое «личное» хранилище локального компьютера. WCF теперь может видеть сертификат, но указанная выше ошибка указывает либо на проблему с разрешениями, либо на ключевую проблему. Я также попытался импортировать сертификат в личный магазин IIS Admin Service, но безуспешно.

Кстати, я добавил это в свой web.config для службы:

       <serviceCertificate
          findValue="...."
          x509FindType="FindByThumbprint"
          storeLocation="LocalMachine"
          storeName="My"
          />

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

Судя по моему исследованию, в Windows 7 я смогу использовать диспетчер сертификатов, щелкнуть правой кнопкой мыши сертификат в оснастке MMC и выбрать «Все задачи» -> «Управление секретным ключом» ... или что-то подобное. Когда я щелкаю сертификат правой кнопкой мыши, я не вижу эту опцию, у меня есть только эти опции в разделе «Все задачи»: [Открыть, запросить сертификат с новым ключом, обновить сертификат с новым ключом, экспортировать ...] Это наводит меня на мысль, что это проблема с сертификатом, а не проблема с приватом.

Заранее спасибо.


person codenheim    schedule 18.02.2010    source источник
comment
Я регенерировал свой сертификат, а также создал файл .spc и файл .pfx (с помощью pvk2pfx.exe) и загрузил файл .pfx в хранилище сертификатов, это открыло возможность управления закрытым ключом, которую я искал ранее. Таким образом, исходная проблема заключалась в слепом следовании инструкциям MSDN для создания файла .cer, который не был настроен для обмена ключами. Теперь я могу добавлять разрешения в IIS. Это привело к появлению новых проблем: поскольку IIS7 в Windows 7 по умолчанию не работает в NETWORK SERVICE, мне пришлось это изменить.   -  person codenheim    schedule 19.02.2010
comment
Большое спасибо за комментарий об изменении службы по умолчанию, в которой работает IIS7. как только я изменил, мои проблемы были исправлены. Очень признателен!   -  person stuartmclark    schedule 07.11.2011


Ответы (1)


После регенерации файла .PFX (сертификат PKCS # 12) http://msdn.microsoft.com/en-us/library/ms867088.aspx (создайте файл .spc с помощью cert2spc.exe и файл .pfx с помощью pvk2pfx.exe) и загрузите файл .pfx в хранилище сертификатов. параметр «Управление закрытым ключом». Первоначальная проблема заключалась в слепом следовании инструкциям MSDN и использовании файла открытого сертификата .CER, который не подходил для обмена ключами. Файл .PFX делает свое дело. Теперь я могу добавить разрешения для пользователей / служб на чтение ключа.

Я также обнаружил, что IIS7 в Windows7 не работал под обычным документированным удостоверением «СЕТЕВАЯ СЛУЖБА» или «ЛОКАЛЬНАЯ СЛУЖБА», а работал под «ApplicationPoolIdentity». Итак, после того, как я сменил идентификатор, эта проблема была решена (еще одно раздражение в том, что WCF сдвинулся с мертвой точки).

person codenheim    schedule 19.02.2010