CA ที่ลงนามไขว้: คีย์ตรงกัน แต่การผูก AKI ไม่ตรง

ใบรับรอง CA สองใบสามารถมีคีย์สาธารณะเดียวกันและ subject เดียวกันแต่ยังใช้แทนกันไม่ได้ ใบหนึ่งลงนามด้วยตนเอง อีกใบลงนามไขว้โดยรากเก่า และชื่อผู้ออก หมายเลขซีเรียล และลายเซ็นต่างกัน ใบสามารถผูกกับหนึ่งในสองได้อย่างเฉพาะเจาะจงผ่าน Authority Key Identifier ของตน การผูกนั้นจะมองไม่เห็นจนกว่าลูกค้าจะเลือกห่วงโซ่ผิดและ handshake ล้มเหลวโดยไม่มีสาเหตุชัดเจน

ทำการตรวจห้าข้อนี้ตามลำดับ แต่ละข้อตัดความล้มเหลวที่ต่างกันออกไป

การตรวจ 1: วาดห่วงโซ่ทั้งสองก่อนแตะเทมเพลต

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

สำเนาที่ลงนามไขว้ก็ต้องเป็นใบรับรอง CA จริง โดยมี basic constraints และ key usage ที่อนุญาตให้ลงนาม

การตรวจ 2: เปรียบเทียบฟิลด์ AKI ไม่ใช่แค่คีย์

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

ตรวจดูใบแทนการเดา: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier

จากนั้นเปรียบเทียบผู้สมัครทั้งสองด้วย openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" และคำสั่งเดียวกันกับสำเนาที่ลงนามด้วยตนเอง

ถ้าใบมีผู้ออกและหมายเลขซีเรียล มีเพียงใบรับรองที่ค่าดังกล่าวอธิบายเท่านั้นที่ทำให้ห่วงโซ่สมบูรณ์ ไม่ว่าลูกค้าจะโหลดสำเนาใด

การตรวจ 3: เปลี่ยนนโยบายการออก ไม่ใช่ไบต์ที่ลงนามแล้ว

ส่วนขยายอยู่ภายในลายเซ็น การเพิ่ม ลบ หรือแก้ไขหนึ่งอย่างบนใบที่มีอยู่ไม่ใช่การซ่อมแซม แต่เป็นใบรับรองอื่น และต้องออกใหม่ การเปลี่ยนแปลงอยู่ในนโยบายการออก: authorityKeyIdentifier = keyid,issuer:always ทำให้ใบใหม่มีการผูกเฉพาะใบรับรอง ขณะที่ keyid เพียงอย่างเดียวคงรูปแบบที่หลวมกว่าซึ่งเหมาะกับการเปลี่ยนผ่านการลงนามไขว้โดยเจตนา ตัดสินใจว่า PKI ของคุณต้องการแบบใดก่อนลงนามชุดถัดไป

การแก้ไขเทมเพลตที่ใช้ร่วมกันยังเปลี่ยนใบรับรองในอนาคตทุกใบ ไม่ใช่แค่เซิร์ฟเวอร์ตรงหน้าคุณ

การตรวจ 4: ตรวจสอบแต่ละประชากรความเชื่อถือแยกกัน

ทดสอบเส้นทางเก่าและเส้นทางใหม่เป็นการรันแยกกัน openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem ฝึกเส้นทางที่ลงนามไขว้ และคำสั่งเดียวกันกับรากใหม่และไม่มีไฟล์ untrusted ฝึกเส้นทางที่ลงนามด้วยตนเอง การผสมรากทั้งสองในชุดเดียวซ่อนว่าห่วงโซ่ใดถูกเลือก จากนั้นทำซ้ำกับลูกค้าจริง เพราะ backend ของ VPN อาจชอบห่วงโซ่หนึ่งหรือ ปักหมุดใบรับรอง ในแบบที่ openssl ไม่ทำ

ส่งมอบใบรับรองกลางผ่านการกำหนดค่าบริการที่ลูกค้าอ่านจริง ไม่ใช่ผ่านหน้าวิกิ

การตรวจ 5: เก็บเส้นทางเก่าไว้บนนาฬิกาการปลดระวาง

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

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