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

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).

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.

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.

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.

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).

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/