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

สามเงื่อนไขกำหนดรูปแบบของการต่ออายุ

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

เริ่มจากการตรวจสอบใบรับรองที่คุณมี openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName พิมพ์หัวเรื่อง ผู้ออก ช่วงเวลาที่ใช้ได้ และชื่อที่ใบรับรองใช้ได้จริง ฟิลด์สุดท้ายสำคัญที่สุดและถูกสมมติบ่อยที่สุด คำขอต่ออายุที่ละเว้น SAN ที่ไคลเอนต์พึ่งพาจะให้ใบรับรองที่ถูกต้องทางเทคนิคแต่ผิดทางการใช้งาน คัดลอกรายการ SAN จากใบรับรองเก่าลงในคำขอแทนการพิมพ์ใหม่จากความจำ

เงื่อนไขที่หนึ่ง: มีสิ่งใดปักหมุดใบหรือไม่

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

ค้นหาว่าคุณอยู่ในกรณีใดก่อนสั่งซื้อสิ่งใด หมุดที่ไม่มีใครบันทึกไว้ก็ยังเป็นหมุดเมื่อมันแตก

เงื่อนไขที่สอง: เปรียบเทียบหมุดและห่วงโซ่

ลายนิ้วมือทำให้หมุดตรวจสอบได้: openssl x509 -noout -fingerprint -sha256 -in server.crt บนใบรับรองเก่าและใหม่ และ openssl x509 -noout -pubkey เพื่อเปรียบเทียบกุญแจสาธารณะ หากการกำหนดค่าไคลเอนต์ โปรไฟล์มือถือ หรือที่เก็บความไว้วางใจของอุปกรณ์มีค่าใดค่าหนึ่ง คุณมีหมุด โปรไฟล์ VPN บนมือถือเป็นที่ซ่อนทั่วไป เพราะโปรไฟล์ถูกเผยแพร่ครั้งเดียวและไม่ถูกตรวจสอบอีก

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

ตรวจสอบห่วงโซ่ที่เซิร์ฟเวอร์ส่งจริงด้วย openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts และตรวจสอบภายในด้วย openssl verify -CAfile ca.pem -untrusted chain.pem server.crt การทำเช่นนี้ก่อนการเปลี่ยนแปลงจะให้เส้นฐานสำหรับเปรียบเทียบภายหลัง

เงื่อนไขที่สาม: ใครอื่นตรวจสอบชื่อ

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

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

มีกับดักด้านเวลาด้วย ตรวจสอบจุดเริ่มต้นของความถูกต้องเช่นเดียวกับการหมดอายุ เพราะใบรับรองที่เตรียมไว้สำหรับการเปิดใช้งานภายหลังจะถูกปฏิเสธหากติดตั้งเร็วเกินไป และข้อผิดพลาดดูเหมือนปัญหาเรื่องนาฬิกาไม่ใช่ปัญหาเรื่องการเตรียม openssl x509 -noout -dates บนไฟล์ใหม่ก่อนนำไปใช้คือการตรวจสองวินาที เก็บเส้นทางการกู้คืนที่รองรับและการกำหนดค่าที่รู้ว่าดีไว้ด้วย เพื่อให้การต่ออายุที่ผิดพลาดสามารถย้อนกลับได้โดยการคืนใบรับรองและกุญแจก่อนหน้า

นำไปใช้ ตรวจสอบด้วยการพิสูจน์ตัวตนใหม่ แล้วจึงปลดระวาง

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

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

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

บทความที่เกี่ยวข้อง