ใบรับรอง VPN ยังไม่ใช้งานได้: สาเหตุสามประการ ลำดับการตรวจสอบหนึ่งลำดับ
«ยังไม่ใช้งานได้» หมายถึงนาฬิกาของอุปกรณ์ล่าช้า หน้าต่างเริ่มช้ากว่าจริง หรือใบรับรองกลางยังไม่เปิด ตรวจสอบตามลำดับนั้น
คุณเปิดไคลเอนต์ เลือกโปรไฟล์ที่ใช้มาหลายเดือน แล้วมันหยุดด้วย "certificate is not yet valid" ไม่มีอะไรเปลี่ยนในการลงชื่อเข้าใช้ของคุณ และที่เก็บความเชื่อถือมักจะปกติดี: ใบรับรองที่นำเสนอในการจับมือมีหน้าต่างความถูกต้องที่เริ่มช้ากว่าช่วงเวลาที่ผู้ตรวจสอบใช้ สามสถานการณ์ที่แตกต่างกันให้ข้อความเดียวกันนี้ และต้องดำเนินการต่างกัน ลำดับด้านล่างบอกคุณว่าคุณอยู่ในสถานการณ์ใดก่อนที่คุณจะแตะนาฬิกาหรือไฟล์ใบรับรอง
คุณกำลังเจอสาเหตุใดในสามประการ
สาเหตุแรกอยู่ภายในเครื่อง: อุปกรณ์ที่ทำการตรวจสอบมีนาฬิกาที่เร็วกว่าหรือช้ากว่าวันเริ่มต้นของใบรับรอง คุณเห็นได้บนฮาร์ดแวร์ที่แบตเตอรี่ CMOS หมด บนเครื่องเสมือนที่กู้คืนจากสแนปชอตเก่า บนอุปกรณ์ที่ปิดเครื่องนานพอจนเวลาหายไป และบนเครือข่ายที่ NTP ขาออกถูกบล็อกโดยไม่มีใครสังเกต ใบรับรองอาจสมบูรณ์ถูกต้องและยังล้มเหลวด้วยวิธีนี้ได้
สาเหตุที่สองเป็นของผู้ออกใบรับรอง เพราะใบรับรองเริ่มต้นในอนาคตจริง: ออกล่วงหน้า สร้างด้วยเวลาเริ่มต้นที่ระบุชัด หรือลงนามเป็นส่วนหนึ่งของขั้นตอนเปิดใช้งานที่ยังไม่ได้ทำงาน สาเหตุที่สามเสียเวลามากที่สุด เพราะใบปลายยังใช้ได้แต่ใบรับรองอื่นในสายที่นำเสนอใช้ไม่ได้ ข้อผิดพลาดจึงระบุวัสดุที่คุณไม่เคยติดตั้ง
คำถามเดียวแยกทั้งสามออกจากกัน ความล้มเหลวตามอุปกรณ์หรือตามบริการ? เครื่องสองเครื่องในเครือข่ายเดียวกันที่ทำงานต่างกันชี้ไปที่นาฬิกา ไคลเอนต์ทุกตัวล้มเหลวเหมือนกันชี้ไปที่หน้าต่างของใบรับรองและสายที่อยู่ข้างหลัง
อ่านหน้าต่างจากใบรับรองที่นำเสนอจริง
อย่าตรวจไฟล์ PEM ที่หลงเหลือจากการติดตั้งครั้งก่อน ให้ถามบริการถึงสายที่ส่งอยู่ในขณะนี้ openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts พิมพ์ใบรับรองทุกใบในสาย บันทึกบล็อกที่คุณสนใจและเรียก openssl x509 -noout -subject -issuer -dates ตัวหลังพิมพ์ notBefore และ notAfter ซึ่งเป็นสองค่าที่ตัดสิน บน Windows กล่องโต้ตอบใบรับรองของการเชื่อมต่อและ certutil -dump บนไฟล์ที่ส่งออกแสดงฟิลด์เดียวกัน
อ่านทั้งสองปลายของหน้าต่าง ไม่ใช่แค่จุดเริ่มต้น ใบรับรองที่เปิดในอีกสองชั่วโมงกับใบที่ปิดในอีกสองชั่วโมงล้มเหลวด้วยข้อความต่างกันและเกี่ยวข้องกับทีมต่างกัน บันทึกว่าใบรับรองใดถูกระบุในข้อผิดพลาด — ใบปลาย ใบกลาง หรือใบราก — เพราะนั่นตัดสินว่ามีอะไรที่ฝั่งไคลเอนต์แก้ไขได้หรือไม่
คุณยังทดสอบหน้าต่างได้โดยไม่ต้องรอ การตรวจสอบรับเวลาที่ระบุชัดได้: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem ประเมินสาย ณ เวลานั้น เรียกด้วยเวลาปัจจุบันเพื่อจำลองความล้มเหลว แล้วเรียกด้วยเวลาเริ่มต้นของใบรับรองเพื่อยืนยันว่าสายเดิมผ่านเมื่อหน้าต่างเปิด RFC 5280 กำหนดฟิลด์ความถูกต้องและกฎที่ว่าใบรับรองต้องไม่ถูกใช้ภายนอกช่วงนั้น และนั่นคือกฎที่ไคลเอนต์ของคุณเพิ่งบังคับใช้
นาฬิกาของคุณ หรือของพวกเขา
เปรียบเทียบนาฬิกาของอุปกรณ์กับเวลาเริ่มต้นของใบรับรองใน UTC จากแหล่งที่คุณเชื่อถือ date -u ให้เวลานั้น และ timedatectl status บนโฮสต์ systemd ก็รายงานว่านาฬิกาซิงโครไนซ์หรือไม่ บน Windows w32tm /query /status แสดงแหล่งปัจจุบันและการซิงโครไนซ์สำเร็จครั้งล่าสุด เขตเวลาที่แสดงในถาดระบบเป็นการเลือกการแสดงผล ไม่ใช่นาฬิกาที่ผิด ผู้ตรวจสอบเปรียบเทียบช่วงเวลา UTC
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
ถ้านาฬิกาล่าช้า ให้ซิงโครไนซ์ใหม่และทดสอบใหม่ก่อนเปลี่ยนวัสดุใบรับรองใด ๆ อุปกรณ์ที่คลาดเคลื่อนหลายนาทีหรือหลายชั่วโมงจะปฏิเสธใบรับรองที่ออกใหม่ทุกใบที่พบ ไม่ใช่เพียงบริการเดียว คำอธิบายแบบบริการเดียวจึงมักผิด ถ้านาฬิกาถูกต้องและซิงโครไนซ์แล้ว ให้หยุดดูอุปกรณ์: หน้าต่างเป็นของผู้ออก และไม่ควรปรับการตั้งค่าภายในเครื่องใด ๆ เพื่อให้ผ่าน
ตารางนั้นคือการตัดสินใจทั้งหมด การเลื่อนนาฬิกาไปตามที่ใบรับรองคาดหวังไม่ใช่การซ่อม และการปิดการตรวจเวลาไม่ใช่การซ่อมเช่นกัน เพราะทั้งสองซ่อนเงื่อนไขที่ทำให้เกิดข้อผิดพลาด
ทำไมสายจึงล้มเหลวในขณะที่ใบปลายดูปกติ
ใบปลายที่ต่ออายุและใบกลางทดแทนมักถูกส่งมาพร้อมกัน และไม่ได้มาถึงพร้อมกันเสมอ บริการอาจส่งใบปลายใหม่ที่ลงนามโดยใบกลางซึ่งหน้าต่างของตัวเองเริ่มช้ากว่า หรือยังคงให้บริการใบกลางเก่าภายใต้ใบปลายใหม่ ไม่ทางใดก็ทางหนึ่งสายล้มเหลวในขณะที่วันที่ของใบปลายเองดูสมเหตุสมผล
ปลายทางที่กระจายโหลดทำให้สิ่งนี้เปลี่ยนจากพังเป็นไม่สอดคล้อง ถ้าการลองใหม่สำเร็จ หรือเครือข่ายหนึ่งทำงานแต่อีกเครือข่ายไม่ทำงาน ให้บันทึกว่าเพียร์ใดตอบและส่งสายใดก่อนเปลี่ยนการตั้งค่า openssl s_client พิมพ์ที่อยู่ที่เชื่อมต่อ ดังนั้นการลองไม่กี่ครั้งจะเผยว่าทุกโหนดให้สายเดียวกันหรือไม่
เส้นทางการซ่อมที่รักษาการตรวจสอบไว้
ปัญหานาฬิกาแก้ได้บนอุปกรณ์โดยเปิดการตรวจสอบไว้ ปัญหาใบรับรองแก้โดยผู้ดูแลด้วยวัสดุที่ออกสำหรับหน้าต่างที่มีอยู่แล้วตอนนี้ ไม่มีการตั้งค่าไคลเอนต์ใดทำให้ใบรับรองที่ยังไม่ถูกต้องกลายเป็นถูกต้อง ธงที่ข้ามการตรวจเวลาไว้เพื่อยืนยันการวินิจฉัย ไม่ใช่เพื่อนำไปใช้จริง
เมื่อใบรับรองถูกเตรียมไว้สำหรับการเปิดใช้งานตามแผน ให้ทำตามแผนการเปลี่ยนผ่าน ติดตั้งเมื่อหน้าต่างเปิด หรือใช้ขั้นตอนการซ้อนทับที่ผู้ให้บริการจัดทำเอกสารไว้ แทนที่จะติดตั้งล่วงหน้าและสอนผู้ใช้ให้คลิกผ่านคำเตือน คำเตือนที่ผู้คนเรียนรู้ที่จะเพิกเฉยมีราคาแพงกว่าความล่าช้าสั้น ๆ
สุดท้าย ทดสอบใหม่ในแบบที่ความล้มเหลวเกิดขึ้น: เซสชันใหม่ ไคลเอนต์เดิม ทรัพยากรที่คุณต้องการจริง ไลบรารี TLS อาจแคชสายที่ตรวจสอบแล้วตลอดอายุการเชื่อมต่อ และเซสชันที่กลับมาใช้ต่อไม่จำเป็นต้องตรวจสอบอีกครั้ง เซสชันเก่าจึงอาจยังล้มเหลวหลังการซ่อมหรือยังทำงานหลังเกิดรีเกรสชัน ไฟล์ที่เปิดในโปรแกรมดูพิสูจน์เพียงว่าไฟล์อ่านได้ การจับมือที่สมบูรณ์พิสูจน์ว่าสายผ่านการตรวจสอบ
ก่อนปิดตั๋ว ให้ยืนยันสี่อย่าง: เวลา UTC และสถานะการซิงโครไนซ์ของอุปกรณ์ที่ล้มเหลว ค่า notBefore และ notAfter ของใบรับรองแต่ละใบในสายที่นำเสนอ สายเดียวกันจากไคลเอนต์ตัวที่สอง และชื่อที่ข้อผิดพลาดให้กับใบรับรอง ถ้านาฬิกาถูกต้องและหน้าต่างยังไม่เปิด ส่วนที่เหลือเป็นงานของผู้ดูแล และสิ่งที่ถูกต้องฝั่งคุณคือรอหน้าต่างแทนที่จะทำให้การตรวจสอบอ่อนลง