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

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

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

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

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

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

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

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

Ответы

Ответ 1

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

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

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

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

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

Ответ 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 не будет хранить тот же пароль, что и pvk, и X509Certificate2() завершится с ошибкой.

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

        var assembly = typeof(Certificate).Assembly;
        using (var stream = assembly.GetManifestResourceStream("MyCompany.Identity.Website.Config.idsrv3test.pfx"))
        {
            return new X509Certificate2(ReadStream(stream), "idsrv3test");
        }

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

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