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


12

ฉันต้องการโฮสต์เว็บไซต์ที่ควรฟังโดเมนย่อย (เช่น 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 ของฉันในที่สุด


คุณควรจะสามารถทำสิ่งนี้ได้บน IIS โดยใช้ SNI โดยไม่ต้องใช้ IP หลายตัวหรือพอร์ตที่ไม่ได้มาตรฐาน
Joe Sniderman

คุณหมายความว่า IIS ควรสนับสนุนสิ่งนี้หรือไม่ ฉันเห็นด้วย :-).
Piedone

ฉันเห็นด้วยกับคุณโดยสิ้นเชิง Piedone ฉันผิดหวังจริง ๆ ที่ IIS (หรือจะเป็น http.sys ที่แม่นยำยิ่งขึ้น) ไม่สนับสนุนการรวมของใบรับรองไวด์การ์ดเป็นใบรับรอง SSL เริ่มต้นและใบรับรองคอนกรีตหลายใบที่มี SNI ตามที่คาดหวัง ปัญหาที่เกิดขึ้นเป็นที่รู้จักกันดีตั้งแต่ปี 2012 เป็นที่คุณสามารถดูที่นี่: forums.iis.net/t/1192170.aspx ฉันเพิ่งเขียนอีเมลถึง Microsoft และหวังว่าจะได้รับข้อเสนอแนะในไม่ช้า
โทเบียสเจ

ขอบคุณโทเบียส โปรดกลับมาที่นี่อีกครั้งเมื่อ Microsoft ตอบกลับ
Piedone

2
อาจเป็น http.sys ปฏิเสธคำขอดังนั้นไม่มีคำขอล้มเหลวถูกบันทึกไว้ใน IIS สร้างไฟล์บันทึกการติดตาม HTTP.sys ETW: 1) เริ่มบันทึกการติดตาม run: logman start httptrace -p Microsoft-Windows-HttpService 0xFFFF -o httptrace.etl -ets2) ทำตามคำขอ 503 3) หยุดบันทึกการติดตาม run: logman stop httptrace -ets4) เขียนบันทึกการติดตามไปยังไฟล์ run: tracerpt.exe httptrace.etl -of XML -o httptrace.xml5) ตรวจสอบเหตุผลสำหรับ 503 ในไฟล์ xml และโพสต์ไว้ที่นี่
โทเบียสเจ

คำตอบ:


6

บาริสพูดถูก! ใบรับรอง 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());
        }
    }
}

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

การกำหนดค่า IIS ที่ทำงาน

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


ขอบคุณสำหรับคำตอบโดยละเอียดของคุณ ฉันอัปเดตคำถามของฉัน: ตามที่ฉันจำได้ในตอนนี้ฉันอาจไม่ได้ไปกับการตั้งค่านี้เพราะฉันได้รับข้อผิดพลาดเช่นเดียวกัน
Piedone

4

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


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

โดยพอร์ตฉันคิดว่าคุณหมายถึง IP คุณไม่สามารถมีผลผูกพันหากไม่มีพอร์ต Inetmgr จะไม่อนุญาต สำหรับการผูก SNI คุณสามารถใช้ IP เฉพาะหรือ "ไม่ได้รับมอบหมายทั้งหมด" และผลลัพธ์จะเหมือนกัน เป็น Catch All binding ซึ่งคุณมีใบรับรองไวด์การ์ดที่ต้องอยู่ใน "All Unassigned" และไม่ได้อยู่ใน IP เฉพาะ
bariscaglar

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

bariscaglar เป็นผู้พัฒนา Microsoft (ทำงานบน IIS) ฉันมีการสนทนาที่ดีและเป็นประโยชน์กับ! ขอบคุณบาริส! เราได้วิเคราะห์พฤติกรรมและเราได้ข้อสรุปว่าพฤติกรรมที่อธิบายนั้นเป็นพฤติกรรมที่ต้องการของ http.sys แต่มีวิธีแก้ปัญหาที่ดีคือ ดูคำตอบของฉันสำหรับรายละเอียด
โทเบียสเจ

เพิ่งทราบสำหรับทุกคนที่อ่านฉันเพิ่งค้นพบว่าถ้าคุณใช้ Azure Portal เพื่อกำหนดค่าบริการสำหรับเดสก์ท็อประยะไกล (หรือเปลี่ยนการกำหนดค่าใบรับรอง) ก็สามารถทำให้ IP: พอร์ตผูกพันที่จะสร้างขึ้นโดยอัตโนมัติและทำลาย SNI ทั้งหมดของคุณ . ฉันไม่มีวิธีแก้ปัญหาเฉพาะเรื่องนั้น มันเกิดขึ้นหลังจาก RoleEnvironment.Changed ดังนั้นฉันจึงไม่สามารถจับมันได้ใน WebRole.cs
Mike

1

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

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


ขอบคุณ แต่อย่างที่ฉันอธิบายไม่มีปัญหากับ SNI ตัวเอง (ฉันใช้มัน) แต่วิธีการจับคู่ชื่อโฮสต์ตัวแทนใน IIS
Piedone

บทความนี้ไม่มีอยู่อีกต่อไป แต่ที่นี่เป็นที่เก็บถาวรของเว็บ: web.archive.org/web/20151020041907/http://www.vic.ms/microsoft/…
Mike
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.