ใบรับรองใบเป็นใบที่ถูกต้อง แต่ห่วงโซ่หมดอายุ: อ่านความลึก

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

ความลึกบอกชื่อใบรับรองที่ล้มเหลว

ในการวินิจฉัยของ OpenSSL ความลึก 0 คือใบรับรองเป้าหมาย และความลึก 1 คือผู้ออกที่ลงนามให้ ความลึกที่มากขึ้นจะต่อไปยังสมอความเชื่อถือ การหมดอายุที่รายงานที่ความลึก 1 ไม่ได้ถูกโต้แย้งด้วย notAfter ปัจจุบันบนใบ ดังนั้นการตรวจใบรับรองที่มองเห็นอีกครั้งจะไม่มีทางอธิบายข้อผิดพลาดได้

บันทึกลายนิ้วมือของใบรับรองที่ล้มเหลวพร้อม subject ของมัน เพราะใบรับรองต่างกันอาจมีชื่อ CA เดียวกัน การลงนามข้ามสร้างสถานการณ์นั้นพอดี: หน่วยงานเดียวกันปรากฏมากกว่าหนึ่งครั้ง ด้วยวันที่ใช้ได้ต่างกัน และผู้ตรวจเลือกอันที่คุณไม่ได้คาดไว้ ฉลากที่คุ้นเคยไม่ใช่ตัวระบุ และลายนิ้วมือคือสิ่งที่แยกวัตถุสองชิ้นที่ใช้ชื่อร่วมกัน

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

อินพุตความเชื่อถือไม่เหมือนกับตัวเลือกในห่วงโซ่

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

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

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

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

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

การตรวจพิสูจน์อะไรและละอะไรไว้

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

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

หากต้องการเห็นหน้าต่างของใบรับรองแต่ละใบแทนที่จะดูทีละใบ ให้พิมพ์เป็นชุด:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

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

ซ่อมเส้นทางโดยไม่ทำให้การตรวจสอบอ่อนแอลง

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

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

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