CSR เดี่ยว ๆ ไม่ใช่การลงทะเบียน: CA ของ VPN ต้องตรวจอะไร

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

รูปแบบการลงทะเบียนสองแบบควรค่าแก่การเปรียบเทียบจากสิ่งที่ผูกไว้ ไม่ใช่จากโปรโตคอลที่พูด

คำขอกล่าวอ้างชื่อ แต่ไม่พิสูจน์ชื่อ

อ่านคำขอตามสิ่งที่มีอยู่จริง: กุญแจสาธารณะ subject ที่ผู้ขอเลือก และลายเซ็นตัวเองบนทั้งสองอย่าง ไม่มีสิ่งใดในโครงสร้างนั้นอ้างถึงบัญชีอุปกรณ์ของท่าน ไดเรกทอรีบัญชี หรือขั้นตอนอนุมัติ subject อย่าง cn=finance-laptop คือสตริงที่ใครบางคนพิมพ์ขึ้น จนกว่าขั้นตอนการออกจะตรวจสตริงนั้นกับบันทึกที่เชื่อถือได้ ใบรับรองก็เป็นเพียงข้อกล่าวอ้างที่มีลายเซ็นแนบมา ความแตกต่างนี้คือเหตุผลทั้งหมดที่มีขั้นตอนการลงทะเบียน

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

เปรียบเทียบรูปแบบจากสิ่งที่ผูกไว้

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

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

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

บันทึกวงจรชีวิตตั้งแต่การออกครั้งแรก

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

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

ตรวจสอบใบรับรองที่ออกแล้ว จากนั้นตรวจการเข้าถึง

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

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

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

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