openssl ca: วันที่หมดอายุไม่ถูกต้องใน index.txt และวิธีแก้ไข
CA ปฏิเสธที่จะออกใบรับรองเพราะบรรทัดหนึ่งใน index.txt ไม่สามารถแยกวิเคราะห์ได้ คัดลอกสถานะของ CA ถอดรหัสรายการ แล้วกระทบยอดกับใบรับรองที่ลงนามแล้ว
การรันออกใบรับรองหยุดที่ entry 22: invalid expiry date ทั้งที่คำขอที่อยู่ตรงหน้าคุณถูกต้องสมบูรณ์ ข้อร้องเรียนมาจากตัวแยกวิเคราะห์ฐานข้อมูลของ CA ไม่ใช่จาก CSR และไม่ใช่จากไคลเอนต์ VPN ที่จะนำใบรับรองไปแสดงในที่สุด ความแตกต่างนี้กำหนดทุกอย่างที่ตามมา เพราะระเบียนผิดรูปแบบ การซ่อมแซมจึงอยู่ในสถานะของ CA ไม่ใช่ในคำขอหรือการกำหนดค่าของคู่ สิ่งที่ต้องทำคือมองรายการที่ระบุหมายเลขนั้นเป็นบรรทัดหนึ่งใน index.txt และปัญหาก็หดเหลือเป็นคำถามเรื่องข้อมูลที่มีขอบเขตและมีคำตอบที่ตรวจสอบได้
อ่านข้อผิดพลาดให้เป็นข้อร้องเรียนเรื่องฐานข้อมูล
ทุก openssl ca การเรียกจะไล่ผ่านฐานข้อมูลข้อความของตนก่อนที่จะลงนามสิ่งใด ในแต่ละบรรทัดมีตัวอักษรสถานะ การประทับเวลาการหมดอายุ การประทับเวลาการเพิกถอนซึ่งไม่บังคับ หมายเลขลำดับในรูปเลขฐานสิบหก ชื่อไฟล์ และชื่อ subject เมื่อฟิลด์ใดฟิลด์หนึ่งแยกวิเคราะห์ไม่ได้ คำสั่งจะรายงานหมายเลขบรรทัดและหยุดแทนที่จะเดาส่วนที่เหลือของระเบียน
การหยุดนั้นเป็นการป้องกันไม่ใช่ความจู้จี้ ระเบียนที่เครื่องมืออ่านไม่ได้ทำให้เครื่องมือตัดสินไม่ได้ว่ามี subject ที่ขออยู่แล้วหรือไม่ มีการออกหมายเลขลำดับไปแล้วหรือไม่ หรือ CRL ครั้งถัดไปควรมีอะไร การเดินผ่านบรรทัดที่เสียไปจะสร้างความไม่สอดคล้องเงียบ ๆ ที่จะโผล่ขึ้นมาหลายเดือนให้หลัง ซึ่งมักเกิดตอนเพิกถอนใบรับรองที่ไม่มีใครอธิบายได้ อ่านข้อความนั้นเป็นข้อร้องเรียนเรื่องข้อมูล แล้วการสอบสวนก็ยังอยู่ในไดเรกทอรีของ CA
คัดลอกสถานะของ CA ก่อนแตะต้องสิ่งใด
จดภาพรวมของไดเรกทอรี CA ทั้งหมด ไม่ใช่แค่ไฟล์ฐานข้อมูล ดัชนี ไฟล์แอตทริบิวต์ของดัชนี ไฟล์หมายเลขลำดับและหมายเลข CRL คีย์ส่วนตัว และใบรับรองที่ออกแล้ว ล้วนมีส่วนในงานขั้นต่อไป และการซ่อมแซมที่คืนค่าอย่างหนึ่งแต่พลาดอย่างอื่นจะสร้างเหตุการณ์ที่สอง ใช้ขั้นตอนสำรองข้อมูลของ CA เองหากมี และหยุดการออกใบรับรองตามกำหนดไว้ตลอดเวลาที่ทำงาน
บันทึกบิลด์ OpenSSL และไฟล์กำหนดค่าที่คำสั่งที่ล้มเหลวโหลดจริง การติดตั้งมักเก็บไดเรกทอรี CA มากกว่าหนึ่งแห่ง และข้อผิดพลาดจะมีความหมายก็ต่อเมื่อเทียบกับฐานข้อมูลที่การกำหนดค่าที่เลือกระบุไว้
ค้นหารายการนั้นและถอดรหัสฟิลด์วันที่
หมายเลขบรรทัดที่รายงานนับจากระเบียนแรก ดังนั้น sed -n '22p' index.txt จึงตกที่รายการที่มีปัญหาเมื่อคุณยืนยันแล้วว่าไม่มีบรรทัดว่างหรือบรรทัดความคิดเห็นอยู่ข้างบน พิมพ์บรรทัดนั้นพร้อมตัวคั่นที่มองเห็นได้ เพราะแท็บและช่องว่างท้ายบรรทัดเป็นเรื่องปกติและมองไม่เห็นในหน้าต่างเอดิเตอร์ทั่วไป
ฟิลด์การหมดอายุคือการประทับเวลาที่ความกว้างขึ้นกับปี ค่าถึงปี 2049 เขียนในรูปแบบ UTCTime เป็น YYMMDDHHMMSSZ ส่วนค่าที่หลังจากนั้นเปลี่ยนไปใช้ GeneralizedTime ที่มีปีสี่หลัก ระเบียนที่ผสมสองรูปแบบ หรือมีปีสองหลักในตำแหน่งที่ตัวแยกวิเคราะห์ตอนนี้คาดว่าสี่หลัก จะล้มเหลวตรงจุดนี้พอดี เช่นเดียวกับฟิลด์ที่ถูกตัดทอนซึ่งเหลือจากการเขียนที่ถูกขัดจังหวะ
เปรียบเทียบระเบียนกับใบรับรองที่มันอ้างถึง ไม่ใช่กับไฟล์ของ CA อื่น ใบรับรองที่ลงนามแล้วคือผู้มีอำนาจว่าความถูกต้องควรระบุอะไร และมันมีอยู่แล้วในฐานะวัตถุที่แยกวิเคราะห์ได้
ซ่อมแซมระเบียนโดยยึดใบรับรองที่ลงนามแล้ว
อ่านวันที่จริงด้วย openssl x509 -in issued.pem -noout -dates -serial -subject จากนั้นแปลง notAfter ให้เป็นความกว้างของการประทับเวลาที่บิลด์ของคุณเขียนสำหรับปีนั้น และยืนยันว่าหมายเลขลำดับตรงกับรายการที่คุณกำลังจะแก้ไขก่อนเปลี่ยนสักตัวอักษร
แก้เฉพาะฟิลด์ที่เสีย คงตัวอักษรสถานะและหมายเลขลำดับไว้ และปล่อยส่วนที่เหลือของบรรทัดไว้ หากกระทบยอดระเบียนกับใบรับรองที่ลงนามแล้วไม่ได้เลย ให้ถือว่าเป็นรายการที่หลงมาและปลดระวางผ่านเส้นทางการเพิกถอนของ CA เอง แทนการลบบรรทัดด้วยมือ
อย่าซ่อมด้วยการตัดวันที่ให้พอดีกับข้อสันนิษฐานเรื่องปี การตัดสองอักขระไม่สามารถพอร์ตข้ามบิลด์ได้ และมันเปลี่ยนความถูกต้องที่ฐานข้อมูลรายงานต่อการตรวจ subject ซ้ำและ CRL ในอนาคตอย่างเงียบ ๆ เมื่อกู้ค่าเดิมไม่ได้ ให้ออกใบรับรองใหม่ภายใต้หมายเลขลำดับใหม่ และจดไว้ว่าทำไมของเดิมจึงถูกทิ้ง ร่องรอยการตรวจสอบเป็นส่วนหนึ่งของการซ่อมแซม ไม่ใช่เอกสารที่ล้อมรอบมัน
ตรวจสอบการออกใบรับรองและการสร้าง CRL ก่อนจากไป
รันการออกใบรับรองหนึ่งครั้งด้วยการกำหนดค่าเดิม และยืนยันว่าจบลงโดยไม่มีข้อร้องเรียนเรื่องหมายเลขบรรทัด จากนั้นสร้าง CRL ด้วย openssl ca -gencrl -config openssl.cnf และตรวจว่ามันแยกวิเคราะห์ได้ เพราะระเบียนที่เสียหายมักโผล่ขึ้นที่นั่น ไม่ใช่ตอนลงนาม
ตรวจดูใบรับรองใหม่ด้วย openssl x509 -noout -dates -serial และเทียบกับบรรทัดที่ CA เพิ่งเขียนลงไป ยืนยันว่าตัวอักษรสถานะและวันที่หมดอายุตรงกับใบรับรอง และยืนยันว่า openssl verify -CAfile ca.pem issued.pem กลับมาโดยไม่มีข้อผิดพลาด จากนั้นคืนการออกใบรับรองตามกำหนดและเฝ้าดูการรันครั้งแรก เพราะบรรทัดที่ผิดรูปแบบบรรทัดที่สองจะประกาศตัวทันที