ใบรับรอง VPN ที่ต่ออายุแล้ว: ไคลเอนต์บางตัวยังคงปฏิเสธ

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

การต่ออายุครั้งเดียว พฤติกรรมสองแบบ

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

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

การต่ออายุแทนที่วัตถุ ไม่ใช่แค่วันที่

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

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

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

อ่านว่าอะไรคือสิ่งที่ไคลเอนต์ปักหมุด

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

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

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

เปรียบเทียบใบรับรองที่แต่ละแบ็กเอนด์ให้บริการ

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

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

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

เปลี่ยนความเชื่อถือผ่านเส้นทางที่จัดการ

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

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