IIS ile aynı sunucudaki SNI ve joker karakterli SSL sertifikaları

IIS ve SSL ile ikinci düzey bir alanın (ör. Domain2.com, domain3.com) altında yaşayan birden çok web sitesi ile birlikte alt alan adlarını (ör. Sub.domain.com) dinlemesi gereken bir web sitesi barındırmak istiyorum.

Alt alan adlarına sahip web sitesi için bir joker karakter sertifikam (* .etkialanı.com) var ve ayrıca diğer siteler (domain2.com ve domain3.com) için de sertifikalarım var.

Böyle bir kurulum aynı IIS'de barındırılabilir mi (önemliyse, bir Azure Cloud Service web rolünde)?

Sorun tam olarak burada titobf açıkladı : teorik olarak bunun için SNI kullanarak bağlamalar, domain2 / 3.com için ana bilgisayar ve daha sonra * .domain.com için * host ile bir catch-all web sitesi gerekir. Ancak pratikte, tüm web sitesi açıksa, bağlamalar nasıl kurulursa kurulsun, domain2 / 3.com'a da tüm talepleri alacaktır (her ne kadar sadece son çare olarak eşleşse de).

Herhangi bir yardım mutluluk duyacağız.

Hâlâ çözülmemiş

Ne yazık ki bunu çözemedim: IIS ile internet (yani temelde bir güvenlik duvarı) arasında oturan ve (SSL el sıkışması gerçekleşmeden önce) gelen istekleri değiştiren bir yazılım oluşturmak gibi sadece son derece karmaşık şekillerde çözülebilir gibi görünüyor. ) izin verir. Yerel bir modülden bile ne olursa olsun, IIS ile mümkün olmadığından oldukça eminim.

Açıklığa kavuşturmak zorundayım: Azure Cloud Services kullanıyoruz, bu nedenle birden fazla IP adresi kullanamayacağımız konusunda başka bir kısıtlamamız var (bkz: http://feedback.azure.com/forums/169386-cloud-services-web-and -çalışan rolü / öneriler / 1259311-multiple-ssl-and-domain-to-one-app ). Sunucunuza birden çok IP'yi işaret edebiliyorsanız, IP'ler için de bağlayıcılar oluşturabileceğiniz için bu sorunla karşılaşmazsınız ve bunlar joker karakterli bağlayıcılarla birlikte çalışır. Daha spesifik olarak, joker site için bir IP'ye ihtiyacınız vardır (ancak şimdi ayrı bir IP'niz olduğundan joker ana bilgisayar adı bağlayıcısını yapılandırmanız gerekmez) ve diğer joker olmayanlar için başka bir IP.

Aslında geçici çözümümüz, standart olmayan bir SSL bağlantı noktası olan 8443'ün kullanılmasıydı. Bu nedenle SNI bağlaması aslında bu bağlantı noktasına bağlıdır, bu nedenle diğer bağlantılarla birlikte çalışır. Hoş değil, ancak web rolleri için birden fazla IP kullanabilene kadar bizim için kabul edilebilir bir geçici çözüm.

Şimdi çalışmayan bağlamalar

İlk https bağlaması basit bir sertifikaya sahip SNI, ikincisi bir joker karakter sertifikası olan SNI değil.

Http sitesi yanı sıra SNI https sitesi çalışır, ancak joker karakterli bağlayıcı bir "HTTP Hatası 503 verir. Hizmet kullanılamıyor." (daha fazla bilgi olmadan, Başarısız İstek İzleme veya Olay Günlüğü girişi yok).

Sonunda temelde çalışıyor

Tobias'ın tanımladığı gibi ETW izleme günlüğünün etkinleştirilmesi, kök hatasının aşağıdaki gibi olduğunu gösterdi:

İstek (istek kimliği 0xF500000080000008) şu nedenle reddedildi: UrlGroupLookupFailed.

Bildiğim kadarıyla bu http.sys isteği kullanılabilir herhangi bir uç noktaya yönlendirmek mümkün olmadığı anlamına gelir.

Kayıtlı uç noktaların kontrol edilmesi, netsh http show urlacl443 numaralı bağlantı noktasına kaydedilmiş bir şeyin olduğunu gösterdi:

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

Bu Çıkarma netsh http delete urlacl url=https://IP:443/sonunda benim SSL bağlama etkin.

Barış haklı! IP: PORT bağlamasında yapılandırılan SSL sertifikası (örnek: 100.74.156.187:443) http.sys'de her zaman önceliklidir! Böylece çözüm aşağıdaki gibidir:

Joker karakter yedek sertifikanız için bir IP: 443 bağlaması yapılandırmayın, ancak bunun için bir *: 443 bağlaması (* "Tümü Atanmadı" anlamına gelir) yapılandırın .

Azure Cloud Service SSL uç noktasında joker sertifikanızı yapılandırdıysanız (benim gibi) Azure Cloud Service Çalışma Zamanı Modülü (IISconfigurator.exe) tarafından oluşturulan SSL bağlamasını IP: PORT yerine *: PORT olarak değiştirmeniz gerekir. Web rolüm OnStart aşağıdaki yöntemi çağırıyorum :

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());
        }
    }
}

Aşağıdaki ekran görüntüsü bulut hizmetimizin çalışan bir yapılandırmasını göstermektedir. Lütfen standart dışı bağlantı noktaları hakkında karıştırmayın. Ekran görüntüsü taklit bulut hizmetinden.

Bahsedilmesi gereken başka bir şey: HTTP (port 80) bağlaması, konuşlandırılan bulut hizmetinde yalnızca IP: PORT bağlamasıyla çalıştığı için tüm bağlamaları * olarak değiştirmeyin . Başka bir şey IP: 80'e bağlanır, bu nedenle *: 80 çalışmaz, çünkü * "tüm atanmamışlar" anlamına gelir ve IP zaten http.sys'de başka bir yere atanmıştır.

Tümünü yakalama bağlantınızın IP: Port türünde olmadığından emin olun. SNI gerekli değilken HTTPS bağlaması için bir IP: Bağlantı Noktası bağlaması mevcut olduğunda, bu bağlamanın her zaman önceliği olacaktır. Tümünü yakalama durumunuz için bir *: Port bağlama (* atanmamış olanıdır) kullanın.

IIS, SNI'yi destekliyor, ancak portal aracılığıyla yapılandırmaya erişemeseniz de, masmavi bulut hizmeti web rollerinde bile ve dağıtımdan sonra kutuda yaparsanız, bir sonraki dağıtımınızla silinecektir. Çözüm yapılandırmayı otomatikleştirmektir. Ayrıntılar için buraya bir göz atın:

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