ใบรับรอง SSTP ไม่ตรงกัน: ชื่อที่เซิร์ฟเวอร์ของคุณต้องนำเสนอ

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

ชื่อในโปรไฟล์เป็นตัวกำหนดว่าจะตรวจอะไร

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

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

สิ่งที่ใบรับรองเซิร์ฟเวอร์ต้องมี

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

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

ตรวจห่วงโซ่และนาฬิกาก่อนข้อมูลเข้าสู่ระบบ

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

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

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

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

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

แก้ไขชื่อหรือใบรับรองแล้วทดสอบใหม่

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

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