ใช้ CA องค์กรที่มีอยู่ของคุณสำหรับ peer ของ OpenVPN

OpenVPN ไม่มีสิ่งใดกำหนดให้ใบรับรองต้องมาจาก Easy-RSA และกลุ่มอุปกรณ์ที่มี PKI ขององค์กรอยู่แล้วโดยปกติไม่ควรสร้างชุดที่สอง งานจริงไม่ใช่การเลือกเครื่องมือ แต่คือการตัดสินว่าเอกลักษณ์ที่ออกให้หมายถึงอะไร tunnel ยอมรับ peer รายใด และการต่ออายุกับการเพิกถอนมาถึงผู้ตรวจสอบอย่างไร ทำตามห้าขั้นตอนด้านล่างตามลำดับ เพราะขั้นตอนหลังไม่สามารถแก้ไขการตัดสินใจเรื่องบทบาทที่ทำในขั้นแรกได้

ออกสองบทบาทแทนหนึ่งเอกลักษณ์ที่ใช้ร่วมกัน

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

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

เชื่อมต่ออินพุตความเชื่อถือในแต่ละฝ่าย

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

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

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

ส่งมอบใบรับรองระดับกลางโดยไม่ขยายความเชื่อถือ

ทั้งสองฝ่ายไม่จำเป็นต้องใช้ห่วงโซ่การออกใบรับรองเดียวกัน เมื่อ peer นำเสนอใบรับรองที่ลงนามโดยใบรับรองระดับกลาง ฝ่ายตรวจสอบต้องมีใบรับรองระดับกลางนั้นพร้อมใช้ และ OpenVPN แยกแยะอินพุตสมอความเชื่อถือจากใบรับรองเพิ่มเติมที่ใช้เพื่อทำให้ห่วงโซ่ที่นำเสนอในเครื่องสมบูรณ์. เอกสารอ้างอิงตัวเลือก TLS ของ OpenVPN 2.6 อธิบายทั้งสองอย่าง

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

ตกลงกับทีม PKI ว่าการต่ออายุและการเพิกถอนมาถึงผู้ตรวจสอบ VPN อย่างไร รวมถึงผู้ออกใบรับรองรายใดสำคัญและใครเผยแพร่รายการ จุดกระจาย CRL ที่ฝังอยู่ในใบรับรองเป็นคำสั่ง ไม่ใช่หลักฐานว่ามีบางสิ่งดึงมันมา

ตัดสินใจว่าการเพิกถอนมาถึงจริงอย่างไร

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

จดบันทึกเวลาการแพร่กระจายที่คาดไว้และทดสอบด้วยใบรับรองที่คุณยินดีเพิกถอน หากไม่สามารถรีเฟรชรายการบนโฮสต์ VPN ได้ ทางเลือกคืออายุการใช้งานที่สั้นลงบวกกับกระบวนการต่ออายุที่ทำงานจริง ไม่ใช่สมมติฐานว่าการเพิกถอนทำงานเพราะมี URL

พิสูจน์การยอมรับด้วยไคลเอนต์จริง

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

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