microsoft - porta azure

Orientación sobre Thinktecture IdentityServer v3-certificados

Question

Estoy trabajando en una demostración de Thinktecture IdentityServer v3. La intención es que el servidor de identidad se ejecute como su propio sitio web en Azure Websites.

Habrá otros (más de un) sitios web de Azure que usarán el servidor de identidad para autenticar usuarios.

Basado en el tutorial de inicio (consulte https://github.com/thinktecture/Thinktecture.IdentityServer.v3/wiki/Getting-started ) Tengo esto principalmente funcionando.

Donde estoy teniendo problemas es con los certificados.

Para la demostración, me gustaría crear mi propio certificado, pero no estoy seguro de lo que tengo que hacer. Cualquier orientación sería útil.

Otras preguntas que tengo sobre esto:

1. ¿Se pueden usar certificados autofirmados?
2. En un escenario de producción, ¿serían aceptables los certificados autofirmados o realmente necesitarían ser firmados por una autoridad raíz de confianza?
3. ¿Cómo se instalarían estos certificados en un sitio web de Azure (o puedo cargar desde el disco)?

Answer 1

Ampliando la respuesta de privilegios mínimos, creo que la forma "correcta" es instalarlos en el depósito de confianza de Azure, pero en mi caso los proporcioné desde recursos incrustados como en el ejemplo idsrv3.

Aquí hay algunos detalles que funcionaron para mí. Creando un certificado autofirmado:

        "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

A pesar de los documentos pvk2pfx.exe, encontré que si no se proporciona -po, el pfx no mantendría la misma contraseña que el pvk y X509Certificate2 () fallaría con un problema de contraseña.

El certificado de muestra idsrv3 funcionó bien en azure para mí, utilizando el código de ejemplo idsrv3:

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

Sin embargo, cuando hice mi propio certificado, funcionó bien en las pruebas locales utilizando el código anterior, pero en Azure tuve que agregar algunos indicadores adicionales para que funcione. No estoy necesariamente seguro de las implicaciones de usar estos, pero funcionan, así que eso es un comienzo:

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

Answer 2

Bueno, estrictamente hablando, necesita dos certificados, uno para SSL y otro para firmar, técnicamente podrían ser los mismos, pero no es necesario. También tienen diferentes requisitos.

Para SSL, necesita tener un certificado que se encuentre en la lista de confianza de sus clientes. Normalmente, esto es un certificado de una CA comercial o de una PKI interna.

Para el certificado de firma, puede generar el suyo, por ejemplo, utilizando makecert.

IdSrv es bastante flexible en la carga de certificados: puede recuperarlos de fuentes arbitrarias, generalmente desde el almacén de certificados de Windows (cuando tiene acceso de nivel de administrador al servidor), o desde el sistema de archivos, o desde un recurso incrustado.

Nuestro host de muestra utiliza el enfoque de recursos integrados que funciona bien para Azure WebSites. Para los escenarios de producción, normalmente desea más flexibilidad (por ejemplo, para reiniciar), por lo que buscaría cargarla desde, por ejemplo, almacenamiento de blob.