ใบรับรอง SNI และไวด์การ์ดบนเซิร์ฟเวอร์เดียวกันกับ IIS

ฉันต้องการโฮสต์เว็บไซต์ที่ควรฟังโดเมนย่อย (เช่น sub.domain.com) พร้อมกับเว็บไซต์หลายเว็บไซต์ที่อยู่ภายใต้โดเมนระดับที่สอง (เช่น domain2.com, domain3.com) กับ IIS และ SSL

สำหรับเว็บไซต์ที่มีโดเมนย่อยฉันมีใบรับรองตัวแทน (* .domain.com) และฉันยังมีใบรับรองเฉพาะสำหรับไซต์อื่น ๆ (domain2.com และ domain3.com)

การตั้งค่าดังกล่าวสามารถโฮสต์บน IIS เดียวกันได้หรือไม่ (หากมีความสำคัญในบทบาทบนเว็บ Azure Cloud Service)

ปัญหาคือสิ่งที่ titobf อธิบายไว้ที่นี่ : ในทางทฤษฎีสำหรับสิ่งนี้เราจำเป็นต้องทำการเชื่อมโยงโดยใช้ SNI โดยมีโฮสต์ที่ระบุสำหรับ domain2 / 3.com แล้วเว็บไซต์ catch-all ที่มี * host สำหรับ * .domain.com แต่ในทางปฏิบัติไม่ว่าจะมีการตั้งค่าการเชื่อมโยงอย่างไรหากเว็บไซต์ catch-all นั้นอยู่ในนั้นจะได้รับการร้องขอทั้งหมดไปยัง domain2 / 3.com (แม้ว่าจะจับคู่เป็นทางเลือกสุดท้ายเท่านั้น)

ความช่วยเหลือใด ๆ ที่จะได้รับการชื่นชม

ยังไม่ได้แก้

น่าเสียดายที่ฉันไม่สามารถแก้ปัญหานี้ได้: ดูเหมือนว่าจะสามารถแก้ไขได้ด้วยวิธีที่ซับซ้อนมากเท่านั้นเช่นการสร้างซอฟต์แวร์ที่ตั้งอยู่ระหว่าง IIS และอินเทอร์เน็ต (โดยทั่วไปจะเป็นไฟร์วอลล์) และปรับเปลี่ยนคำขอขาเข้า (ก่อน SSL handshake จะเกิดขึ้น! ) เพื่ออนุญาตสถานการณ์ ฉันค่อนข้างมั่นใจว่าเป็นไปไม่ได้กับ IIS ไม่ว่าจะเกิดอะไรขึ้นไม่ได้มาจากโมดูลเนทิฟ

ฉันต้องชี้แจง: เราใช้ Azure Cloud Services ดังนั้นเราจึงมีข้อ จำกัด เพิ่มเติมที่เราไม่สามารถใช้ที่อยู่ IP หลายแห่งได้ (ดู: http://feedback.azure.com/forums/169386-cloud-services-web-and -worker- บทบาท / คำแนะนำ / 1259311-multiple-ssl-and-domains-to-one-app ) หากคุณสามารถชี้ IP หลาย ๆ ตัวไปยังเซิร์ฟเวอร์ของคุณคุณจะไม่มีปัญหานี้เนื่องจากคุณสามารถสร้างการเชื่อมโยงสำหรับ IP ได้ด้วยและสิ่งเหล่านั้นจะทำงานร่วมกันด้วยการเชื่อมโยงสัญลักษณ์แทน โดยเฉพาะคุณต้องมี IP สำหรับเว็บไซต์ไวด์การ์ด (แต่เนื่องจากคุณมี IP แยกตอนนี้คุณไม่จำเป็นต้องกำหนดค่าการเชื่อมโยงชื่อโฮสต์ไวด์การ์ด) และ IP อื่นสำหรับรายการที่ไม่ใช่ไวด์การ์ดอื่น ๆ ทั้งหมด

อันที่จริงวิธีแก้ปัญหาของเราคือการใช้พอร์ต SSL ที่ไม่ได้มาตรฐาน 8443 ดังนั้นการผูก SNI จึงผูกพันกับพอร์ตนี้ดังนั้นจึงทำงานได้พร้อมกับการผูกอื่น ๆ ไม่ดี แต่เป็นวิธีการแก้ปัญหาที่ยอมรับได้สำหรับเราจนกว่าคุณจะสามารถใช้หลาย IP สำหรับบทบาทบนเว็บ

การเชื่อมที่ไม่ทำงานในขณะนี้

การรวม https ครั้งแรกคือ SNI ที่มีใบรับรองแบบง่ายส่วนที่สองไม่ใช่ SNI ที่มีใบรับรองไวด์การ์ด

ไซต์ http ทำงานได้เป็นอย่างดีรวมถึงไซต์ SNI https แต่เว็บไซต์ที่มีการเชื่อมโยงไวด์การ์ดจะให้ "HTTP Error 503 ไม่สามารถใช้บริการได้" (ไม่มีข้อมูลเพิ่มเติมไม่มีการติดตามคำขอที่ล้มเหลวหรือรายการบันทึกเหตุการณ์)

ในที่สุดก็รับมันทำงานโดยทั่วไป

การเปิดใช้งานบันทึกการติดตาม ETW เช่น Tobias อธิบายไว้แสดงให้เห็นว่าข้อผิดพลาดรูตมีดังต่อไปนี้:

คำขอ (คำขอ ID 0xF500000080000008) ถูกปฏิเสธเนื่องจากเหตุผล: UrlGroupLookupFailed

เท่าที่ฉันเข้าใจนี่หมายความว่า http.sys ไม่สามารถกำหนดเส้นทางคำขอไปยังจุดปลายที่มีอยู่ได้

การตรวจสอบจุดสิ้นสุดที่ลงทะเบียนด้วยnetsh http show urlaclแสดงให้เห็นว่ามีบางสิ่งที่ลงทะเบียนไว้สำหรับพอร์ต 443:

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

การลบสิ่งนี้ด้วยการnetsh http delete urlacl url=https://IP:443/เปิดใช้งานการผูก SSL ของฉันในที่สุด

บาริสพูดถูก! ใบรับรอง SSL ที่กำหนดค่าบนการเชื่อมโยง IP: PORT (ตัวอย่าง: 100.74.156.187:443) จะมีความสำคัญใน http.sys เสมอ! ดังนั้นวิธีการแก้ปัญหามีดังนี้:

อย่ากำหนดค่า IP: 443 ผูกพันสัญลักษณ์แทน-สำรองใบรับรองของคุณ แต่กำหนดค่า *: 443 ผูกพัน (* หมายถึง "Unassigned ทั้งหมด") สำหรับมัน

หากคุณกำหนดค่าใบรับรองไวด์การ์ดของคุณบนปลายทาง SSL Azure Cloud Service SSL (เช่นฉัน) คุณต้องเปลี่ยนการเชื่อม SSL ที่สร้างโดย Azure Cloud Service Runtime (IISconfigurator.exe) จาก IP: PORT เป็น *: PORT ฉันกำลังเรียกวิธีต่อไปนี้ในOnStartของบทบาทเว็บของฉัน:

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

ภาพหน้าจอต่อไปนี้แสดงการกำหนดค่าที่ใช้งานได้ของบริการคลาวด์ของเรา โปรดอย่าสับสนเกี่ยวกับพอร์ตที่ไม่ได้มาตรฐาน ภาพหน้าจอมาจากบริการคลาวด์ที่จำลอง

อีกสิ่งหนึ่งที่ต้องพูดถึง: อย่าเปลี่ยนการเชื่อมโยงทั้งหมดเป็น * เนื่องจากการรวม HTTP (พอร์ต 80) ทำงานได้เฉพาะกับ IP: การเชื่อมโยง PORT ในบริการคลาวด์ที่ปรับใช้ อย่างอื่นถูกผูกไว้กับ IP: 80 ดังนั้น *: 80 ไม่ทำงานเพราะ * ย่อมาจาก "ไม่ได้กำหนดทั้งหมด" และ IP ได้รับมอบหมายแล้วในที่อื่นใน http.sys

ตรวจสอบให้แน่ใจว่าการเชื่อมทั้งหมดของคุณไม่ใช่ประเภท IP: พอร์ต เมื่อ IP: มีผลผูกพันกับพอร์ตสำหรับการเชื่อมโยง HTTPS ในขณะที่ไม่จำเป็นต้องใช้ SNI การผูกนั้นจะมีความสำคัญกว่าเสมอ สำหรับกรณี catch-all ของคุณให้ใช้ *: การเชื่อมพอร์ต (* เป็นค่าที่ไม่ได้กำหนดทั้งหมด)

IIS สนับสนุน SNI แม้ในบทบาทเว็บบริการคลาวด์สีฟ้าถึงแม้ว่าคุณจะไม่สามารถกำหนดค่าผ่านทางพอร์ทัลและถ้าคุณทำในช่องหลังจากการปรับใช้มันจะถูกลบด้วยการปรับใช้ครั้งต่อไป ทางออกคือการตั้งค่าโดยอัตโนมัติ ดูรายละเอียดที่นี่:

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