ใบรับรองไคลเอนต์ที่ลงนามเอง? เซิร์ฟเวอร์ VPN ยังคงปฏิเสธ

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

ความไว้วางใจอยู่ที่เซิร์ฟเวอร์ ไม่ใช่ในโปรไฟล์ของคุณ

การพิสูจน์ตัวตนด้วยใบรับรองคือการเปรียบเทียบ ไคลเอนต์แสดงใบรับรอง เกตเวย์ตรวจสอบว่าลงนามโดย CA ตัวใดตัวหนึ่งในการกำหนดค่าหรือไม่

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

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

ทำไมใบรับรองที่ลงนามเองจึงใช้แทนไม่ได้

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

เกตเวย์ไม่ได้ถามว่าใบรับรองสอดคล้องภายในหรือไม่ แต่ถามว่าผู้ออกที่เชื่อถือได้ลงนามหรือไม่

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

เส้นทาง CSR รักษากุญแจส่วนตัวของคุณ

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

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

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

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

ชุดถูกนำเข้า ไม่ได้ติดตั้ง

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

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

เพิ่มการตรวจสอบที่ผู้ให้บริการอาจข้ามไป

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

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

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

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

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