remote-cert-tls server: ตรวจอะไรในโปรไฟล์ OpenVPN
ไดเรกทีฟนี้ตรวจบทบาทที่เข้ารหัสอยู่ในใบรับรองของคู่สนทนา ไม่ใช่ชื่อของมัน เปรียบเทียบบทบาท จุดยึดความเชื่อถือ และการตรวจชื่อโฮสต์ก่อนปิดการตรวจสอบใด ๆ
คำถามที่แตกต่างกันสามข้อได้รับคำตอบจากสามส่วนที่แตกต่างกันของโปรไฟล์ OpenVPN และการนำคำถามเหล่านี้มารวมกันคือสาเหตุที่ผู้คนปิดการตรวจสอบที่กำลังทำงานอยู่ ใบรับรองของคู่สนทนาได้รับการลงนามโดยหน่วยงานที่ฉันไว้วางใจหรือไม่ ใบรับรองนั้นประกาศบทบาท TLS server หรือไม่ มันเป็นเซิร์ฟเวอร์เครื่องที่ฉันตั้งใจจะเข้าถึงหรือไม่ remote-cert-tls server ตอบเพียงข้อกลางข้อเดียว และตอบโดยการอ่านส่วนขยายภายในใบรับรอง
การตรวจสอบสามอย่างที่รวมกันในหัวได้ง่าย
จุดยึดความเชื่อถืออยู่ในไดเรกทีฟ ca การตรวจบทบาทเป็นของ remote-cert-tls การตรวจตัวตนเป็นของ verify-x509-name เมื่อโปรไฟล์ใช้งานมัน หรือเป็นของการตรวจชื่อใดก็ตามที่การติดตั้งเพิ่มเข้ามา
การตรวจสอบเหล่านี้ครอบคลุมความล้มเหลวที่แตกต่างกัน:
| Question | Directive | Failure it catches |
|---|---|---|
| Who signed this? | ca | Certificate from an unrelated authority |
| Is this a server? | remote-cert-tls | Client certificate presented by a peer |
| Is this my server? | verify-x509-name | Another valid server from the same CA |
โปรไฟล์สามารถมีทั้งสามอย่างและยังอ่อนแอได้หาก CA ถูกใช้ร่วมกันกว้างเกินไป ซึ่งเป็นคำถามเรื่องการจัดการกุญแจไม่ใช่คำถามเรื่องไดเรกทีฟ
สิ่งที่การตรวจบทบาทอ่าน
ไดเรกทีฟนี้เป็นมาโคร มันขยายเป็นข้อกำหนดการใช้กุญแจและข้อกำหนดการใช้กุญแจแบบขยายที่ระบุบทบาท TLS Web Server ดังนั้นใบรับรองของคู่สนทนาต้องประกาศวัตถุประสงค์นั้นจริง ๆ ใบรับรองที่ออกเพื่อการพิสูจน์ตัวตนของไคลเอนต์ไม่ผ่านข้อกำหนดนี้ แม้หน่วยงานเดียวกันจะลงนามทั้งสองใบก็ตาม
เรื่องนี้สำคัญเพราะ CA ที่ใช้ร่วมกันเป็นเรื่องปกติในการติดตั้งขนาดเล็ก หน่วยงานเดียวลงนามไคลเอนต์ทุกตัวและเซิร์ฟเวอร์ และหากไม่มีการตรวจบทบาท ใบรับรองใด ๆ เหล่านั้นก็สามารถทำส่วนเซิร์ฟเวอร์ของการจับมือให้สำเร็จได้ การตรวจสอบไม่ได้ทำให้สถานการณ์นั้นเป็นไปไม่ได้ แต่ตัดเวอร์ชันง่าย ๆ ของมันออกไป
ไดเรกทีฟนี้ออกแบบมาให้ไม่สมมาตร: ไคลเอนต์ถือ remote-cert-tls server และเซิร์ฟเวอร์ถือ remote-cert-tls client สลับกันแล้วทุกการเชื่อมต่อจะล้มเหลวด้วยข้อผิดพลาดเรื่องบทบาทที่ดูเหมือนใบรับรองเสีย
โปรไฟล์เก่าบางครั้งใช้ ns-cert-type เพื่อจุดประสงค์เดียวกัน หน้าคู่มือปัจจุบันถือว่าตัวเลือกนั้นถูกแทนที่แล้ว ดังนั้น โปรไฟล์ที่ยังพึ่งพามันอยู่จึงควรย้ายระบบมากกว่าจะไล่ดีบัก.
ทำไมการปิดการตรวจจึงรู้สึกเหมือนการแก้ไข
เมื่อการตรวจบทบาทล้มเหลว การเชื่อมต่อจะหยุดด้วยข้อผิดพลาดการตรวจสอบ และสิ่งที่ดูเหมือนทำได้ชัดเจนคือลบบรรทัดนั้นออก จากนั้นการเชื่อมต่อก็ขึ้นมา ซึ่งรู้สึกเหมือนความคืบหน้าและจริง ๆ แล้วคือโหมดความล้มเหลวที่ไดเรกทีฟนี้มีอยู่เพื่อป้องกัน ตอนนี้คุณยอมรับคู่สนทนาที่ใบรับรองไม่เคยถูกตั้งใจให้มีบทบาทนั้น
อ่านข้อผิดพลาดแทน ข้อผิดพลาดระบุการตรวจที่ล้มเหลว และใบรับรองอีกฝั่งสามารถตรวจดูได้ว่ามีส่วนขยายใดจริง ๆ การอ่านสองนาทีก็ตัดสินได้ว่าความผิดอยู่ที่การออกใบรับรองหรือการตั้งค่า การเดาใช้เวลาหนึ่งบ่ายและมักจบลงด้วยโปรไฟล์ที่อ่อนแอลง ใบรับรองเซิร์ฟเวอร์ที่ต่ออายุแล้วแต่สูญเสียส่วนขยายการใช้กุญแจแบบขยายเป็นความผิดจริงในการต่ออายุ ไม่ใช่เหตุผลที่จะผ่อนปรนไคลเอนต์
การตรวจชื่อเป็นไดเรกทีฟแยกต่างหาก
การผ่านการตรวจบทบาทบอกว่าคู่สนทนาเป็นเซิร์ฟเวอร์บางเครื่องที่ลงนามโดยหน่วยงานของคุณ มันไม่ได้บอกว่าเครื่องไหน ซึ่งสำคัญเมื่อ CA เดียวกันออกใบรับรองให้เกตเวย์หลายตัวและตัวหนึ่งถูกบุกรุกหรือนำไปใช้ผิดวัตถุประสงค์
verify-x509-name เปรียบเทียบชื่อเรื่องของใบรับรองกับค่าที่คุณกำหนด โดยมีโหมดการจับคู่สำหรับชื่อเรื่องแบบตรงทั้งหมด คำนำหน้า หรือฟิลด์เดียว ใช้ฟิลด์ที่ระบุเกตเวย์จริง ๆ และคาดว่าจะต้องอัปเดตอย่างตั้งใจเมื่อชื่อเปลี่ยน
ไม่มีไดเรกทีฟใดแทนที่การจัดการกุญแจที่ดี หากไฟล์กุญแจไคลเอนต์ถูกคัดลอกไปพร้อมกับโปรไฟล์ ตัวตนของคู่สนทนาก็แข็งแรงเท่ากับรายชื่อผู้รับแจกจ่ายเท่านั้น
ตรวจใบรับรองก่อนแก้ไขโปรไฟล์
อ่านใบรับรองของคู่สนทนาและล็อกของไคลเอนต์ตามลำดับนั้น ใบรับรองบอกว่าประกาศบทบาทอะไรบ้าง ล็อกบอกว่าการตรวจใดปฏิเสธมัน
คำสั่งเหล่านี้พิมพ์ส่วนขยายการใช้งานและบรรทัดการตรวจสอบจากการเชื่อมต่อแบบละเอียด:
openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verifyหากส่วนขยายแสดงบทบาทเซิร์ฟเวอร์และล็อกยังรายงานความล้มเหลวเรื่องบทบาท โปรไฟล์อาจชี้ไปที่ไฟล์ใบรับรองผิดมากกว่าใบรับรองเสีย หากส่วนขยายแสดงเฉพาะการพิสูจน์ตัวตนของไคลเอนต์ ให้หยุดดูฝั่งไคลเอนต์แล้วแก้ที่การออกใบรับรอง ไม่ว่าทางใด ให้คืนการตรวจสอบก่อนจะบอกว่าการเชื่อมต่อปกติ เพราะการจับมือที่สำเร็จหลังถอดการตรวจสอบพิสูจน์ได้น้อยกว่าข้อผิดพลาดที่มันแทนที่