SAN ของใบรับรอง IKEv2: ทำไมการตรวจสอบตัวตนจึงล้มเหลว
ใบรับรอง IKEv2 ที่ถูกต้องยังคงล้มเหลวเมื่อตัวตนที่คาดหวังและประเภท SAN ไม่ตรงกัน จับคู่ DNS กับ DNS, IP กับ IP และตรวจสอบโปรไฟล์ก่อน
ใบรับรองของคุณเชื่อมโยงกับ CA ที่เชื่อถือได้ วันที่ถูกต้อง และคู่ขัดยังคงปฏิเสธที่จะจบเฟส 1 ด้วยข้อผิดพลาดด้านตัวตน การเข้าถึงได้และลายเซ็นที่ถูกต้องเป็นเพียงครึ่งหนึ่งของสิ่งที่ไคลเอนต์ IKEv2 ตรวจสอบ อีกครึ่งหนึ่งคือตัวตนที่คาดหวังปรากฏในใบรับรองในฟิลด์ที่ถูกต้องหรือไม่ และความคาดหวังนั้นถูกกำหนดโดยโปรไฟล์ ไม่ใช่ชื่อไฟล์ของใบรับรอง
อาการมีรูปร่างเหมือนเดิมเสมอ
โปรไฟล์การเชื่อมต่อถูกเปลี่ยนจากชื่อโฮสต์เป็นที่อยู่ IP หรือต่ออายุจากใบรับรองที่มีชื่อ DNS เป็นใบรับรองที่มีเฉพาะที่อยู่ และอุโมงค์หยุดเจรจา. ไม่มีอะไรเปลี่ยนแปลงในเส้นทางเครือข่าย ไคลเอนต์เข้าถึงคู่ขัด ได้รับใบรับรอง และปฏิเสธตัวตนของคู่ขัดเพราะตัวระบุที่บอกให้คาดหวังไม่ได้แสดงอยู่ในฟิลด์ที่ยอมรับ การต่ออายุเป็นตัวกระตุ้นปกติ เนื่องจากใบรับรองทดแทนมักมาจากเทมเพลตที่แตกต่างจากใบที่ถูกแทนที่
จากนั้นทั้งสองฝ่ายบันทึกสิ่งที่ไม่เป็นประโยชน์ ซึ่งเป็นเหตุให้ความล้มเหลวมักถูกรายงานว่าเป็นปัญหาใบรับรอง บันทึกของไคลเอนต์อาจระบุตัวตนที่ต้องการ และชื่อนั้นคือเบาะแสที่คุณต้องการ ไม่ใช่วันหมดอายุ
จับคู่ประเภทของตัวระบุ ไม่ใช่แค่ค่า
SAN ชนิด dNSName และ SAN ชนิด iPAddress เป็นฟิลด์ที่แตกต่างกันพร้อมกฎการจับคู่ที่แตกต่างกัน ดังนั้นใบรับรองที่มี 203.0.113.10 เป็นสตริง DNS จึงไม่ทำให้ไคลเอนต์ที่คาดหวังตัวตน IP พอใจ ตัวตรวจสอบสมัยใหม่ส่วนใหญ่เพิกเฉยต่อชื่อทั่วไป ป้ายชื่อที่เป็นมิตรในรายละเอียดใบรับรองจึงไม่ได้พิสูจน์อะไรเกี่ยวกับสิ่งที่จะตรงกัน หากชื่อโฮสต์ถูกแทนที่ด้วยที่อยู่ระหว่างการแก้ปัญหา ให้ถือว่าตัวตนที่คาดหวังย้ายไปด้วยจนกว่าคุณจะตรวจสอบ เปรียบเทียบสตริงในโปรไฟล์กับสตริงใน SAN ทีละอักขระ เพราะจุดท้ายหรือช่องว่างเกินก็เพียงพอ
ไวลด์การ์ดเป็นเพียงความสะดวกของ DNS และปฏิบัติตามกฎการจับคู่ของตัวเอง ซึ่งเป็นอีกเหตุผลที่โปรไฟล์ที่อิง IP ไม่ควรพึ่งพาไวลด์การ์ดเลย
ค้นหาว่าไคลเอนต์แต่ละตัวเก็บความคาดหวังไว้ที่ใด
ใน strongSwan ค่าที่เปรียบเทียบกับใบรับรองมาจากการตั้งค่าตัวตนของคู่ขัด: rightid ในการกำหนดค่าแบบคลาสสิก หรือ id ของส่วนการเชื่อมต่อระยะไกลใน swanctl เอกสารเกี่ยวกับการทำงานร่วมกับ Apple IKEv2 มีประโยชน์ที่นี่เพราะอธิบายแบบแผนตัวตนที่ไคลเอนต์ที่ขับเคลื่อนด้วยโปรไฟล์ใช้ และแบบแผนเหล่านั้นอธิบายระดับของความไม่ตรงกันที่ดูเหมือนสุ่มบนสาย
โปรไฟล์การกำหนดค่าของ Apple มีฟิลด์ตัวระบุระยะไกล และค่าที่นั่นคือสิ่งที่ไคลเอนต์ตรวจสอบ ไม่ใช่ที่อยู่เซิร์ฟเวอร์ในการตั้งค่าการเชื่อมต่อ ไคลเอนต์ Windows และอุปกรณ์ต่างมีฟิลด์ของตัวเองพร้อมค่าเริ่มต้นของตัวเอง และค่าเริ่มต้นมักตามที่อยู่ที่คุณพิมพ์ เมื่อสองฟิลด์ไม่ตรงกัน ฝ่ายที่ไคลเอนต์อ่านจริงจะเป็นฝ่ายชนะ และแทบไม่ใช่ฟิลด์ที่คุณแก้ไข
ซ่อมโปรไฟล์หรือใบรับรองอย่างตั้งใจ
ก่อนเปลี่ยนสิ่งใด ให้ตรวจสอบใบรับรองของคู่ขัดด้วยเครื่องมือที่ได้รับอนุมัติและระบุรายการ SAN พร้อมประเภท การตรวจสอบนั้นไม่ต้องใช้กุญแจส่วนตัวและไม่ต้องอัปโหลด และแก้คำถามได้ในไม่กี่วินาที หากการติดตั้งตั้งใจให้มีตัวตน DNS เพียงหนึ่งเดียว ใบรับรองต้องมีสิ่งนั้นเป็นรายการ dNSName และหากการติดตั้งตั้งใจให้มีที่อยู่ ใบรับรองต้องมีรายการ iPAddress สำหรับที่อยู่นั้นโดยเฉพาะ
เมื่อใบรับรองผิด ให้ขอใบที่แก้ไขแล้วจากผู้ดูแลพร้อมตัวระบุที่คาดหวังอย่างเฉพาะเจาะจง เมื่อโปรไฟล์ผิด ให้แก้โปรไฟล์และปล่อยใบรับรองไว้ การปิดการตรวจสอบตัวตนทำให้ข้อผิดพลาดหายไปและลบการตรวจสอบว่าอุโมงค์กำลังคุยกับคู่ขัดที่คุณตั้งใจ
บันทึกตัวตนที่คาดหวังสำหรับแพลตฟอร์มไคลเอนต์แต่ละแพลตฟอร์ม เพราะค่าที่ไคลเอนต์หนึ่งได้มาโดยอัตโนมัติอาจต้องระบุอย่างชัดเจนบนอีกตัว
ให้ข้อเท็จจริงสี่ประการแก่คำขอต่ออายุ
เขียนตัวระบุที่คาดหวังและประเภทของมัน รายการ SAN ที่ใบรับรองปัจจุบันมีจริง ไคลเอนต์และเวอร์ชันที่ทำการตรวจสอบ และข้อความข้อผิดพลาดที่แน่นอน คำขอต่ออายุที่สร้างจากสี่บรรทัดนี้จะได้ใบรับรองที่ถูกต้องในครั้งแรก แทนที่จะเป็นอีกใบที่มีชื่อไฟล์คุ้นเคยเหมือนกัน