SNI y certificados SSL comodín en el mismo servidor con IIS

12

Me gustaría alojar un sitio web que debería escuchar subdominios (por ejemplo, sub.domain.com) junto con varios sitios web que viven justo debajo de un dominio de segundo nivel (por ejemplo, domain2.com, domain3.com) con IIS y SSL.

Para el sitio web con los subdominios, tengo un certificado comodín (* .dominio.com) y también tengo certificados específicamente para los otros sitios (dominio2.com y dominio3.com).

¿Se puede alojar dicha configuración en el mismo IIS (si eso es importante, en un rol web de Azure Cloud Service)?

El problema es exactamente lo que titobf explicó aquí : teóricamente para esto necesitaríamos enlaces usando SNI, con el host especificado para domain2 / 3.com y luego un sitio web general con * host para * .domain.com. Pero, en la práctica, no importa cómo se configuren los enlaces si el sitio web general está en funcionamiento, también recibirá todas las solicitudes a domain2 / 3.com (aunque supuestamente solo coincide como último recurso).

Cualquier ayuda sería apreciada.

Aún sin resolver

Desafortunadamente, no pude resolver esto: parece resolverse solo de maneras extremadamente complicadas, como crear un software que se encuentra entre IIS e Internet (básicamente un firewall) y modifica las solicitudes entrantes (¡antes de que se realice el protocolo de enlace SSL! ) para permitir el escenario. Estoy bastante seguro de que esto no es posible con IIS, pase lo que pase, ni siquiera desde un módulo nativo.

Tengo que aclarar: usamos Azure Cloud Services, por lo que tenemos una restricción adicional de que no podemos usar varias direcciones IP (consulte: http://feedback.azure.com/forums/169386-cloud-services-web-and -worker-role / sugerencias / 1259311-multiple-ssl-and-domains-to-one-app ). Si puede apuntar varias direcciones IP a su servidor, entonces no tiene este problema, ya que también puede crear enlaces para IP, y estos funcionarán juntos. Más específicamente, necesita una IP para el sitio comodín (pero dado que ahora tiene una IP separada, no tendría que configurar un enlace de nombre de host comodín) y otra IP para todos los demás no comodín.

En realidad, nuestra solución fue el uso de un puerto SSL no estándar, 8443. Por lo tanto, el enlace SNI está realmente vinculado a este puerto, por lo que funciona junto con los otros enlaces. No es agradable, pero es una solución aceptable para nosotros hasta que pueda usar varias IP para roles web.

Los enlaces que no funcionan ahora

El primer enlace https es SNI con un certificado simple, el segundo no es SNI, con un certificado comodín.

El sitio http funciona, al igual que el sitio SNI https, pero el que tiene el enlace comodín muestra un "Error HTTP 503. El servicio no está disponible". (sin más información, sin seguimiento de solicitud fallida o entrada del registro de eventos). Fijaciones

Finalmente conseguir que básicamente funcione

Habilitar el registro de rastreo ETW como describió Tobias mostró que el error raíz fue el siguiente:

Solicitud (ID de solicitud 0xF500000080000008) rechazada por el motivo: UrlGroupLookupFailed.

Según tengo entendido, esto significa que http.sys no puede enrutar la solicitud a ningún punto final disponible.

La comprobación de los puntos finales registrados con netsh http show urlaclmostró que efectivamente había algo registrado para el puerto 443:

Reserved URL            : https://IP:443/
    User: NT AUTHORITY\NETWORK SERVICE
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;NS)

Eliminar esto con netsh http delete urlacl url=https://IP:443/finalmente habilitado mi enlace SSL.

Piedone
fuente
Absolutamente debería poder hacer esto en IIS usando SNI, sin recurrir a múltiples IP o puertos no estándar.
Joe Sniderman
¿Quiere decir que IIS debería soportar esto? Estoy de acuerdo :-).
Piedone
Estoy totalmente de acuerdo contigo, Piedone. Estoy realmente decepcionado de que IIS (o, para ser más precisos, http.sys) NO admita la combinación de un certificado comodín como un certificado SSL predeterminado y varios certificados concretos con SNI como ESPERADO. El problema es bien conocido desde 2012, como puede ver aquí: forums.iis.net/t/1192170.aspx . Acabo de escribir un correo electrónico a Microsoft y espero recibir comentarios pronto.
Tobias J.
Gracias Tobías Vuelva aquí una vez que Microsoft respondió.
Piedone
2
Probablemente http.sys está rechazando la solicitud, por lo que no se registra ninguna solicitud fallida en IIS. Cree un registro de seguimiento ETW http.sys: 1) inicie el registro de seguimiento. ejecutar: logman start httptrace -p Microsoft-Windows-HttpService 0xFFFF -o httptrace.etl -ets2) hacer la solicitud 503 3) detener el registro de seguimiento. ejecutar: logman stop httptrace -ets4) escribir registro de seguimiento en el archivo. ejecutar: tracerpt.exe httptrace.etl -of XML -o httptrace.xml5) verifique el motivo de 503 en el archivo xml y publíquelo aquí.
Tobias J.

Respuestas:

6

Baris tiene razón! El certificado SSL configurado en un enlace IP: PORT (ejemplo: 100.74.156.187:443) siempre tiene prioridad en http.sys! Entonces la solución es la siguiente:

No configure un enlace IP: 443 para su certificado de reserva comodín, pero configure un enlace *: 443 (* significa "Todos sin asignar") para él .

Si ha configurado su certificado comodín en el punto final SSL de Azure Cloud Service (como lo he hecho), debe cambiar el enlace SSL creado por Azure Cloud Service Runtime (IISconfigurator.exe) de IP: PUERTO a *: PUERTO. Llamo al siguiente método en OnStart de mi rol web:

public static void UnbindDefaultSslBindingFromIp()
{
    Trace.TraceInformation(">> IISTenantManager: Unbind default SSL binding from IP");
    using (var serverManager = new Microsoft.Web.Administration.ServerManager())
    {
        try
        {
            var websiteName = string.Format("{0}_Web", Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.CurrentRoleInstance.Id);
            var site = serverManager.Sites[websiteName];
            var defaultSslBinding = site.Bindings.Single(b => b.IsIPPortHostBinding && b.Protocol == "https");
            defaultSslBinding.BindingInformation = string.Format("*:{0}:", defaultSslBinding.EndPoint.Port);
            serverManager.CommitChanges();
        }
        catch (Exception ex)
        {
            Trace.TraceError(ex.ToString());
        }
    }
}

La siguiente captura de pantalla muestra una configuración funcional de nuestro servicio en la nube. No se confunda con los puertos no estándar. La captura de pantalla es del servicio en la nube emulado.

configuración de trabajo de IIS

Una cosa más para mencionar: no cambie todos los enlaces a * porque el enlace HTTP (puerto 80) solo funciona con el enlace IP: PORT en el servicio en la nube implementado. Algo más está vinculado a IP: 80, por lo que *: 80 no funciona porque * significa "todos sin asignar" y la IP ya está asignada en otro lugar en http.sys.

Tobias J.
fuente
Gracias por tu respuesta detallada. Actualicé mi pregunta: como recuerdo ahora, probablemente no utilicé esta configuración porque recibí el mismo error que ahora.
Piedone
4

Asegúrese de que su enlace general no sea del tipo IP: Puerto. Cuando existe un enlace IP: puerto para un enlace HTTPS mientras no se requiere SNI, ese enlace siempre tendrá prioridad. Para su caso general, utilice un *: enlace de puerto (* siendo todos sin asignar).

bariscaglar
fuente
Gracias, pero como puede ver en mi descripción, inicialmente intenté configurar el enlace SNI sin puerto, pero como eso no funcionó, terminé con un enlace de puerto personalizado.
Piedone
Por puerto, supongo que te refieres a la IP. No puede tener un enlace sin un puerto. Inetmgr no lo permitirá. Para los enlaces SNI, puede usar la IP específica o "Todos sin asignar" y el resultado será el mismo. Es el enlace Catch All, para el que tiene un certificado comodín, que debe estar en "Todos sin asignar" y no en una IP específica.
bariscaglar
Me refería a puerto pero quería decir "puerto no estándar". La IP no se especificó, tal como usted dice y todavía no funciona, también vea el enlace de Tobias. Hay dos formas de evitar esta limitación de IIS: use un puerto personalizado o una IP diferente a los otros enlaces: en los servicios en la nube de Azure, este último no está disponible, por lo que hemos optado por un puerto personalizado.
Piedone
¡bariscaglar es el desarrollador de Microsoft (trabajando en IIS) con el que tuve una conversación muy agradable y útil! Thx Baris! Juntos analizamos el comportamiento y llegamos a la conclusión de que el comportamiento descrito es el comportamiento deseado de http.sys. Pero hay una buena solución. Vea mi respuesta para más detalles.
Tobias J.
Solo una nota para cualquiera que lea, recientemente descubrí que si usa Azure Portal para configurar un servicio para Escritorio remoto (o de lo contrario cambia la configuración del certificado) puede causar que se cree automáticamente una IP: enlace de puerto y rompa todo su SNI . No tengo una solución para ese problema en particular. Sucede después de RoleEnvironment.Changed para que no pueda detectarlo en WebRole.cs.
Mike
1

IIS admite SNI, incluso en roles web de servicio en la nube azul, aunque no puede acceder a la configuración a través del portal y si lo hace en la caja después de la implementación, se borrará con su próxima implementación. La solución es automatizar la configuración. Echa un vistazo aquí para más detalles:

http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/

CamW
fuente
Gracias, pero como he explicado, no hay ningún problema con SNI en sí mismo (lo estoy usando), sino cómo funciona la coincidencia de nombres de host comodín en IIS.
Piedone
Este artículo ya no existe, pero aquí está en el Archivo Web: web.archive.org/web/20151020041907/http://www.vic.ms/microsoft/…
Mike