เว็บไซต์แสดงใบรับรองผิด? หาตัวผู้รับฟังให้เจอ
ไซต์นำเสนอใบรับรองที่ไม่คาดคิดและไฟล์ที่ดูชัดเจนถูกเขียนทับ ระบุตัวผู้รับฟังและโฮสต์เสมือนที่ตอบก่อน
การติดตั้งซอฟต์แวร์ VPN บนเว็บโฮสต์อาจจัดเรียงบริการใหม่ แต่ใบรับรองที่ไม่คาดคิดไม่ได้พิสูจน์ว่าไฟล์ Apache ถูกเขียนทับ มีบางสิ่งนำใบรับรองนั้นเสนอต่อเบราว์เซอร์ของคุณ และงานแรกคือการระบุชื่อมัน จนกว่าจะระบุตัวผู้รับฟังและโฮสต์เสมือนได้ ทุกการซ่อมคือการเดาที่ใช้กับชั้นผิด การตรวจสอบทั้งหมดด้านล่างเป็นแบบอ่านอย่างเดียว
ไม่มีสิ่งใดถูกเริ่มใหม่ ถอนการติดตั้ง หรือเขียนทับขณะที่คุณรวบรวมข้อเท็จจริงที่ชี้ขาดคดี
อ่านใบรับรองที่เบราว์เซอร์ได้รับจริง
บันทึกชื่อโฮสต์ ที่อยู่ที่แก้ไขได้สำหรับแต่ละตระกูล พอร์ต และรายละเอียดใบรับรองที่เบราว์เซอร์ร้องเรียน ชื่อที่แก้ไขได้ทั้งเรกคอร์ด A และ AAAA อาจไปถึงส่วนหน้าสองส่วนที่ต่างกัน และมีเพียงส่วนเดียวเท่านั้นที่เป็นโฮสต์ที่คุณมีสิทธิ์เข้าถึงเชลล์ เบราว์เซอร์หลังพร็อกซีอาจใช้เส้นทางที่สามอีกครั้ง การเดาว่าสิ่งใดสร้างคำเตือนจะทำให้การสังเกตเพียงอย่างเดียวที่คุณมีสูญเปล่า
จากนั้นทำการจับมือซ้ำจากเครื่องบนเส้นทางเดียวกัน ระบุที่อยู่อย่างชัดเจนและส่งชื่อเซิร์ฟเวอร์ที่ต้องการ เพื่อให้คำตอบสะท้อนไซต์ไม่ใช่โฮสต์เริ่มต้น
openssl s_client -connect 198.51.100.37:443 -servername www.example.net </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -fingerprint -sha256 -ext subjectAltName
เทียบชื่อทางเลือกของ subject และลายนิ้วมือกับใบรับรองที่คุณคาดหวัง ไม่ใช่กับผู้ออกที่คุ้นเคย การเชื่อมต่อกับที่อยู่เปล่าโดยไม่มีชื่อเซิร์ฟเวอร์อาจเลือกใบรับรองเริ่มต้น ซึ่งจะดูเหมือนไฟล์ผิดทั้งที่จริงแล้วคำถามต่างหากที่ผิด
ระบุโปรเซสที่ผูกกับพอร์ตนั้น
บนโฮสต์ที่ควรรับการเชื่อมต่อ ให้ไล่รายการผู้รับฟังและบันทึกที่อยู่ผูก ตระกูลที่อยู่ และเจ้าของโปรเซส บริการที่ผูกกับที่อยู่ลูปแบ็กไม่เหมือนกับบริการที่ผูกกับทุกอินเทอร์เฟซ และการเผยแพร่คอนเทนเนอร์อาจวางผู้รับฟังสาธารณะไว้ที่อื่นโดยสิ้นเชิง
sudo ss -ltnp 'sport = :443'
sudo ss -ltnp | grep -E ':(443|943)\b'
หาก TLS ถูกยุติโดยตัวกระจายโหลดหรือพร็อกซีที่อยู่ข้างหน้า ให้หยุดตรงนี้และตรวจสอบส่วนหน้านั้นแทน อินสแตนซ์ Apache ที่อยู่ข้างหลังอาจไม่เคยเสนอใบรับรองให้เบราว์เซอร์สาธารณะเลย การแก้ไขการกำหนดค่าจึงไม่เปลี่ยนสิ่งที่เบราว์เซอร์เห็น มุมมองซ็อกเก็ตและการจับมือภายนอกต้องอธิบายเส้นทางเดียวกัน และนั่นคือสิ่งที่การเปรียบเทียบนี้พิสูจน์
จับคู่โฮสต์เสมือนก่อนไฟล์
เมื่อ Apache เป็นตัวยุติ ให้ถามว่ามีโฮสต์เสมือนใดชนะสำหรับที่อยู่และชื่อนั้น คำสั่งควบคุมจะพิมพ์เลย์เอาต์ที่มีผล รวมถึงกลุ่มที่ตรงกับแต่ละซ็อกเก็ต ชื่อเซิร์ฟเวอร์ที่ประกาศไว้ และโฮสต์ที่ถือเป็นค่าเริ่มต้น การแก้ไฟล์ใบรับรองโดยไม่มีคำตอบนั้นคือวิธีที่ไซต์ผิดถูกให้บริการจากไฟล์ที่ถูกต้อง
sudo apachectl -S
คำถามที่พบบ่อยเกี่ยวกับ SSL ของ Apache อธิบายว่าการระบุชื่อเซิร์ฟเวอร์เลือกใบรับรองอย่างไร ส่วนหัว Host ของ HTTP มาถึงหลังการจับมือและไม่สามารถย้อนกลับไปเปลี่ยนสิ่งที่เสนอไปแล้วได้ ชื่อที่ไม่ตรงหรือไม่มีจึงตกไปที่โฮสต์เริ่มต้น
โฮสต์เสมือนที่ตั้งชื่อซึ่งมีคำผิดใน ServerAlias ทำให้เกิดอาการนี้พอดี และไฟล์กำหนดค่าไฟล์ที่สองที่โหลดโฮสต์ที่ดักจับทุกอย่างก่อนก็เช่นกัน ทั้งสองมองเห็นได้ในรายการเลย์เอาต์นั้น
ตรวจสอบการแก้ไขบนทุกเส้นทางที่คุณอ้าง
หลังการเปลี่ยนแปลงที่ได้รับอนุมัติ ให้ทำการตรวจสอบเฉพาะชื่อโฮสต์ซ้ำสำหรับแต่ละตระกูลที่อยู่ และปิดท้ายด้วยการตรวจสอบตามปกติของเบราว์เซอร์แทนการใช้แฟล็กข้าม เก็บเส้นทางผู้ดูแลระบบแยกไว้ก่อนแตะการตั้งค่าผู้รับฟังที่ใช้ร่วมกัน เพราะความผิดพลาดตรงนั้นจะตัดสิทธิ์เข้าถึงที่คุณจะใช้เพื่อย้อนกลับ จากนั้นบันทึกว่าผู้รับฟังใดตอบ โฮสต์เสมือนใดตรงกัน และใบรับรองใดถูกให้บริการก่อนและหลัง
การถอนแพ็กเกจอาจเปลี่ยนเลย์เอาต์และทิ้งความไม่ตรงกันเดิมไว้โดยไม่มีคำอธิบาย นั่นคือเหตุผลที่บันทึกนั้นอยู่ได้นานกว่าการซ่อม
สิ่งที่คุณต้องการคือไซต์ที่ตั้งใจไว้ที่จุดเข้าที่ตั้งใจไว้ ใบรับรองที่ต่างออกไปหลังจากบริการที่ไม่เกี่ยวข้องหายไปไม่ใช่ผลลัพธ์นั้น แม้เบราว์เซอร์จะหยุดร้องเรียน