AWS Client VPN: ใบรับรองเซิร์ฟเวอร์กับบทบาทของใบรับรองไคลเอนต์
ใบรับรองเซิร์ฟเวอร์ของจุดปลายยืนยันบริการ การพิสูจน์ตัวตนทั้งสองฝ่ายเพิ่มอัตลักษณ์ของไคลเอนต์แต่ละรายและความเชื่อถือใน CA โดยไม่แชร์คีย์ของเซิร์ฟเวอร์
จุดปลายของ Client VPN จำเป็นต้องมีใบรับรอง TLS ของเซิร์ฟเวอร์เสมอ นั่นคืออัตลักษณ์ที่จุดปลายที่จัดการแสดงเมื่อไคลเอนต์เชื่อมต่อ เป็นวัตถุคนละอย่างกับใบรับรองที่ไคลเอนต์แต่ละรายแสดงเมื่อใช้การพิสูจน์ตัวตนทั้งสองฝ่าย การสลับสับสนสองสิ่งนี้คือสาเหตุที่พบบ่อยที่สุดที่ทำให้การตั้งค่า ACM ที่ถูกต้องในด้านอื่นยังล้มเหลวในการเชื่อมต่อครั้งแรก
ต่อไปนี้คือการไล่จากคอนโซลออกไปข้างนอก ตามลำดับที่การเชื่อมต่อเดินจริง
สองบทบาท หนึ่งจุดปลาย
จุดปลายมีอัตลักษณ์ของเซิร์ฟเวอร์ และอาจมีวิธีตรวจสอบอัตลักษณ์ของไคลเอนต์ด้วย ทั้งสองอย่างตั้งค่าแยกกัน อย่างหนึ่งตัดสิน ว่าไคลเอนต์ไว้ใจบริการได้หรือไม่ อีกอย่างหนึ่งตัดสินว่าบริการยอมรับไคลเอนต์หรือไม่
| Material | Purpose | Where it lives |
|---|---|---|
| Server certificate and private key | The managed endpoint proves its TLS identity | ACM, in the endpoint's Region |
| Client certificate and matching key | An individual client proves its identity | On the device |
| CA trust material | The verifier checks the issuer chain | Selected for the client role |
อ่านตารางเป็นข้อกำหนดอิสระสามข้อ ไม่ใช่ใบรับรองเดียว ใบรับรองเซิร์ฟเวอร์และคีย์ส่วนตัวยังอยู่กับบริการ ใบรับรองไคลเอนต์และคีย์ส่วนตัวที่คู่กันอยู่บนอุปกรณ์ วัสดุ CA คือสิ่งที่ผู้ตรวจใช้ตรวจสอบห่วงโซ่ มีเพียงแถวกลางเท่านั้นที่เคยเป็นของแล็ปท็อป
ใบรับรองเซิร์ฟเวอร์ของ ACM ทำอะไร
เมื่อสร้างจุดปลาย ใบรับรองเซิร์ฟเวอร์ต้องพร้อมใช้ใน ACM ในภูมิภาคเดียวกับจุดปลาย คอนโซลขอ ARN และ ARN นั้นต้องแก้ได้ที่นั่น ACM เก็บใบรับรองที่คุณจัดหาด้วยการตรวจสอบโดเมน หรือใบรับรองที่คุณนำเข้าพร้อมคีย์และห่วงโซ่ได้ ทั้งสองแบบใช้ได้ในบทบาทนี้ ต่างกันที่การต่ออายุและใครถือคีย์ส่วนตัว
เลือกเส้นทางการจัดหาที่ตรงกับว่าใครต่ออายุใบรับรองได้ ไม่ใช่เส้นทางที่บังเอิญสร้างไฟล์ที่ดูเหมือนใช้ได้
การพิสูจน์ตัวตนทั้งสองฝ่ายเพิ่มอะไร
การเลือกพิสูจน์ตัวตนไคลเอนต์ด้วยใบรับรองเพิ่มคำถามที่สอง คือไคลเอนต์ใดได้รับอนุญาตให้เชื่อมต่อ ไคลเอนต์แต่ละรายแสดงใบรับรองของตนเองและพิสูจน์ว่าถือคีย์ส่วนตัวที่คู่กัน อัตลักษณ์ที่แยกกันคือสิ่งที่ทำให้การเพิกถอนแบบเลือกได้ทำได้ในภายหลัง การคัดลอกคีย์ไคลเอนต์เดียวไปยังทุกอุปกรณ์ทิ้งคุณสมบัตินั้นอย่างเงียบ แม้จะได้ใบรับรองเซิร์ฟเวอร์มาอย่างสมบูรณ์แบบ
วิธีพิสูจน์ตัวตนของจุดปลายเป็นทางเลือก ไม่ใช่ข้อกำหนดสากล
Active Directory และการพิสูจน์ตัวตนแบบเฟเดอเรตตอบคำถามเดียวกันด้วยวิธีอื่น สูตรใบรับรองทั้งสองฝ่ายไม่ใช่การออกแบบการเข้าสู่ระบบสำหรับการติดตั้งเหล่านั้นโดยอัตโนมัติ และการตรวจสอบ TLS ของเซิร์ฟเวอร์ยังคงอยู่ไม่ว่าจะรับผู้ใช้เข้ามาอย่างไร
ทำไม ARN ของ CA เดียวกันจึงไม่ใช่การแชร์คีย์
AWS ระบุว่าเมื่อใบรับรองเซิร์ฟเวอร์และไคลเอนต์ออกโดย CA เดียวกัน สามารถใช้ ARN ของใบรับรองเซิร์ฟเวอร์ในการเลือกใบรับรองไคลเอนต์ได้ด้วย ประโยคนั้นพูดถึงห่วงโซ่ที่จุดปลายเชื่อถือเมื่อตรวจสอบ ไม่ได้บอกให้ไคลเอนต์ใช้คีย์ส่วนตัวของเซิร์ฟเวอร์ แล็ปท็อปยังต้องมีใบรับรองไคลเอนต์ของตนเองและคีย์ที่คู่กันของตนเอง
เมื่อ CA ของไคลเอนต์เป็นผู้ออกรายอื่น เส้นทางที่เอกสารระบุคือการนำเข้า CA นั้นใน ACM และเลือก CA นั้นสำหรับบทบาทไคลเอนต์
ไล่ความล้มเหลวกลับไปยังขั้นตอน
ระบุว่าขั้นตอนใดล้มเหลวก่อนจะเปลี่ยนสิ่งใด ถ้าไคลเอนต์ปฏิเสธจุดปลาย ผู้ต้องสงสัยคือ ARN ของเซิร์ฟเวอร์หรือห่วงโซ่ของมัน ถ้าจุดปลายปฏิเสธไคลเอนต์ ให้ดูใบรับรองไคลเอนต์ ผู้ออก และวิธีพิสูจน์ตัวตนที่เลือก ถ้าอุโมงค์ขึ้นมาแล้วแต่การรับส่งยังล้มเหลว แปลว่าคุณผ่านเรื่องใบรับรองไปแล้ว
เปลี่ยนทีละวัตถุ เพราะการสลับทั้งสองปลายพร้อมกันจะสร้างความกำกวนเดิมขึ้นมาใหม่
ตรวจสอบอัลกอริทึมคีย์ที่บริการรองรับและส่วนขยายที่จำเป็นสำหรับบทบาทเฉพาะด้วย ใบรับรองที่ตอบโจทย์เว็บไซต์สาธารณะไม่ใช่หลักฐานว่าข้อกำหนดอัตลักษณ์ทั้งหมดของ Client VPN ได้รับการตอบสนอง
จดว่าฟิลด์ใดถือ ARN ใด CA ใดออกใบรับรองไคลเอนต์ และจุดปลายใช้วิธีพิสูจน์ตัวตนใดจริง สามบรรทัดของบันทึกทำให้การต่ออายุครั้งหน้าเป็นงานหนึ่ง ไม่ใช่การสอบสวน