ข้อผิดพลาดความเชื่อถือ Android IKEv2: ส่ง CA ระดับกลาง ไม่ใช่ราก
โทรศัพท์ปฏิเสธเกตเวย์เพราะห่วงโซ่ที่ได้รับสิ้นสุดเร็วเกินไป ตัดสินใจ: ส่งตัวกลาง แก้ไขตัวตน หรือเปลี่ยนประเภทคีย์
โทรศัพท์ปฏิเสธการเชื่อมต่อและพิมพ์ No trusted RSA public key found for vpn.example.net ในขณะที่ใบรับรองเกตเวย์เดียวกันทำงานได้จากแล็ปท็อปในเครือข่ายเดียวกัน การออกใบรับรองใหม่เป็นขั้นตอนที่ชวนทำ ก่อนจะทำเช่นนั้น ให้พิจารณาว่าคุณมีหนึ่งในสามความล้มเหลวใด เพราะมีเพียงหนึ่งเดียวเท่านั้นที่เกี่ยวกับเนื้อหาของใบรับรอง ข้อความครอบคลุมห่วงโซ่ที่ไม่สมบูรณ์ ตัวตนไม่ตรงกัน และคีย์หรือลายเซ็นที่ไม่รองรับ และแต่ละอย่างมีการซ่อมแซมต่างกัน
สามความล้มเหลวเบื้องหลังข้อความเดียว
Android สร้างห่วงโซ่จากใบรับรองเกตเวย์ไปยัง CA ที่เลือกในโปรไฟล์ VPN จากนั้นเปรียบเทียบชื่อเซิร์ฟเวอร์กับโปรไฟล์ การแจ้งเตือนรายงานผลลัพธ์ ไม่ใช่ขั้นตอน ความล้มเหลวด้านความเชื่อถือหมายถึงไม่สามารถทำให้ห่วงโซ่สมบูรณ์จากใบรับรองที่ส่งมาในการแลกเปลี่ยนได้ ความล้มเหลวด้านตัวตนหมายถึงห่วงโซ่ผ่านการตรวจสอบแต่ชื่อไม่ตรง ความล้มเหลวด้านอัลกอริทึมหมายถึงอุปกรณ์หรือโปรไฟล์ไม่ยอมรับประเภทคีย์หรือลายเซ็น
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
ตัดสินใจด้วยหลักฐานแทนการลองซ่อมตามลำดับ การลองหนึ่งครั้งที่ระดับบันทึก 2 กับดีมอนจะบอกว่าคุณอยู่ในแถวใด และมีค่าใช้น้อยกว่าการออกใบรับรองใหม่ที่ไม่เคยผิดเลย
ตัดสินใจก่อน: ห่วงโซ่ทั้งหมดมาถึงหรือไม่?
strongSwan ส่งใบรับรองที่กำหนดค่าไว้สำหรับการเชื่อมต่อนั้น และใบรับรองระดับกลางเป็นข้อมูลรับรองแยกต่างหาก ต้องโหลดเป็นใบรับรอง CA ก่อนที่ดีมอนจะวางไว้ในเพย์โหลดได้ ดังนั้นการจัดวางที่ใบรับรองเซิร์ฟเวอร์ลงนามโดยตัวกลาง รากเป็นสมอความเชื่อถือ และตัวกลางอยู่ในไดเรกทอรีบิลด์ของ CA เท่านั้น จึงก่อให้เกิดความล้มเหลวนี้พอดี: มีเพียงใบที่สาย สายโซ่สิ้นสุดเร็วบนโทรศัพท์
ตรวจสอบว่าดีมอนมีอะไรด้วย swanctl --list-certs ในการติดตั้ง swanctl หรือ ipsec listcerts กับ starter รุ่นเก่า ตัวกลางควรปรากฏเป็นใบรับรอง CA ที่มีรากอยู่เหนือขึ้นไป หากหายไป ไม่มีตัวเลือกฝั่งไคลเอนต์ใดช่วยได้ หากมีอยู่ ให้ไปยังคำถามถัดไป
จากนั้นตรวจสอบว่าจะถูกส่งหรือไม่ เอกสารอ้างอิง swanctl.conf ระบุ send_cert ซึ่งค่าเริ่มต้น ifasked ส่งใบรับรองเฉพาะเมื่อคู่เจรจาขอเท่านั้น always ส่งเสมอ ค่าเทียบเท่ารุ่นเก่าคือ leftsendcert=always ใน ipsec.conf การตั้งค่านั้นควบคุมการส่ง ไม่ใช่ความพร้อมใช้งาน จึงชดเชยตัวกลางที่ดีมอนไม่เคยโหลดไม่ได้
หากห่วงโซ่สั้น ให้โหลดตัวกลางในที่ที่ดีมอนค้นหา
วางตัวกลางในไดเรกทอรี CA ไม่ใช่ข้างใบ: /etc/ipsec.d/cacerts สำหรับการตั้งค่า ipsec.conf /etc/swanctl/x509ca สำหรับ swanctl หรือพาธที่แพ็กเกจของคุณแทนที่ โหลดการกำหนดค่าใหม่และแสดงรายการใบรับรองอีกครั้ง บางเวอร์ชันยังส่งบันเดิลที่มีห่วงโซ่อยู่ในไฟล์ใบ แต่ไดเรกทอรี CA เป็นการจัดวางที่พกพาได้ข้ามเวอร์ชันและแพ็กเกจ
ตรวจสอบจากฝั่งไคลเอนต์ด้วย โทรศัพท์เห็นเพียงสิ่งที่การแลกเปลี่ยนนำมา ดังนั้นบันทึกดีมอนที่ระดับ 2 ควรแสดงตัวกลางในใบรับรองที่ส่งไป หากบันทึกแสดงและโทรศัพท์ยังล้มเหลว คุณอยู่ในแถวอื่นของตาราง และการปรับไฟล์ CA ต่อไปจะไม่เปลี่ยนผลลัพธ์
หากห่วงโซ่สมบูรณ์ ให้หยุดแก้ไขใบรับรอง
ความล้มเหลวด้านตัวตนคือความไม่ตรงกันระหว่างชื่อในโปรไฟล์ VPN กับชื่อในใบรับรอง Android เปรียบเทียบตัวตนเซิร์ฟเวอร์ที่คุณกำหนดค่ากับใบรับรองที่ตรวจสอบแล้ว ดังนั้นโปรไฟล์ที่ชี้ไปยังที่อยู่ในขณะที่ใบรับรองระบุชื่อโฮสต์ หรือโปรไฟล์ที่ระบุชื่อโฮสต์ที่ใบรับรองไม่ครอบคลุม จะล้มเหลวหลังการตรวจสอบห่วงโซ่สำเร็จ แก้ไขฝั่งที่ผิด และรักษาโปรไฟล์กับใบรับรองให้สอดคล้องกันเมื่อฝ่ายใดเปลี่ยน
ความล้มเหลวด้านอัลกอริทึมปรากฏพร้อมห่วงโซ่ที่ถูกต้องและชื่อที่ตรงกัน เวอร์ชัน Android แตกต่างกันในประเภทคีย์และโครงร่างลายเซ็นที่ยอมรับ และประเภทโปรไฟล์เองก็จำกัดตัวเลือก หากเกตเวย์ใช้ชุดค่าผสมเก่าหรือผิดปกติ ให้เปรียบเทียบกับสิ่งที่อุปกรณ์รองรับก่อนสันนิษฐานว่าใบรับรองเสียหาย บันทึกดีมอนจะแสดงแฮนด์เชคดำเนินต่อไปไกลกว่ากรณีความเชื่อถือ ซึ่งเป็นสัญญาณว่าห่วงโซ่ไม่ใช่ปัญหาอีกต่อไป
อย่าติดตั้งตัวกลางเป็นรากของผู้ใช้บนโทรศัพท์
การติดตั้งตัวกลางที่หายไปเป็นใบรับรองผู้ใช้บนโทรศัพท์ทำให้คำเตือนหายไปและเปลี่ยนแบบจำลองความเชื่อถือของโทรศัพท์สำหรับทุกแอปที่ยอมรับรากที่ผู้ใช้ติดตั้ง นอกจากนี้ยังซ่อนข้อบกพร่องในการส่งมอบที่จะกระทบไคลเอนต์ถัดไป และทำให้เกตเวย์ส่งห่วงโซ่ที่ไม่สมบูรณ์ไปยังทุกอุปกรณ์ในอนาคต การซ่อมแซมที่ยั่งยืนอยู่ที่เซิร์ฟเวอร์ ครั้งเดียว สำหรับไคลเอนต์ทั้งหมด
แยกการตัดสินใจทั้งสามไว้ในบันทึกการเปลี่ยนแปลง: ใบรับรองใดถูกส่ง ตัวตนใดถูกเปรียบเทียบ และอัลกอริทึมใดถูกเจรจา เกตเวย์ที่ส่งห่วงโซ่เต็มเสมอ โปรไฟล์ที่ระบุชื่อใบรับรองอย่างถูกต้อง และประเภทคีย์ที่ฝูงอุปกรณ์รองรับ เป็นข้อเท็จจริงเล็ก ๆ สามข้อ และนั่นคือความล้มเหลวทั้งหมดนี้