กระบวนการค้นหาอัตโนมัติและโครงสร้างพื้นฐานด้านความปลอดภัยของ Exchange | ตอนที่ 20#36
บทความนี้เป็นข้อมูลเกี่ยวกับกลไกการรักษาความปลอดภัยที่นำไปใช้เป็นส่วนหนึ่งของกระบวนการค้นหาอัตโนมัติ
การค้นหาอัตโนมัติและการรักษาความปลอดภัย
กลไกการค้นหาอัตโนมัติประกอบด้วยสามส่วนหลัก:
- การค้นหาจุดสิ้นสุดการค้นหาอัตโนมัติ
- รับข้อมูลการค้นหาอัตโนมัติ \data
- การใช้ข้อมูลการค้นหาอัตโนมัติ
ในบทความปัจจุบัน เราเกี่ยวข้องกับ "ส่วนตรงกลาง" ในไดอะแกรมที่เกี่ยวข้องกับงานของ - "การรับข้อมูลการค้นหาอัตโนมัติ\ข้อมูล "
กระบวนการค้นหาอัตโนมัติที่สร้างขึ้นเพื่อให้ “ลูกค้า” มีวิธีที่มีประสิทธิภาพและปลอดภัยในการรับข้อมูลที่จำเป็นจาก “เซิร์ฟเวอร์” (จุดสิ้นสุด Exchange หรือ Autodiscover)
ความหมายของ "วิธีที่ปลอดภัย" ได้รับการแปลเป็นข้อกำหนดบังคับที่สำคัญสามประการ:
1. ความสามารถในการพิสูจน์ตัวตน
แต่ละฝ่ายที่เกี่ยวข้องในเซสชันการค้นหาอัตโนมัติ ซึ่งหมายถึงลูกค้าและเซิร์ฟเวอร์ จำเป็นต้องระบุตัวเองและ "พิสูจน์" ตัวตนของเขา
ลูกค้าและเซิร์ฟเวอร์ต้องใช้โมเดล "ความไว้วางใจซึ่งกันและกัน" ซึ่งลูกค้าสามารถรู้ได้ว่าเซิร์ฟเวอร์นั้นเป็น "แหล่งข้อมูลที่เชื่อถือได้" และเซิร์ฟเวอร์สามารถรู้ได้ว่าลูกค้า "ได้รับอนุญาต" เพื่อรับข้อมูลเฉพาะ
ความไว้วางใจระหว่างฝ่ายที่เกี่ยวข้องทำได้โดยการใช้การรับรองความถูกต้องร่วมกัน
“ฝั่งเซิร์ฟเวอร์” จะระบุตัวเองโดยการจัดทำใบรับรอง ฝั่งไคลเอ็นต์จะระบุตัวเองโดยการให้ข้อมูลประจำตัวผู้ใช้ หลังจากที่ไคลเอนต์ Autodiscover ตรวจสอบว่าใบรับรอง Exchange นั้นใช้ได้ และเซิร์ฟเวอร์สามารถเชื่อถือได้ ไคลเอนต์ Autodiscover ยังจำเป็นต้องพิสูจน์ข้อมูลเฉพาะตัวของเขาไปยังเซิร์ฟเวอร์ Exchange
“การพิสูจน์ไคลเอ็นต์การค้นหาอัตโนมัติ” ไม่ได้ถูกนำมาใช้โดยการจัดเตรียมใบรับรอง (ใบรับรองฝั่งไคลเอ็นต์) แต่โดยการให้ข้อมูลประจำตัวผู้ใช้ (ชื่อผู้ใช้ + รหัสผ่าน) ที่จะเข้ารหัสโดยใช้คีย์สาธารณะจากใบรับรองเซิร์ฟเวอร์แทน
<แข็งแกร่ง>2. ความสามารถในการรักษาความปลอดภัยช่องทางการสื่อสาร
ช่องทางการสื่อสารที่ปลอดภัยที่ดำเนินการโดยการเข้ารหัสข้อมูลที่ถ่ายโอนระหว่างจุดสิ้นสุดการค้นหาอัตโนมัติทั้งสองจุด
<แข็งแกร่ง>3. ความสามารถในการให้ความสมบูรณ์ของข้อมูล
ความหมายของ “ความสมบูรณ์ของข้อมูล” คือการใช้กลไกที่จะช่วยให้แต่ละฝ่ายมั่นใจได้ว่าข้อมูลที่ส่งไปจะไม่ถูกแก้ไข เสียหาย ฯลฯ
ในแผนภาพต่อไปนี้ เราจะเห็นข้อกำหนดสำคัญที่ต้องปฏิบัติตาม การดำเนินการตามข้อกำหนดที่แตกต่างกันนี้ดำเนินการโดยโครงสร้างพื้นฐาน SSL
โครงสร้างพื้นฐาน SSL (HTTPS) และ Exchange Autodiscover
SSL ย่อมาจาก - เลเยอร์ซ็อกเก็ตที่ปลอดภัย กลไก SSL ถูกนำมาใช้โดยโปรโตคอลชื่อ - HTTPS (HTTP ปลอดภัย)
โครงสร้างพื้นฐาน Exchange Autodiscover ที่สร้างขึ้นบนโครงสร้างพื้นฐาน SSL
คำว่า “โครงสร้างพื้นฐาน SSL” สร้างขึ้นจากชิ้นส่วนและส่วนประกอบต่างๆ มากมาย การตรวจสอบอย่างละเอียดสำหรับแต่ละองค์ประกอบคือ Outlook ของขอบเขตของบทความปัจจุบันของเรา
แต่เราจะพูดถึง "ส่วน" บางส่วนที่สร้างข้อมูล SSL และวิธีที่ "ใช้" ส่วนนี้โดยกระบวนการค้นหาอัตโนมัติ
การค้นหาอัตโนมัติและใบรับรองสาธารณะฝั่งเซิร์ฟเวอร์
โครงสร้างพื้นฐานสำหรับ HTTPS และ SSL (กลไกที่ใช้โดยกระบวนการ Exchange Autodiscover) อาศัย "ใบรับรองฝั่งเซิร์ฟเวอร์" เป็นอย่างมาก
คำว่า "เซิร์ฟเวอร์" เกี่ยวข้องกับองค์ประกอบที่ให้บริการแก่ลูกค้า
ในสถานการณ์สมมติของเรา เซิร์ฟเวอร์คือเซิร์ฟเวอร์ Exchange (จุดสิ้นสุดการค้นหาอัตโนมัติ) ที่ให้บริการการค้นหาอัตโนมัติแก่ไคลเอนต์การค้นหาอัตโนมัติของเขา
หมายเหตุ - ในบทความปัจจุบัน เราจะพูดถึงคำว่า "ใบรับรองสาธารณะ" ในทางเทคนิคแล้ว ใบรับรองเซิร์ฟเวอร์ไม่จำเป็นต้องถือเป็นใบรับรองสาธารณะที่สร้างโดย CA สาธารณะ (ผู้ออกใบรับรอง)
ในสภาพแวดล้อมสาธารณะ ความจำเป็นที่จำเป็นคือต้องมีใบรับรองสาธารณะ เนื่องจากโครงสร้างพื้นฐานของ Exchange ให้บริการแก่ลูกค้าภายนอกที่อยู่ในเครือข่ายสาธารณะ เราจะเห็นว่าเซิร์ฟเวอร์ Exchange ต้องใช้ใบรับรองสาธารณะ
ใบรับรองสาธารณะฝั่งเซิร์ฟเวอร์ (เซิร์ฟเวอร์ Exchange) ที่ใช้เพื่อวัตถุประสงค์สองประการ:
ใบรับรองสาธารณะฝั่งเซิร์ฟเวอร์ (เซิร์ฟเวอร์ Exchange) ใช้เพื่อวัตถุประสงค์สองประการ:
1. ความสามารถของเซิร์ฟเวอร์ในการจัดเตรียมหลักฐานระบุตัวตนให้กับไคลเอ็นต์ Autodiscover
ไคลเอนต์ Exchange (ไคลเอนต์ Autodiscover) ไม่ได้ส่งต่อเพื่อทราบว่าเซิร์ฟเวอร์ Exchange ที่เขาพยายามสื่อสารนั้น“ เป็นคนที่เขาบอกว่าเขาเป็นจริงๆ หรือไม่ ”
ใบรับรองสาธารณะของเซิร์ฟเวอร์เปิดใช้งานเซิร์ฟเวอร์ Exchange (จุดสิ้นสุดการค้นหาอัตโนมัติ) เพื่อพิสูจน์ข้อมูลเฉพาะตัวของเขาไปยังไคลเอนต์การค้นหาอัตโนมัติ
<แข็งแกร่ง>2. การสร้างลิงก์การสื่อสารที่ปลอดภัย
การค้นหาอัตโนมัติกำหนดความจำเป็นในการเข้ารหัสข้อมูลที่ส่งผ่านระหว่างทั้งสองฝ่าย
การเข้ารหัสข้อมูลที่นำไปใช้โดยใช้คีย์เซสชันที่ไคลเอนต์สร้างและใช้สำหรับงาน - การเข้ารหัสข้อมูลระหว่างจุดสิ้นสุดทั้งสอง
ประเภทของใบรับรองสาธารณะ
การจำแนกประเภททั่วไปของใบรับรองอาจเป็น:
- SAN - (ชื่อทางเลือกของหัวเรื่อง) - ใบรับรองที่สร้างขึ้นเพื่อ "เป็นตัวแทน" โฮสต์ในจำนวนจำกัด โดยส่วนใหญ่ ชื่อโฮสต์จะปรากฏเป็น FQDN ซึ่งหมายถึงหลักการตั้งชื่อที่รวมชื่อโฮสต์ + ชื่อโดเมน
- ใบรับรอง Wildcard - ใบรับรองที่แสดงถึงชื่อโดเมน “สมบูรณ์” และไม่ใช่แค่โฮสต์หรือ FQDN ที่ระบุ ชื่อ “ไวด์การ์ด ” ถูกใช้เนื่องจากไวยากรณ์ที่ใช้จะขึ้นอยู่กับเครื่องหมายดอกจันที่ใช้แทนไวด์การ์ด ตัวอย่างเช่น ใบรับรองไวด์การ์ดสำหรับชื่อโดเมน - com จะเกี่ยวข้องกับชื่อโดเมนเป็น - *.o365info.com
ค้นหาอัตโนมัติ | กระบวนการเข้ารหัสข้อมูล
เป็นเพียงภาพรวมคร่าวๆ เกี่ยวกับวิธีที่ใช้สำหรับ “สร้างช่องทางการสื่อสารที่ปลอดภัย” ระหว่างเซิร์ฟเวอร์และไคลเอนต์
ขั้นตอนที่ 1 - ตรวจสอบข้อมูลระบุตัวตนของเซิร์ฟเวอร์ รับใบรับรองสาธารณะ และดึงรหัสสาธารณะจากใบรับรอง
ลูกค้าขอให้เซิร์ฟเวอร์มอบใบรับรองให้เขา ลูกค้าใช้กระบวนการที่เขายืนยันว่าใบรับรองเซิร์ฟเวอร์เป็น “ตกลง ” และเซิร์ฟเวอร์สามารถเชื่อถือได้
ไคลเอ็นต์ “ดึงข้อมูล ” จากใบรับรองเซิร์ฟเวอร์คีย์สาธารณะ
ขั้นตอนที่ 2 - สร้างคีย์เซสชัน เข้ารหัส และส่งไปยังเซิร์ฟเวอร์
ในกรณีที่กระบวนการตรวจสอบใบรับรองสาธารณะของเซิร์ฟเวอร์เสร็จสมบูรณ์ ไคลเอนต์ “สร้างรหัส ” ที่อธิบายว่าเป็น- คีย์เซสชัน
คีย์เซสชันคือ "รหัสผ่าน ” ซึ่งใช้โดยเซิร์ฟเวอร์และไคลเอนต์ในการเข้ารหัสข้อมูลการเดินทางผ่านลิงก์การสื่อสารที่ปลอดภัย
ไคลเอนต์เข้ารหัสคีย์เซสชันโดยใช้คีย์สาธารณะของเซิร์ฟเวอร์
“(ไคลเอนต์ “รับ” ค่าของคีย์สาธารณะจากใบรับรองเซิร์ฟเวอร์)
ลูกค้าส่งข้อมูลกลับไปยังเซิร์ฟเวอร์
ขั้นตอนที่ 3 - เซิร์ฟเวอร์แยกคีย์เซสชัน
เฉพาะเซิร์ฟเวอร์ที่มีคีย์ส่วนตัวเท่านั้นที่สามารถเปิดโค้ดที่เข้ารหัสและค้นหาค่าของคีย์เซสชันที่ "ซ่อน" ในข้อมูลที่เข้ารหัสได้
ขณะนี้ ไคลเอนต์และเซิร์ฟเวอร์มีคีย์เซสชัน (รหัสผ่าน) ที่พวกเขารู้เท่านั้น
ตั้งแต่วันนี้เป็นต้นไป ข้อมูลแต่ละชิ้นที่ถ่ายโอนระหว่างไคลเอนต์และเซิร์ฟเวอร์จะถูกเข้ารหัสโดยใช้ค่าเป็นคลาส คีย์เซสชัน
หมายเหตุ: คีย์เซสชันในชื่อหมายถึง "ดีเท่านั้น" สำหรับเซสชันที่ระบุ
ทุกครั้งที่ไคลเอ็นต์สร้างการสื่อสารใหม่กับเซิร์ฟเวอร์ กระบวนการจะถูกนำไปใช้ใหม่อีกครั้ง และคีย์เซสชันใหม่จะถูกสร้างขึ้น
กระบวนการค้นหาอัตโนมัติและรายละเอียดความปลอดภัย
ในกระบวนการการค้นหาอัตโนมัติ ความพยายามครั้งแรกของไคลเอนต์การค้นหาอัตโนมัติคือการตรวจสอบว่าจุดสิ้นสุดการค้นหาอัตโนมัติสามารถสื่อสารโดยใช้ HTTPS และหากคำตอบคือ "ใช่" ไคลเอนต์การค้นหาอัตโนมัติจะถามใบรับรองของเขาจากจุดสิ้นสุดการค้นหาอัตโนมัติ
ไคลเอนต์ Autodiscover จะต้องดำเนินการอย่างจริงจังเกี่ยวกับ "การตรวจสอบความถูกต้อง" ดังนั้นเขาจะสามารถมั่นใจได้อย่างไม่ต้องสงสัยว่าใบรับรองเซิร์ฟเวอร์นั้นถูกต้องและถูกต้องตามกฎหมาย
ในกรณีที่ใบรับรองเซิร์ฟเวอร์ถือว่าถูกต้อง ไคลเอนต์ Autodiscover จะให้ข้อมูลประจำตัวของเขาไปยังเซิร์ฟเวอร์ และตั้งแต่วันนี้เป็นต้นไป ข้อมูลทั้งหมดที่ส่งผ่านช่องทางการสื่อสารจะถูกเข้ารหัส
การตรวจสอบความถูกต้องของใบรับรองสาธารณะของเซิร์ฟเวอร์
ใบรับรองเซิร์ฟเวอร์ต้องเป็นไปตามการทดสอบการตรวจสอบทั้งสามรายการที่ดำเนินการโดยไคลเอ็นต์ เพื่อให้สามารถพูดได้ว่าใบรับรองเฉพาะนั้น "ถูกต้อง" ฉันต้องดำเนินการทดสอบการตรวจสอบความถูกต้องทั้งสามรายการให้สำเร็จ
หมายเหตุ: กระบวนการตรวจสอบจะขึ้นอยู่กับวิธีที่โปรโตคอล HTTPS “ทำงาน” และในความเป็นจริง กระบวนการนี้ซับซ้อนยิ่งขึ้นและรวมถึงขั้นตอนเพิ่มเติม เช่น การตรวจสอบความสมบูรณ์ของข้อมูลใบรับรองโดยใช้ลายเซ็นดิจิทัลของเซิร์ฟเวอร์ และอื่นๆ
การทดสอบการตรวจสอบความถูกต้องสามประการที่ลูกค้านำไปใช้คือ:
1. กำลังตรวจสอบชื่อใบรับรอง
คำว่า “การตรวจสอบความถูกต้องของชื่อใบรับรอง“ ทำให้เกิดความสับสนเล็กน้อย
ความหมายคือเมื่อไคลเอ็นต์พยายามระบุที่อยู่ โฮสต์ปลายทาง โดยใช้ชื่อโฮสต์เฉพาะ หรือหากจะให้แม่นยำยิ่งขึ้น FQDN (ผ่านการรับรองโดยสมบูรณ์) ชื่อโดเมน) ไคลเอ็นต์ยกเว้นว่าใบรับรองเซิร์ฟเวอร์จะรวมชื่อโฮสต์นี้ด้วย
กรณีที่ 1 - เซิร์ฟเวอร์ใช้ใบรับรอง SAN
คำว่า - ”SAN ” (ชื่อสำรองของเรื่อง) อธิบายวิธีการรับรองที่รวมหรือเกี่ยวข้องกับชื่อโฮสต์เฉพาะ\s
ในกรณีที่ใบรับรอง SAN มีชื่อโฮสต์สี่ชื่อ ใบรับรองดังกล่าวสามารถใช้งานได้โดยโฮสต์ที่แตกต่างกันสี่โฮสต์ หรือเพียงเซิร์ฟเวอร์เดียวที่ต้องการ "นำเสนอตัวเอง" โดยใช้ชื่อโฮสต์อื่น
ตัวอย่างเช่น เมื่อไคลเอ็นต์ Autodiscover ระบุตำแหน่งปลายทางการค้นหาอัตโนมัติที่เรียกว่า autodiscover.o365info.com ซึ่งเป็นไคลเอ็นต์ ยกเว้นชื่อที่จะปรากฏในใบรับรองเซิร์ฟเวอร์
ในกรณีที่ใบรับรองเซิร์ฟเวอร์ไม่รวมชื่อเซิร์ฟเวอร์ที่ไคลเอนต์ Autodiscover คาดว่าจะค้นหา กระบวนการ Autodiscover จะล้มเหลว
ถ้าเซิร์ฟเวอร์ใช้ใบรับรอง SAN ข้อกำหนดสำหรับการจับคู่ระหว่างชื่อโฮสต์ที่ไคลเอ็นต์ Autodiscover ใช้และชื่อที่ต้องปรากฏในใบรับรองเซิร์ฟเวอร์เป็นข้อบังคับ
กรณีที่ 2 - เซิร์ฟเวอร์ใช้ใบรับรองไวด์การ์ด
ใบรับรองไวด์การ์ดไม่เกี่ยวข้องกับชื่อโฮสต์ใดชื่อหนึ่ง (“ส่วนซ้าย ” ของชื่อ FQDN) แต่จะเกี่ยวข้องกับชื่อโดเมนเท่านั้น (“ส่วนขวา ” ของชื่อ FQDN) แทน
ในกรณีนี้ ใบรับรองจะมีเฉพาะชื่อโดเมนเท่านั้น
แต่ละโฮสต์ที่ใช้ชื่อ FQDN ซึ่งส่วนหนึ่งของชื่อโดเมนเหมือนกันกับชื่อโดเมนที่ปรากฏบนใบรับรองไวด์การ์ด สามารถใช้ใบรับรองนี้ได้
ตัวอย่างเช่น ในกรณีที่ชื่อโฮสต์การค้นหาอัตโนมัติของเซิร์ฟเวอร์ Exchange เฉพาะคือ - autodiscover.o365info.com ใบรับรองไวด์การ์ดที่เซิร์ฟเวอร์จัดเตรียมไว้คือใบรับรองที่แสดงถึง ชื่อโดเมน - o365info.com และไม่ใช่แค่ชื่อโฮสต์เฉพาะ
ตัวอย่างชีวิตจริง
ประเภทของใบรับรองสาธารณะ
1. ใบรับรองซาน
ในภาพหน้าจอต่อไปนี้ เราจะเห็นตัวอย่างใบรับรอง SAN
ดังที่เราเห็นห่วงโซ่ใบรับรองหนึ่งรายการ "โฮสต์" ชื่อโฮสต์หลายชื่อและแม้แต่ชื่อโดเมนหลายชื่อ
<แข็งแกร่ง>2. ใบรับรองไวด์การ์ด
ตัวอย่างถัดไปคือใบรับรอง Office 365 Wildcard
ในภาพหน้าจอต่อไปนี้ เราจะเห็นปรากฏการณ์ที่น่าสนใจ - โครงสร้างพื้นฐานขนาดใหญ่ของ Office 365 และ Exchange Online ทั้งหมดแสดงด้วยใบรับรองที่เรียบง่ายและ “บาง” ”
Office 365 ใช้ใบรับรอง Wildcard ที่มีชื่อโดเมน:
*.office365.com และ *.outlook.com >
เซิร์ฟเวอร์ Office 365 และ Exchange Online ทั้งหมดที่ "เป็น" ของโดเมนใดโดเมนหนึ่งเหล่านี้สามารถใช้ใบรับรองนี้ได้
เราสามารถเชื่อมโยงกับใบรับรองไวด์การ์ดในฐานะ "ร่มเชิงตรรกะ" สำหรับโฮสต์ทั้งหมดที่ชื่อ FQDN รวมหนึ่งในชื่อโดเมนนี้
ใบรับรอง CA
ในภาพหน้าจอต่อไปนี้ เราจะเห็นตัวอย่างใบรับรองสาธารณะที่สร้างขึ้นโดย CA สาธารณะ - GoDaddy
ชื่อของ CA ปรากฏใต้ "ผู้ออก" ที่ยื่น
ห่วงโซ่ความน่าเชื่อถือของใบรับรอง
ในสถานการณ์ส่วนใหญ่ CA ที่ให้ใบรับรองคือลิงก์สุดท้ายในห่วงโซ่
หลายครั้ง มี CA เพิ่มเติมที่ "ลงทะเบียน" CA อื่นเป็นผู้มีอำนาจที่สามารถ "ลงทะเบียน" เซิร์ฟเวอร์อื่นได้
ในโลกของ "ความปลอดภัย" ลูกค้าจะต้องมั่นใจว่าใบรับรองที่เซิร์ฟเวอร์มอบให้นั้นถูกต้องตามกฎหมายและเชื่อถือได้
ด้วยเหตุผลนี้ หลังจากที่เซิร์ฟเวอร์ส่งใบรับรองของเขาให้กับลูกค้าแล้ว ไคลเอนต์จำเป็นต้อง "ดึง Outlook" ออกจากใบรับรองที่เป็นห่วงโซ่ความน่าเชื่อถือของใบรับรอง
ขั้นตอนต่อไปคือการตรวจสอบ CA ใดๆ ที่ปรากฏในห่วงโซ่ความน่าเชื่อถือของใบรับรอง
คำถามที่ 1: ไคลเอ็นต์ (ไคลเอ็นต์การค้นหาอัตโนมัติ) สามารถเชื่อถือใบรับรองที่เซิร์ฟเวอร์ให้ไว้ (จุดสิ้นสุดการค้นหาอัตโนมัติ) ได้อย่างไร
A1: ใบรับรองที่เซิร์ฟเวอร์มอบให้นั้น "ประทับตรา" โดย CA สาธารณะ
ไตรมาสที่ 2: เหตุใดลูกค้าจึงควรเชื่อถือ “CA ” นี้
A2: สมมติฐานพื้นฐานคือเดสก์ท็อปไคลเอ็นต์มีที่เก็บใบรับรองที่มีรายการ CA สาธารณะ "ที่ได้รับอนุมัติ" ซึ่งไคลเอ็นต์สามารถเชื่อถือได้
คำตอบนั้นค่อนข้างง่าย: ทุกระบบปฏิบัติการ "แบบใช้หน้าต่าง" จะมีฐานข้อมูลชื่อ: ที่เก็บใบรับรองเป็นค่าเริ่มต้น
ที่เก็บใบรับรองจะมีใบรับรองหาก “บริษัทมหาชน” เหล่านี้ เช่น - GoDaddy, GTE Cyber Trust, DigiCert และอื่นๆ
ในภาพหน้าจอต่อไปนี้ เราจะเห็นตัวอย่าง "ภายใน" ของที่เก็บใบรับรอง Windows OS และใบรับรอง CA
คำว่า "ห่วงโซ่ความน่าเชื่อถือใบรับรอง" อธิบาย "ลำดับชั้นของความไว้วางใจ" ระหว่างเอนทิตี
เพื่อให้ง่ายขึ้น หลายครั้งที่ CA ที่ "อนุญาต" เซิร์ฟเวอร์เฉพาะโดยมอบใบรับรองสาธารณะให้เขานั้นเป็น "ลูก" หรือผู้ใต้บังคับบัญชาของ CA เพิ่มเติมที่อนุญาตเขา
เมื่อไคลเอนต์ได้รับใบรับรองสาธารณะของเซิร์ฟเวอร์ นอกเหนือจากการตรวจสอบรายละเอียดของเซิร์ฟเวอร์เฉพาะที่ให้ใบรับรองแล้ว ไคลเอนต์จะต้องตรวจสอบ "ลำดับชั้นของความน่าเชื่อถือ" ทั้งหมด ซึ่งหมายถึง CA ทั้งหมดที่เกี่ยวข้องตลอดกระบวนการ
ข้อมูลเกี่ยวกับห่วงโซ่ความน่าเชื่อถือของใบรับรองจะต้องปรากฏเป็นส่วนหนึ่งของใบรับรอง
ตัวอย่างในชีวิตจริง: มาดูตัวอย่างกันดีกว่า ใบรับรองสาธารณะที่ฉันมี
ใต้แท็บ เส้นทางใบรับรอง เราจะเห็นภาพลำดับชั้นที่ชัดเจน
ใบรับรองนี้จัดทำขึ้นสำหรับโฮสต์ชื่อ - o365info.com โดย CA (ผู้ออกใบรับรอง) ของ GoDaddy
ชื่อ CA ที่ให้ใบรับรองนี้คือ - Go Daddy Secure Certification Authority G2 (หมายเลข 2)
ดังที่เราเห็น Go Daddy Secure Certification Authority CA ไม่ได้อยู่ "ระดับบนสุด"
สิทธิ์ในการลงทะเบียนใบรับรองเซิร์ฟเวอร์ได้รับมอบหมายหรือให้มาจาก "ผู้มีอำนาจที่สูงกว่า" ชื่อ - “Go Daddy Root Certificate Authority - G2 ” (หมายเลข 1)
ในแผนภาพต่อไปนี้ เราจะเห็นคำอธิบายของกระบวนการห่วงโซ่ความน่าเชื่อถือของใบรับรอง
ขั้นตอนที่ 1+ 2 : ลูกค้าเข้าถึงเซิร์ฟเวอร์และขอให้เขาจัดเตรียมใบรับรอง
เมื่อลูกค้าได้รับใบรับรองเซิร์ฟเวอร์ เขาจะต้องตรวจสอบว่าชื่อเซิร์ฟเวอร์ปรากฏในใบรับรองหรือไม่ และชื่อนั้นหรือไม่ ปรากฏว่าลูกค้าย้ายไปยังขั้นตอนถัดไปอย่างถูกต้อง
ตอนนี้ ลูกค้าจะพยายามสื่อสารเซิร์ฟเวอร์ CA (Go Daddy Secure Certification Authority ในสถานการณ์ของเรา) และขอให้เขาจัดเตรียมใบรับรองสาธารณะของเขา
ในกรณีที่ CA ให้ใบรับรองสาธารณะ ลูกค้าจะตรวจสอบว่านี่คือ "จุดสิ้นสุดของลำดับชั้นหรือไม่"
ในกรณีที่คำตอบคือ "ใช่" ลูกค้าจะย้ายไปยังขั้นตอนถัดไป
ขั้นตอนที่ 3: ไคลเอ็นต์เข้าถึงที่เก็บใบรับรองในเครื่องของเขา และค้นหาใบรับรอง CA (CA สุดท้ายในลำดับชั้น)
ในกรณีที่ใบรับรอง CA ปรากฏในที่เก็บใบรับรองไคลเอ็นต์และในกรณีที่ใบรับรองถูกต้อง นี่คือ "สัญญาณ" สำหรับลูกค้าที่เขาสามารถเชื่อถือเซิร์ฟเวอร์ที่เขาต้องการสื่อสารด้วย
<แข็งแกร่ง>3. ตรวจสอบว่าวันที่ใบรับรองถูกต้อง
นี่เป็นส่วนที่ง่ายที่สุดของ “กระบวนการตรวจสอบใบรับรอง ”
ใบรับรองแต่ละใบมี "อายุการใช้งานที่จำกัด" “ใบรับรองสาธารณะ อายุการใช้งาน” ที่พบมากที่สุดคือ 1-4 ปี
ลายเซ็นดิจิทัล
ไตรมาสที่ 3: ลูกค้าจะแน่ใจได้อย่างไรว่าใบรับรองนั้นถูกต้องตามกฎหมายและไม่ใช่ของปลอม
A3: ใบรับรองสาธารณะมีลายเซ็นดิจิทัลด้วย ลูกค้า “รู้” วิธีใช้ขั้นตอนที่เขาสามารถตรวจสอบได้ว่าใบรับรองที่เซิร์ฟเวอร์ให้นั้นเป็น “ใบรับรองดั้งเดิม” ที่เขาได้รับจาก CA หรือไม่
คีย์สาธารณะของใบรับรอง
ในภาพหน้าจอต่อไปนี้ เราจะเห็นตัวอย่างค่าคีย์สาธารณะที่ปรากฏในใบรับรอง
การแก้ไขปัญหาสถานการณ์ใบรับรองสาธารณะ
ในส่วนต่อไปนี้ ฉันต้องการตรวจสอบสถานการณ์ที่เป็นไปได้สองสามรายการ ซึ่งอาจรบกวนกระบวนการค้นหาอัตโนมัติ
ดังที่เราทราบ กระบวนการค้นหาอัตโนมัติเริ่มต้นโดยการค้นหาชื่อโดเมนราก
ในสถานการณ์ของเรา ชื่อโดเมนสาธารณะของบริษัทคือ - o365pilot.com
ผู้ใช้ชื่อ Bob ซึ่งมีที่อยู่อีเมล - Bob@o365pilot.com ต้องการสร้างโปรไฟล์เมล Outlook ใหม่
กระบวนการค้นหาอัตโนมัติที่เริ่มต้นโดยไคลเอ็นต์ Outlook จะพยายามค้นหาโฮสต์ชื่อ - o365pilot.com และหากพบโฮสต์ดังกล่าว ให้ลองสร้างเซสชัน HTTPS และขอ ข้อมูลที่จำเป็นในการค้นหาอัตโนมัติ
สถานการณ์ที่ 1: ไม่มีเว็บไซต์สาธารณะที่ "แมป" กับชื่อโดเมน
ในสถานการณ์ของเรา บริษัทไม่ได้เผยแพร่หรือ "แมป" ชื่อโดเมนไปยังเว็บไซต์สาธารณะ
หมายเหตุ - อาจมีสถานการณ์อื่นที่บริษัทมีเว็บไซต์ และชื่อโดเมนรากถูกแมปใน DNS กับ IP สาธารณะของที่อยู่เว็บ แต่เว็บไซต์ไม่รองรับ HTTPS
เมื่อไคลเอ็นต์การค้นหาอัตโนมัติเริ่มกระบวนการ เขาจะติดต่อเซิร์ฟเวอร์ DNS เพื่อค้นหาข้อมูลเกี่ยวกับ IP สาธารณะของ - o365pilot.com
เนื่องจากในสถานการณ์ของเรา ไม่มีข้อมูลดังกล่าว ไคลเอ็นต์การค้นหาอัตโนมัติ "เข้าใจ" ว่าเขาควรเริ่มใช้วิธีที่สองของชื่อโฮสต์การค้นหาอัตโนมัติโดยใช้หลักการตั้งชื่อ - autodiscover.o365pilot.com
ในกรณีที่เซิร์ฟเวอร์ Exchange กำหนดค่าอย่างถูกต้อง ไคลเอนต์ Autodiscover จะค้นหาที่อยู่ IP ของโฮสต์ ตรวจสอบว่าโฮสต์ (เซิร์ฟเวอร์ Exchange) รองรับ HTTPS ขอใบรับรองเซิร์ฟเวอร์หรือไม่
สถานการณ์ที่ 2: เว็บไซต์สาธารณะ + ใบรับรองสาธารณะ
ในสถานการณ์นี้ บริษัทมีเว็บไซต์
IP สาธารณะของเว็บไซต์ถูก "แมป" ในเซิร์ฟเวอร์ DNS กับสาธารณะของบริษัท ชื่อโดเมน - o365pilot.com
นอกจากนี้ เว็บไซต์บริษัทยังรองรับ HTTPS และมีใบรับรอง
เพื่อให้สามารถแสดงให้เห็นถึงปัญหาที่เป็นไปได้ในสถานการณ์นี้ เราจะจำลองปัญหาที่เหมาะสมสองประการที่เกี่ยวข้องกับใบรับรองเว็บเซิร์ฟเวอร์
ปัญหาที่ 1: CA สาธารณะไม่ได้ให้ใบรับรองเซิร์ฟเวอร์
ในสถานการณ์สมมตินี้ เว็บไซต์ของบริษัทใช้ใบรับรองที่สร้างขึ้น โดย CA ที่ไม่ใช่แบบสาธารณะ
หากต้องการข้อมูลเพิ่มเติมเกี่ยวกับใบรับรอง “เว็บเซิร์ฟเวอร์” เรามาดูเนื้อหาของใบรับรองกันดีกว่า:
ในภาพหน้าจอต่อไปนี้ ใต้แท็บ ทั่วไป เราจะเห็นว่าไอคอนใบรับรองปรากฏขึ้นพร้อมกับเครื่องหมายหยุดสีแดง การแจ้งเตือนคือ -
ไม่สามารถตรวจสอบใบรับรองได้จนถึงผู้ออกใบรับรองที่เชื่อถือได้
โปรดทราบว่าใบรับรองเซิร์ฟเวอร์มีชื่อโฮสต์ - o365pilot.com และวันที่ของใบรับรองนั้นถูกต้อง แต่ “CA ที่เชื่อถือได้ไม่ได้สร้างใบรับรองเซิร์ฟเวอร์” และด้วยเหตุนี้ การตรวจสอบความถูกต้องจะล้มเหลว
ใต้แท็บ เส้นทางใบรับรอง เราจะเห็นว่าไม่มีคำว่า "สายโซ่ใบรับรอง" - เราไม่พบ "องค์ประกอบ" (CA สาธารณะ) ที่ให้ใบรับรองนี้
การวิเคราะห์เวิร์กโฟลว์การค้นหาอัตโนมัติโดยใช้ ExRCA
เพื่อให้สามารถดูขั้นตอนการค้นหาอัตโนมัติในสถานการณ์นี้ได้อย่างละเอียดยิ่งขึ้น เราจะใช้ผลลัพธ์ของการทดสอบ ExRCA
ในภาพหน้าจอต่อไปนี้ เราจะเห็นว่าส่วนแรกของกระบวนการค้นหาอัตโนมัติเสร็จสมบูรณ์ (หมายเลข 1 + 2)
ไคลเอ็นต์การค้นหาอัตโนมัติจัดการเพื่อรับที่อยู่ IP ของจุดสิ้นสุดการค้นหาอัตโนมัติ (o365pilot.com) และจัดการเพื่อตรวจสอบว่าจุดสิ้นสุดการค้นหาอัตโนมัติสามารถสื่อสารโดยใช้โปรโตคอล HTTPS ได้
(ที่อยู่ IP ที่ส่งคืน: 85.250.113.157 และการทดสอบพอร์ต TCP 443 บนโฮสต์ o365pilot.com เพื่อให้แน่ใจว่ากำลังฟังและเปิดอยู่)
ไคลเอ็นต์การค้นหาอัตโนมัติขอใบรับรองเซิร์ฟเวอร์ และใบรับรองถูกส่ง
สำเร็จไปยังไคลเอนต์การค้นหาอัตโนมัติ (หมายเลข 3):
Microsoft Remote Connectivity Analyzer ได้รับใบรับรอง SSL ระยะไกลสำเร็จแล้ว
ขั้นตอนการตรวจสอบใบรับรองเริ่มต้นขึ้น
การทดสอบแรกที่ไคลเอ็นต์การค้นหาอัตโนมัติดำเนินการคือ - การตรวจสอบความถูกต้องว่าชื่อจุดสิ้นสุดการค้นหาอัตโนมัติปรากฏในใบรับรอง (หมายเลข 4)
ในผลลัพธ์ ExRCA เราจะเห็นว่าชื่อเซิร์ฟเวอร์ (o365pilot.com) ปรากฏอย่างถูกต้อง-
กำลังตรวจสอบชื่อใบรับรอง ชื่อใบรับรองได้รับการตรวจสอบเรียบร้อยแล้ว พบชื่อโฮสต์ o365pilot.com ในชื่อทั่วไปของหัวเรื่องใบรับรอง
การทดสอบการตรวจสอบครั้งต่อไปที่ดำเนินการโดยไคลเอนต์การค้นหาอัตโนมัติคือ “ความน่าเชื่อถือของใบรับรอง ” (จำนวน 5)
ในผลการทดสอบ เราจะเห็นว่าการทดสอบนี้ไม่เสร็จสมบูรณ์ (หมายเลข 5) เนื่องจากใบรับรองเซิร์ฟเวอร์ไม่ได้ถูกสร้างหรือจัดเตรียมโดย "CA ที่เชื่อถือได้":
กำลังตรวจสอบความน่าเชื่อถือของใบรับรอง การตรวจสอบความน่าเชื่อถือของใบรับรองล้มเหลว
Microsoft Connectivity Analyzer กำลังพยายามสร้างกลุ่มใบรับรองสำหรับใบรับรอง CN=o365pilot.com ไม่สามารถสร้างห่วงโซ่ใบรับรองสำหรับใบรับรองได้
ในกรณีที่การตรวจสอบความถูกต้องของโฮสต์ล้มเหลว ไคลเอนต์ Autodiscover จะ "ก้าวไปข้างหน้า" ไปยังขั้นตอนถัดไปโดยเริ่มมองหาความเป็นไปได้ในการสื่อสารกับชื่อโฮสต์ - autodiscover.o365pilot.com (หมายเลข 6)
ปัญหาที่ 2: ใบรับรองเซิร์ฟเวอร์ไม่มีชื่อโฮสต์ของเซิร์ฟเวอร์
ในสถานการณ์สมมติต่อไปนี้ เราประสบปัญหาอื่น
ใบรับรองเซิร์ฟเวอร์ไม่รวมชื่อของจุดสิ้นสุดการค้นหาอัตโนมัติที่ไคลเอ็นต์ "คาดหวัง"
ในสถานการณ์ของเรา ไคลเอนต์ Autodiscover เริ่มการค้นหาโดยมองหาโฮสต์ชื่อ - o365pilot.com
เมื่อดูใบรับรองเซิร์ฟเวอร์เราจะเห็นว่าชื่อที่ปรากฏในใบรับรองนั้นแตกต่างกัน ในตัวอย่างของเรา ชื่อเซิร์ฟเวอร์ที่สามารถเห็นได้จากใบรับรองคือ -
เราจะเห็นว่ามีปัญหาเพิ่มเติมเนื่องจากใบรับรองไม่ได้มาจาก CA สาธารณะ
ด้วยเหตุนี้ การตรวจสอบความถูกต้องจะล้มเหลว (และไม่ดำเนินการต่อ) ก่อนที่ไคลเอ็นต์การค้นหาอัตโนมัติจะพยายามตรวจสอบ\ทดสอบเส้นทางความน่าเชื่อถือของใบรับรอง
ในภาพหน้าจอต่อไปนี้ เราจะเห็นว่าส่วนแรกของกระบวนการค้นหาอัตโนมัติเสร็จสมบูรณ์ (หมายเลข 1 + 2)
ไคลเอ็นต์การค้นหาอัตโนมัติจัดการเพื่อรับที่อยู่ IP ของจุดสิ้นสุดการค้นหาอัตโนมัติ (o365pilot.com) และจัดการเพื่อตรวจสอบว่าจุดสิ้นสุดการค้นหาอัตโนมัติสามารถสื่อสารโดยใช้โปรโตคอล HTTPS ได้
ไคลเอนต์ Autodiscover ขอใบรับรองเซิร์ฟเวอร์ และ
ส่งใบรับรองไปยังไคลเอนต์ Autodiscover ได้สำเร็จ (หมายเลข 3)
ชุดใบรับรองของการตรวจสอบความถูกต้องเริ่มต้น
การทดสอบแรกที่ไคลเอ็นต์ Autodiscover ทำคือการตรวจสอบว่าชื่อจุดสิ้นสุด Autodiscover ปรากฏในใบรับรอง (หมายเลข 4)
การทดสอบการตรวจสอบล้มเหลว และข้อมูลต่อไปนี้ปรากฏขึ้น -
กำลังตรวจสอบชื่อใบรับรอง การตรวจสอบชื่อใบรับรองล้มเหลว ชื่อโฮสต์ o365pilot.com ไม่ตรงกับชื่อใดๆ ที่พบในใบรับรองเซิร์ฟเวอร์ CN=EX01.o365info.local
