Руководство по Thinktecture IdentityServer v3 - сертификаты

Question

Я работаю над демонстрацией Thinktecture IdentityServer v3. Цель состоит в том, чтобы сервер идентификации работал как собственный сайт под сайтами Azure.

Будут другие (более одного) веб-сайты Azure, которые будут использовать сервер идентификации для аутентификации пользователей.

Основано на начавшемся пошаговом руководстве (см. https://github.com/thinktecture/Thinktecture.IdentityServer.v3/wiki/Getting-started) У меня есть этот в основном рабочий.

У меня возникли проблемы с сертификатами.

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

Другие вопросы я на это:

1. ли самозаверяющие сертификаты в состоянии использовать?
2. В сценарии производства можно было бы использовать самоподписанные сертификаты или действительно ли они должны были быть подписаны доверенным корневым центром?
3. Как эти сертификаты будут установлены в Azure веб-сайт (или можно загрузить с диска)

Answer 1

Ну - строго говоря, вам нужны два сертификата - один для SSL и один для подписания - технически они могут быть такими же, - но не нужно. У них также есть разные требования.

Для SSL - у вас должен быть сертификат, находящийся в надежном списке ваших клиентов. Обычно это либо сертификат от коммерческого центра сертификации, либо от внутреннего PKI.

Для подписания сертификата - вы можете создать свой собственный - например, используя makecert.

IdSrv довольно гибкий в загрузке сертификатов - вы можете извлекать их из произвольных источников - обычно из хранилища сертификатов Windows (когда у вас есть доступ на уровне администратора к серверу) - или файловой системы, или из встроенного ресурса.

Наш пример хоста использует встроенный ресурсный подход, который отлично работает для Azure WebSites. Для сценариев производства вы обычно нуждаетесь в большей гибкости (например, для перевертывания), поэтому я бы посмотрел на ее загрузку, например. блок памяти.

Answer 2

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

Вот некоторые особенности, которые сработали для меня. Создание собственного подписанного сертификата:

 "C:\Program Files (x86)\Windows Kits\8.1\bin\x64\makecert.exe" -r -pe -n "CN=MyAppIdentity" -sky signature MyApp.cer -sv MyApp.pvk 
     "C:\Program Files (x86)\Windows Kits\8.1\bin\x64\pvk2pfx.exe" -pvk MyApp.pvk -spc MyApp.cer -pfx MyApp.pfx -pi MyPassword -po MyPassword 

Несмотря на pvk2pfx.exe документы, я обнаружил, что если -PO не входит в комплект, то PFX не будет держать один и тот же пароль, что ПВК и X509Certificate2() потерпит неудачу с паролем вопрос.

idsrv3 образец серт работал отлично на лазури для меня, используя код idsrv3 образца:

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

 using (var stream = assembly.GetManifestResourceStream("MyCompany.Identity.Website.Config.MyApp.pfx")) 
     { 
      return new X509Certificate2(ReadStream(stream), 
       "MyPassword", 
       X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable); 
     }