ไคลเอนต์ VPN ของคุณตรวจอะไรก่อนจะเชื่อถือใบรับรอง
พาคำเตือนใบรับรองผ่านประตูสี่บานที่ไคลเอนต์ของคุณตรวจสอบ ความไว้วางใจใน CA การสร้างสายโซ่ ชื่อและวัตถุประสงค์ของคู่ และนโยบายการเพิกถอน
ไคลเอนต์ VPN ของคุณบอกว่าตรวจสอบใบรับรองไม่ได้ และกล่องโต้ตอบก็จบแค่นั้น ไฟล์อยู่ครบ เซิร์ฟเวอร์ทำงานอยู่ และโปรไฟล์เดียวกันเคยทำงานบนแล็ปท็อปเครื่องอื่นเมื่อเดือนที่แล้ว ภายใต้คำเตือนบรรทัดเดียวนั้น ไคลเอนต์ได้พาใบรับรองของคู่ผ่านประตูสี่บาน คือหน่วยออกใบรับรองที่คุณตั้งค่าไว้รับประกันเส้นทางการลงนาม เส้นทางนั้นไปถึงหน่วยงานนั้น ชื่อของคู่คือชื่อที่คุณขอ และใบรับรองใช้งานได้กับวัตถุประสงค์นี้ในตอนนี้ ค้นหาประตูที่ปิดลง แล้วการซ่อมมักเป็นไฟล์เดียว ถ้าข้ามขั้นตอนนั้นไปคุณจะนำเข้าแพ็กเกจซ้ำทั้งบ่าย
อ่านกล่องโต้ตอบก่อนแก้ไขโปรไฟล์
ข้อความแสดงข้อผิดพลาดของใบรับรองนั้นสร้างโดยไลบรารีที่อยู่ข้างใต้ ไม่ใช่ผลิตภัณฑ์ VPN ที่คุณติดตั้ง ดังนั้นสตริงที่ตรงที่สุดจึงเป็นหลักฐานชิ้นแรกของคุณ ข้อความ «ไม่สามารถดึงใบรับรองของผู้้ออกภายในเครื่องได้» ชี้ไปที่เส้นทางหรือสมอความเชื่อถือ ข้อความ «ใบรับรองหมดอายุหรือยังไม่ถึงเวลาใช้งาน» ชี้ไปที่เวลา ข้อความ «วัตถุประสงค์ของใบรับรองไม่รองรับ» ชี้ไปที่การใช้คีย์แบบขยาย ชื่อที่ไม่ตรงกันบอกคุณว่าต้องการชื่ออะไร ไม่มีข้อใดในสี่ข้อนี้ที่แก้ได้ด้วยการติดตั้งไคลเอนต์ใหม่
เพิ่มระดับการบันทึกก่อนเปลี่ยนแปลงสิ่งใด OpenVPN รายงานความล้มเหลวในการตรวจสอบรอบการจับมือเมื่อคุณเรียกใช้ด้วย --verb 4 และ strongSwan เขียนการตัดสินใจเรื่องตัวตนและสายโซ่ลงในบันทึก charon จากนั้นยืนยันว่าคุณกำลังตรวจใบรับรองใด เพราะผู้คนมักทดสอบไฟล์บนดิสก์ในขณะที่โปรไฟล์ฝังสำเนาเก่าไว้ เมื่อโปรไฟล์ฝังบล็อก PEM ใบรับรองที่ฝังอยู่คือสิ่งที่ถูกทดสอบ
หน่วยออกใบรับรองลงนามในตัวตน ไม่ใช่สิทธิ์
หน่วยงานถือชื่อและคีย์ลงนาม ออกใบรับรองที่ผูกคีย์สาธารณะกับชื่อนั้นตามนโยบายของตนเอง พร้อมช่วงเวลาความถูกต้องและข้อจำกัดการใช้งานแนบมาด้วย ไคลเอนต์ของคุณต้องการเพียงใบรับรองของหน่วยงานเพื่อรู้จักผู้ออก ไม่เคยต้องใช้คีย์ลงนาม และการส่งคีย์นั้นให้ไคลเอนต์จะให้ความสามารถในการสร้างตัวตนใดก็ได้ที่การติดตั้งไว้วางใจ
การไว้วางใจหน่วยงานทำให้ทุกใบรับรองที่ลงนามแล้วเป็นผู้สมัคร ไม่ใช่คู่ที่ถูกต้อง ใบรับรองเว็บเซิร์ฟเวอร์จาก CA ภายในเดียวกันก็เป็นผู้สมัครเช่นกัน นี่คือเหตุผลที่มีประตูชื่อและวัตถุประสงค์ และนี่คือเหตุผลที่คีย์ CA ที่ถูกบุกรุกสำคัญกว่าเซิร์ฟเวอร์ใดเพียงเครื่องเดียว เพราะมันไปถึงทุกตัวตนที่หน่วยงานเคยออกให้ จ่ายใบรับรองไคลเอนต์แยกตามอุปกรณ์ เพื่อให้แล็ปท็อปที่หายไปเป็นการเพิกถอนครั้งเดียว ไม่ใช่การสร้างคีย์ใหม่ทั้งการติดตั้ง
สร้างเส้นทางที่ไคลเอนต์กำลังพยายามสร้างขึ้นใหม่
เส้นทางเริ่มจากใบรับรองของคู่ ผ่านใบรับรองกลางศูนย์หรือมากกว่า ไปยังรากในที่เก็บความเชื่อถือของคุณ ใบรับรองกลางที่หายไปคือความล้มเหลวของสายโซ่ที่พบบ่อยที่สุด และจากฝั่งไคลเอนต์มันดูเหมือน รากที่ไม่ได้รับความเชื่อถือ ทุกประการ อ่านใบก่อน แล้วปล่อยให้ OpenSSL สร้างเส้นทางจากวัสดุที่คุณตั้งใจจะส่ง
openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crtสถานะออกเป็นศูนย์หมายถึงเส้นทางถูกสร้างจากไฟล์เหล่านั้น ความล้มเหลวจะระบุชื่อใบรับรองที่ไม่สามารถไปถึงได้ ถ้า openssl verify สำเร็จแต่ไคลเอนต์ยังปฏิเสธ ความแตกต่างอยู่ที่สิ่งที่เซิร์ฟเวอร์ส่งจริงหรือไฟล์ความเชื่อถือที่โปรไฟล์โหลด ใน OpenVPN ใบรับรองกลางสามารถเดินทางไปกับไฟล์ใบรับรองของเซิร์ฟเวอร์หรือให้แยกต่างหากด้วย --extra-certs และชุดที่มีรากสองรากเขียนใต้ชื่อหัวข้อเดียวกันจะส่งไคลเอนต์ของคุณคนหนึ่งไปยังสาขาที่ผิด
ชื่อและวัตถุประสงค์เป็นประตูแยกกัน
การสร้างสายโซ่ไม่เคยถามว่าชื่อเป็นของคุณหรือไม่ OpenVPN ตรวจสอบเฉพาะเมื่อโปรไฟล์ตั้งค่า --verify-x509-name และนิสัยเก่าที่จับคู่เพียงชื่อทั่วไปจะพังกับใบรับรองที่ตัวตนอาศัยอยู่ใน subjectAltName การติดตั้ง IKEv2 จับคู่ตัวตนที่กำหนดค่าไว้กับรายการ SAN หรือกับชื่อที่แตกต่าง ขึ้นอยู่กับไคลเอนต์ และค่าไวลด์การ์ดหรือ %any จะปิดการเปรียบเทียบที่คุณคิดว่ามีอยู่เงียบ ๆ
ถัดมาคือเวลาและวัตถุประสงค์ แล็ปท็อปที่นาฬิกาเร็วไปหลายชั่วโมงจะปฏิเสธใบรับรองที่ยังไม่ถึงเวลาใช้งาน และใบรับรองกลางที่หมดอายุจะทำให้เส้นทางล้มเหลวในขณะที่ใบยังใช้ได้ ความล้มเหลวด้านวัตถุประสงค์มาจากใบรับรองที่ไม่มี serverAuth ในการใช้คีย์แบบขยาย หรือมี keyUsage ที่ไม่อนุญาตลายเซ็นของการจับมือ ซึ่ง OpenSSL รายงานว่าเป็นวัตถุประสงค์ของใบรับรองที่ไม่รองรับ ออกใหม่จากแม่แบบที่ถูกต้อง ไม่มีสิ่งใดในข้อความนั้นที่เป็นเหตุผลให้ปิดการตรวจสอบ
การเพิกถอนทำงานเฉพาะเมื่อมีคนกำหนดค่าไว้
CRL หรือการตอบกลับ OCSP ไม่ได้ถูกตรวจสอบโดยอัตโนมัติ บนเซิร์ฟเวอร์ OpenVPN ใบรับรองไคลเอนต์จะถูกเทียบกับรายการเฉพาะเมื่อ --crl-verify ชี้ไปที่รายการใดรายการหนึ่ง การตรวจสอบใบรับรองเซิร์ฟเวอร์ฝั่งไคลเอนต์ขึ้นอยู่กับการใช้งานและมักไม่มีอยู่ strongSwan ต้องมีปลั๊กอินการเพิกถอนและนโยบายก่อนจะดู CRL สำหรับคู่
นั่นอธิบายตั๋วที่คุณจะได้รับในที่สุด ใบรับรองไคลเอนต์ที่ถูกเพิกถอนยังเชื่อมต่อได้ และทุกคนสรุปว่าการเพิกถอนเสีย ไม่มีอะไรกำลังตรวจสอบเลย เผยแพร่และรีเฟรช CRL หรือรักษาใบรับรองไคลเอนต์ให้มีอายุสั้นพอที่การเพิกถอนที่ล้าสมัยจะสำคัญเพียงช่วงสั้น ๆ และซ้อมเส้นทางการเพิกถอนบนใบรับรองในห้องปฏิบัติการก่อนที่คุณจะต้องใช้ระหว่างเหตุการณ์
ลำดับการซ่อมที่ทำให้การตรวจสอบยังเปิดอยู่
จัดเรียงตามอาการก่อนแตะไฟล์ เพราะแต่ละแถวของตารางส่งคุณไปยังวัตถุที่แตกต่างกัน
| Client says | Most likely gate | First check |
|---|---|---|
| unable to get local issuer certificate | trust anchor or missing intermediate | your own openssl verify against the files the profile loads |
| expired or not yet valid | validity window | leaf and intermediate dates against the device clock |
| unsupported certificate purpose | extended key usage | serverAuth present, keyUsage allows the handshake |
| name mismatch | peer identity | subjectAltName entries versus the profile name |
ไล่รายการในรอบเดียว ยืนยันไฟล์ที่โปรไฟล์โหลด สร้างเส้นทางด้วยตนเอง ตรวจว่าเซิร์ฟเวอร์ส่งใบรับรองกลางหรือไม่ เปรียบเทียบนาฬิกา อ่าน SAN อ่าน EKU แล้วเชื่อมต่อใหม่และดูบรรทัดบันทึกเดิมหายไป ถ้าอุปกรณ์ไม่สามารถรับ CA ได้เลย การปักหมุดคือทางเลือกที่ซื่อตรง เพราะ OpenVPN 2.6 ยอมรับ --peer-fingerprint และจำกัดความเชื่อถือให้เหลือคีย์เดียวแทนการลบการตรวจสอบออก เอกสารอ้างอิงความหมายของแต่ละฟิลด์เหล่านี้คือ RFC 5280