ข้อผิดพลาดใบรับรองเว็บใน Access Server: ชุด CA ว่างเปล่า
ค่า ca_bundle ว่างหรือ PEM เสียทำให้อินเทอร์เฟซผู้ดูแลหยุดทำงาน ตรวจสอบใบรับรอง คีย์ และห่วงโซ่เป็นชุดเดียวก่อนรีสตาร์ต และอย่าแตะ PKI ของ VPN
หน้าเข้าสู่ระบบเว็บที่ไม่โหลดทั้งที่ DNS แปลงถูกต้องมักไม่ใช่ปัญหา DNS หากบันทึกของบริการระบุเส้นทางชุดใบรับรองว่างหรือการแยกวิเคราะห์ PEM ล้มเหลวสำหรับใบรับรองเว็บและคีย์ส่วนตัว ผู้รับฟัง HTTPS ก็ไม่มีวัสดุที่ใช้ได้และการแปลงชื่อก็ช่วยไม่ได้ การซ่อมอยู่ในคีย์กำหนดค่าสามตัวและไม่ต้องออกใบรับรองไคลเอนต์ VPN ใหม่แม้แต่ใบเดียว
สามคีย์ชี้ไปที่อะไรจริง ๆ
ชุดใบรับรองเว็บที่กำหนดเองอธิบายด้วย cs.cert, cs.priv_key และ cs.ca_bundle แต่ละตัวเก็บเส้นทางไฟล์ และบริการเว็บใช้ทั้งสามร่วมกัน ใบรับรองที่ใช้คีย์ผิด หรือไฟล์ห่วงโซ่ที่เป็นใบรับรองใบจริง ล้มเหลวเหมือนค่าว่าง
คีย์เหล่านี้เป็นของอินเทอร์เฟซเว็บ Admin และ Client แยกจาก PKI ที่ออกใบรับรองให้ไคลเอนต์ VPN จึงไม่ต้องแตะโปรไฟล์ คีย์เซิร์ฟเวอร์ หรือหน่วยออกใบรับรอง การสร้าง PKI ใหม่ทั้งชุดเป็นความผิดพลาดที่แพงที่สุดตรงนี้
ความแตกต่างหนึ่งอย่างประหยัดเวลา: ค่าที่กำหนดเองซึ่งว่างอย่างชัดเจนไม่ใช่สถานะเดียวกับการไม่มีการเขียนทับเลย อย่างแรกให้เส้นทางว่างแก่ตัวแยกวิเคราะห์ ซึ่งเป็นสิ่งที่บรรทัดบันทึกบอก อย่างหลังปล่อยให้ Access Server ใช้วัสดุของตัวเอง
ทำไมไฟล์ที่มีอยู่จึงยังแยกวิเคราะห์ไม่ได้
ตัวแยกวิเคราะห์อ่านบล็อกที่มีป้ายกำกับในไฟล์ ไม่ใช่อ่านชื่อไฟล์ .crt ที่มีคีย์ส่วนตัว ห่วงโซ่ที่เขียนเป็นบล็อกเดียว หรือไฟล์ที่บรรทัดสุดท้ายถูกตัด จะถูกปฏิเสธ RFC 7468 กำหนดป้ายที่อ่านได้เหล่านี้เพราะเป็นสิ่งเดียวที่บอกว่าวัตถุประเภทใดจะตามมา
ตรวจดูวัตถุ ไม่ใช่นามสกุล บนโฮสต์ Linux openssl x509 -noout -subject -issuer -in server.pem และ openssl pkey -noout -check -in key.pem ตอบคำถามสำคัญสองข้อ และการเปรียบเทียบมอดุลัสหรือคีย์สาธารณะพิสูจน์ว่าเข้าคู่กัน เก็บผลลัพธ์คีย์ส่วนตัวให้ห่างจากตั๋วและบันทึกแชต
เส้นทางว่างควรถูกสงสัยพอ ๆ กับไฟล์เสีย เพราะทั้งสองให้ข้อผิดพลาดปลายทางที่คลุมเครือ หากบันทึกบอกว่าเส้นทางชุดว่าง ให้อ่านค่าที่เก็บไว้ก่อนแก้ไขไฟล์
กลับไปใช้ตัวสำรองอย่างตั้งใจ
CLI ของ Access Server มีการตรวจสอบที่รับสามเส้นทางเป็นอาร์กิวเมนต์และรายงานว่าชุดนั้นใช้ได้หรือไม่ เส้นทางด้านล่างเป็นเพียงตัวอย่าง ให้แทนที่ด้วยตำแหน่งที่ป้องกันบนโฮสต์
sacli --ca_bundle=/secure/webcerts/chain.pem \
--cert=/secure/webcerts/server.pem \
--priv_key=/secure/webcerts/key.pem TestWebCertsอ่านผลก่อนแตะบริการที่กำลังทำงาน จากนั้นจึงนำค่าเข้าและใช้งานตามขั้นตอนที่เอกสารไว้สำหรับเวอร์ชันที่ติดตั้ง บทแนะนำ CLI อย่างเป็นทางการ ครอบคลุมการตรวจสอบ การนำเข้า และขั้นตอนใช้งาน และเวอร์ชันของมันสำคัญกว่าบทสรุปใด ๆ
ตรวจสอบชื่อที่ผู้ใช้พิมพ์จริง
เมื่อวัสดุที่กำหนดเองเสียและยังมีตัวสำรองในตัวที่ใช้ได้ การกู้คืนตามเอกสารคือลบการเขียนทับทั้งสามและปล่อยให้ Access Server ใช้ตัวสำรองนั้น เตรียมการเข้าถึงคอนโซลและสำเนาการกำหนดค่าปัจจุบันก่อน
sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this versionการล้างฐานข้อมูลกำหนดค่าทั้งหมดไม่ใช่การซ่อมใบรับรอง ให้เล็งที่สามคีย์นั้น ใช้งาน และยืนยันว่าอินเทอร์เฟซเว็บตอบสนอง ไฟล์ที่ลงนามเองในไดเรกทอรี web-ssl เป็นทรัพยากรสำรอง ไม่ใช่พื้นที่ทำงาน
คาดว่าเบราว์เซอร์จะแสดงใบรับรองอื่นหลังจากตัวสำรองมีผล นั่นคือผลลัพธ์ที่ถูกต้อง ให้ตรวจสอบผ่านกระบวนการบริหารที่เชื่อถือได้
การกู้คืนเสร็จสิ้นเมื่อเข้าสู่ระบบสำเร็จ
การกู้คืนไม่เสร็จเมื่อผู้รับฟัง TCP ปรากฏ ตรวจสอบชื่อ DNS ตัวตนของใบรับรอง และห่วงโซ่ของชื่อนั้น จากนั้นโหลดอินเทอร์เฟซเว็บทั้ง Admin และ Client และเข้าสู่ระบบให้เสร็จ การตรวจพอร์ตไม่ได้พิสูจน์สิ่งเหล่านั้น
Access Server 3.1 ขึ้นไปยังให้บริการใบรับรองเว็บต่างกันตามชื่อโฮสต์ SNI ได้ หากกำหนดไว้ คีย์เริ่มต้นและรายการเฉพาะชื่อจะเป็นชุดแยกกัน และการทดสอบด้วยที่อยู่ IP อาจแสดงใบรับรองต่างจากที่ผู้ใช้ได้รับ แก้ไขและตรวจสอบชุดของชื่อที่ล้มเหลว แล้วทดสอบการเข้าสู่ระบบซ้ำก่อนปิดเหตุการณ์