หน้าเข้าสู่ระบบเว็บที่ไม่โหลดทั้งที่ 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 อาจแสดงใบรับรองต่างจากที่ผู้ใช้ได้รับ แก้ไขและตรวจสอบชุดของชื่อที่ล้มเหลว แล้วทดสอบการเข้าสู่ระบบซ้ำก่อนปิดเหตุการณ์

บทความที่เกี่ยวข้อง