วัตถุประสงค์ใบรับรองที่ไม่รองรับ: ทำไม CA ระดับกลางจึงล้มเหลว

วัตถุประสงค์ใบรับรองเซิร์ฟเวอร์ดูถูกต้อง กุญแจตรงกัน วันที่ไม่ผิดปกติ และการเชื่อมต่อยังล้มเหลวด้วย unsupported certificate purpose รายละเอียดที่ไขปัญหานี้มักอยู่ในบรรทัดเดียวกับข้อผิดพลาด คือค่าความลึกและ subject ที่ระบุใบรับรองที่อยู่สูงกว่าในห่วงโซ่ มีการทดสอบสองแบบที่ต่างกัน และมีเพียงแบบเดียวที่เกี่ยวกับใบปลายทาง การเปรียบเทียบทั้งสองอธิบายว่าทำไมการเปลี่ยนใบรับรองเซิร์ฟเวอร์จึงไม่เปลี่ยนอะไร

ใบรับรองใดที่ผู้ตรวจสอบปฏิเสธจริง

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

อ่านฟิลด์ของใบรับรองที่ความลึกนั้น ไม่ใช่ใบรับรองที่คิดว่าเป็นต้นเหตุ ขอส่วนขยายสองรายการที่จำกัดการออก แทนการเททุกฟิลด์ เพราะคำตอบมักอยู่ในหนึ่งในนั้น เอาต์พุตของส่วนขยายปลอดภัยที่จะแชร์ กุญแจส่วนตัวไม่เคย

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

หากใบรับรองที่ระบุเป็นใบระดับกลางซึ่งการใช้งานกุญแจแบบขยายกล่าวถึงสิ่งที่ไม่เกี่ยวกับการพิสูจน์ตัวตนเซิร์ฟเวอร์ TLS ความล้มเหลวที่เหลือจะตามมาโดยกลไก ห่วงโซ่นี้ใช้ไม่ได้กับวัตถุประสงค์ที่ OpenVPN ร้องขอ

วัตถุประสงค์ของใบปลายทางและนโยบายของห่วงโซ่คือการทดสอบสองแบบ

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

นี่คือเหตุผลที่ใบปลายทางที่ออกใหม่ ซึ่งถูกต้องในทุกฟิลด์ที่มองเห็น อาจล้มเหลวทันที และเป็นเหตุผลที่การแก้ไขมักอยู่ในโปรไฟล์ของหน่วยงานผู้ออก ไม่ใช่การตั้งค่า VPN

EKU ที่ไม่มีไม่ใช่ EKU ที่จำกัด

RFC 5280 ทำให้ส่วนขยายการใช้งานกุญแจแบบขยายเป็นทางเลือก และเมื่อมีอยู่ก็เป็นข้อจำกัด ดังนั้นใบรับรอง CA ที่ไม่มีส่วนขยายนี้จึงไม่ได้กล่าวว่า «ไม่» ต่อการพิสูจน์ตัวตนเซิร์ฟเวอร์ ขณะที่ใบที่ระบุเพียงวัตถุประสงค์ที่ไม่เกี่ยวข้องได้กล่าวสิ่งที่เฉพาะเจาะจงมาก การถือว่าสองสถานะนี้เทียบเท่ากันให้การวินิจฉัยที่ผิด และแย่กว่านั้นคือวิธีแก้ที่ผิด ความแตกต่างนี้ยังอธิบายว่าทำไมหน่วยงานสองแห่งที่ดูคล้ายกันในคอนโซลจึงทำงานต่างกันอย่างสิ้นเชิงในห่วงโซ่

พฤติกรรมของไลบรารีก็ไม่เหมือนกันในที่นี้ เอกสารของ OpenSSL เกี่ยวกับตัวเลือกการตรวจสอบ อธิบายวิธีจัดการการตรวจสอบวัตถุประสงค์บนใบรับรอง CA ของตนเอง และวิธีนั้นเป็นนโยบายการนำไปใช้ ไม่ใช่กฎที่ทุกสแตก TLS ปฏิบัติเหมือนกันทุกประการ อธิบายว่าผู้ตรวจสอบของคุณทำอะไร แล้วยืนยันกับเวอร์ชันที่คุณรันจริง

ทำให้ความล้มเหลวเกิดซ้ำแบบออฟไลน์ก่อนออกใหม่

การตรวจสอบแบบออฟไลน์นำแอปพลิเคชันออกจากสมการ หากห่วงโซ่ล้มเหลวแบบเดียวกันภายใต้วัตถุประสงค์เดียวกัน ปัญหาคือใบรับรอง และไม่มีการตั้งค่าเซิร์ฟเวอร์ใดซ่อนไว้ได้ หากห่วงโซ่ผ่านแบบออฟไลน์แต่บริการยังปฏิเสธ แอปพลิเคชันกำลังขอวัตถุประสงค์อื่นหรือใช้ห่วงโซ่อื่นที่ไม่ใช่ห่วงโซ่ที่คุณทดสอบ

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

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

แก้นโยบายการออก ไม่ใช่การเรียกตรวจสอบ

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

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