OpenVPN ใบรับรองหมดอายุหรือไม่? ตรวจสอบนาฬิกาก่อน แล้วจึงตรวจใบรับรอง

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

เริ่มจากนาฬิกาบนอุปกรณ์

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

date -u
timedatectl status

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

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

อ่านบรรทัดข้อผิดพลาดก่อนโปรไฟล์

เก็บข้อความไว้ให้แม่นยำ ความล้มเหลวในการตรวจสอบของ OpenVPN ระบุความลึกและเหตุผล และสองฟิลด์นั้นบอกคุณว่าใครต้องลงมือ

VERIFY ERROR กับ error=certificate has expired คือความล้มเหลวด้านความถูกต้อง ณ จุดหนึ่งในเชน นี่ ไม่ใช่การปฏิเสธรหัสผ่านและไม่ใช่การหมดเวลา และทั้งสามต้องได้รับการตอบสนองต่างกัน

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

ค้นหาใบรับรองที่หมดอายุ

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

พิมพ์วันที่ของไฟล์ที่โปรไฟล์อ้างถึงจริง เริ่มจากไฟล์ที่ความลึกที่ระบุในข้อผิดพลาด

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl x509 -in ca.crt -noout -subject -dates

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

ต่ออายุผ่านผู้ออก

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

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

การต่ออายุตัวตนหนึ่งไม่ควรต้องแทนที่ลำดับชั้นความเชื่อถือ หากมีคนเสนอ CA ใหม่เพื่อซ่อมใบเดียวที่หมดอายุ ให้ถามก่อนว่าอะไรอื่นขึ้นอยู่กับตัวเก่า กฎด้านความถูกต้องและเส้นทางของ RFC 5280 คือแบบจำลองที่ทั้งสองฝ่ายปฏิบัติตาม

ทำให้ไคลเอนต์ใช้ตัวแทน

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

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

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