บริการหลายชื่ออาจอยู่หลัง proxy เครื่องเดียวกัน ทุกชื่อจึงพาไป IP เดียวได้โดยยังเป็นคนละเว็บไซต์ แต่เมื่อเปิดผ่าน HTTPS ยังมีอีกขั้นที่ต้องเลือกและตรวจ certificate ก่อนถึงการทำงานของหน้าเว็บ
ปัญหาที่ดูเหมือนชื่อเว็บถูกแล้วจึงเกิดได้หลายทาง เช่น proxy ส่งใบของอีกชื่อมา หรือส่งใบที่ชื่อถูกแต่ client สร้างสายความเชื่อถือไม่ได้ การเห็นไฟล์ certificate อยู่ในเครื่องไม่พอจะบอกว่าช่องทางที่ผู้ใช้เข้าผ่านกำลังใช้ใบเดียวกัน
ควรแยกการเลือกใบรับรองกับการยอมรับใบรับรองก่อนครับ เพราะ SNI ที่ส่งไปถูกไม่ได้ทำให้การตรวจชื่อ chain และช่วงเวลาผ่านเองทั้งหมด
Server Name Indication เป็นส่วนหนึ่งของการเริ่ม TLS ที่ช่วยให้ server เลือกค่าของบริการตามชื่อที่ client ขอ จึงรองรับกรณี IP เดียวให้บริการหลายชื่อซึ่งใช้ certificate ต่างกันได้ตามการตั้งค่า
HTTP Host หรือชื่อในคำขอ HTTP ยังมีหน้าที่อีกชั้นหนึ่ง การแก้เฉพาะ header หลัง TLS ไม่ได้ย้อนกลับไปเปลี่ยน certificate ที่ server เลือกส่งก่อนหน้านั้น การทดสอบ HTTPS ด้วย IP ตรงแล้วเพิ่ม Host จึงอาจไม่เท่ากับการเรียก hostname ตามปกติ
Client ที่ส่ง SNI ไม่ตรงกับ virtual server ที่ตั้งใจอาจได้ใบ default ของปลายทางนั้น ส่วนชื่อที่ตรงแต่ยังได้ใบผิดก็ต้องตรวจว่าคำขอถึง proxy ตัวใดและใช้ config ชุดไหน ไม่รีบสรุปว่าข้อมูล DNS อย่างเดียวเป็นต้นเหตุ
การตรวจตัวตนของบริการดู identifier ที่ certificate ระบุไว้ตามมาตรฐานและนโยบายของ client สำหรับชื่อ DNS ใช้ข้อมูลชนิด dNSName ใน subjectAltName ส่วนการเชื่อมโดยใช้ IP มีชนิด iPAddress ที่เกี่ยวข้อง ไม่ใช่เอาข้อความชื่อเครื่องในช่องใดก็ได้มาเทียบแทน
จึงควรเปิดดู SAN ของใบที่ปลายทางส่งจริง ไม่ดูเพียงชื่อไฟล์หรือชื่อที่ใช้ตอนออกใบ หากบริการย้ายจากชื่อหนึ่งไปอีกชื่อ แต่ยังติดตั้งใบเดิม การเชื่อมต่ออาจถึงเครื่องถูกแล้วแต่การตรวจตัวตนยังไม่ผ่านตามเหตุผลของมัน
Wildcard ก็มีขอบเขต ตัวอย่างสมมติ *.lab.example ใช้ครอบชื่ออย่าง api.lab.example ตามกติกาการจับคู่ที่รองรับ แต่ไม่ได้ครอบ lab.example หรือ node.api.lab.example ไปด้วย การมีเครื่องหมายดอกจันจึงไม่ได้หมายถึงทุกระดับใต้โดเมนทั้งหมด
เวลาวางรายชื่อใน certificate ควรเริ่มจากชื่อที่ client ใช้งานจริง รวมชื่อหลักหรือชื่อย่อยที่ต้องรองรับตามงาน ไม่ค่อยๆ เพิ่มชื่อให้ผ่านจาก error โดยยังไม่รู้ว่าผู้ใช้ควรเข้าช่องทางใดและมีชื่อที่เลิกใช้แล้วค้างอยู่หรือไม่
ใบของบริการเชื่อมโยงกับผู้ออกและ trust store ที่ client ยอมรับ การส่ง leaf certificate เพียงใบเดียวอาจไม่พอให้ client สร้าง chain ได้ตามสภาพแวดล้อม แม้บางเครื่องจะมีข้อมูล intermediate ที่ช่วยให้เปิดได้ก็ตาม
สำหรับตัวอย่างการตั้งค่า NGINX เอกสารระบุให้ไฟล์ certificate วางใบหลักก่อนแล้วตามด้วย intermediate ที่ต้องส่ง ควรตรวจรูปแบบของบริการที่ใช้งานจริง ไม่สลับลำดับหรือรวมไฟล์แบบเดาเพียงเพราะทุกไฟล์ลงท้าย PEM เหมือนกัน
Trust store ของระบบปฏิบัติการ browser container หรือโปรแกรมแต่ละตัวก็อาจต่างกัน ใบจาก CA ภายในองค์กรจึงต้องมีแผนกระจายความเชื่อถือไปยัง client ที่เกี่ยวข้องอย่างถูกต้อง ไม่ติดตั้ง root เพิ่มแบบไม่ทราบที่มาเพื่อให้ข้อความผิดพลาดหายไป
ช่วงเวลาที่ certificate ใช้ได้เป็นเงื่อนไขอีกด้านหนึ่ง ควรตรวจเวลาและนโยบายของ client ร่วมกับใบที่ส่งอยู่ ไม่ใช้การผ่าน handshake บางส่วนแทนผลตรวจครบทั้งหมด และไม่ปิดตรวจวันหมดอายุเป็นทางแก้ถาวร
OpenSSL s_client แยกตัวเลือกสำหรับจุดที่เชื่อม ชื่อ SNI และชื่อที่ต้องตรวจได้ ตัวอย่างต่อไปนี้เป็นรูปแบบสมมติสำหรับนำไปปรับกับระบบที่มีสิทธิ์ตรวจ ไม่ใช่ผลตรวจหรือรายงานว่าใบของบริการใดผ่านแล้ว
openssl s_client -connect service.example:443 \
-servername service.example \
-verify_hostname service.example \
-verify_return_error
ตัวเลือก -servername ช่วยกำหนดชื่อใน ClientHello ส่วน -verify_hostname บอกชื่ออ้างอิงที่จะตรวจ จึงควรเข้าใจความต่างของสองหน้าที่ ไม่ถือว่าระบุ SNI แล้วเท่ากับเปิดตรวจชื่อครบตามที่ต้องการเสมอ
เครื่องมือนี้มีพฤติกรรมสำหรับ debugging ที่แสดง verification error แล้วอาจดำเนินต่อได้หากไม่กำหนดให้หยุดตามตัวเลือกที่เกี่ยวข้อง ดังนั้นการเห็นข้อความว่าเชื่อมต่อได้หรืออ่าน certificate ออกมาได้ยังไม่พอ ต้องอ่านผล verification และใช้ trust store ที่ตรงกับขอบเขตการตรวจด้วย
ถ้าโดเมนอยู่หลัง CDN หรือ load balancer ใบที่ผู้ใช้เห็นอาจอยู่ที่ edge ส่วน origin ใช้อีกใบหนึ่ง การตรวจไฟล์ใน origin จึงบอกได้เฉพาะชั้นนั้น ไม่ตอบว่า public endpoint กำลังใช้ใบใด
หากมีหลาย frontend หรือทั้ง IPv4 และ IPv6 ควรตรวจแต่ละเส้นทางโดยรักษาชื่ออ้างอิงเดิม พร้อมบันทึกจุดเชื่อมและเวลา การใช้ชื่อถูกแต่ไป node คนละตัวอาจทำให้ผลต่างกันได้ และต้องหาขอบเขตที่ติดตั้งไม่ครบก่อนแก้
ข้อมูลที่ใช้ส่งต่อให้คนดูแลควรมี hostname ที่คาดหวัง SAN ผู้ออก ช่วงเวลาที่ใช้ได้ และผลตรวจ chain ตามที่จำเป็น ไม่แนบ private key หรือ credential ในรายงาน ปัญหาชื่อกับ chain อธิบายได้จากหลักฐานสาธารณะของใบและสภาพ client โดยไม่ต้องเปิดข้อมูลลับของ server
TLS ต้องเลือก certificate ให้ตรงบริการและตรวจว่าตัวตนนั้นเชื่อถือได้ตาม client ที่ใช้ SNI ช่วยด้านการเลือก ส่วน SAN chain และช่วงเวลาเป็นหลักฐานด้านการยอมรับ เมื่อทดสอบโดยคงชื่อที่ผู้ใช้เรียกและตามถึง endpoint จริง เราจะแยกการตั้ง virtual host ผิดออกจากปัญหาความเชื่อถือ และแก้ได้โดยไม่ลดการตรวจตัวตนเพื่อกลบอาการ