การเปิด API จากคอมพิวเตอร์ได้ ไม่ได้แปลว่า firmware บนบอร์ดจะเชื่อมต่อผ่านเงื่อนไขเดียวกันทั้งหมด คอมพิวเตอร์อาจมีเวลาที่ sync แล้ว มีชุด root certificate ที่อัปเดต และมีหน่วยความจำให้ใช้มากกว่าบอร์ด จึงมีรายละเอียดบางอย่างที่เพิ่งเห็นเมื่อนำ HTTPS มาใช้งานจริงกับอุปกรณ์
เมื่อเชื่อมไม่ผ่าน ข้อความที่แอปแสดงอาจมีเพียงส่งข้อมูลไม่ได้ ทั้งที่สาเหตุอาจอยู่ตั้งแต่ DNS การต่อ TCP ไปจนถึงการตรวจ certificate ของ TLS ถ้าข้ามไปแก้ค่าตรวจความปลอดภัยทันที ก็มีโอกาสทำให้เชื่อมผ่านโดยยังไม่รู้ว่าผิดตรงไหน
แนวทางที่ตามเหตุได้ชัดกว่าคือแยกชั้นของการเชื่อมต่อก่อนครับ แล้วเก็บ error ที่เกี่ยวข้องกับชั้นนั้นพร้อมบริบทของ firmware เพื่อให้แก้สาเหตุได้โดยยังรักษาการตรวจตัวตนของ server ไว้
ก่อนตรวจ certificate ต้องรู้ว่าบอร์ดเข้าถึงเครือข่ายและหาชื่อปลายทางได้แล้วหรือยัง หาก DNS ไม่สำเร็จ การเปลี่ยน CA ใน firmware ก็ไม่ได้ทำให้มีที่อยู่ปลายทางขึ้นมาได้ ส่วนถ้าต่อ TCP ไม่ผ่านก็ต้องดูเส้นทาง พอร์ต และเงื่อนไขเครือข่ายที่เกี่ยวข้องก่อน
ควรเก็บ hostname ที่ตั้งใจติดต่อ ขั้นที่หยุด และรหัส error ตามที่ไลบรารีคืนมา โดยไม่ใส่ token หรือข้อมูลลับใน log หากโค้ดรวมทุกปัญหาเป็นคำเดียว อาจต้องเพิ่มข้อมูลวินิจฉัยในสภาพแวดล้อมทดสอบก่อน เพราะการเดาจากข้อความทั่วไปจะทำให้เปลี่ยนหลายอย่างโดยไม่มีหลักชี้
เมื่อเริ่ม TLS handshake แล้วแต่ไม่สำเร็จ จึงค่อยดูรหัสจาก ESP-TLS กับไลบรารี TLS ที่ใช้ประกอบกัน บทนี้อิงเอกสาร ESP-IDF 5.4 สำหรับ ESP32 การใช้ Arduino core หรือ wrapper อื่นอาจมีชื่อ API และวิธีเปิด log ต่างกัน จึงต้องตรวจรุ่นที่โปรเจกต์ใช้อยู่ด้วย
หลัง handshake ผ่านแล้ว หากได้ HTTP 401 หรือข้อมูลไม่ถูกต้อง ก็เป็นอีกช่วงของการเรียก API การแยกแบบนี้ช่วยไม่ให้เอาปัญหาสิทธิ์ของแอปมาปะปนกับการตรวจ certificate และไม่ยืนยันว่าการได้ response ใดๆ แปลว่างานปลายทางสำเร็จแล้ว
Certificate มีช่วงเวลาที่ใช้ตรวจความถูกต้องตามการตรวจเส้นทาง certificate หากบอร์ดเพิ่งเปิดแล้วเวลายังไม่พร้อม ก็อาจเกิดข้อผิดพลาดเรื่องเวลาได้ จึงควรตรวจเวลาที่บอร์ดใช้อยู่จริงพร้อมสถานะการ sync แทนการดูเพียงเวลาจากหน้าจอคอมพิวเตอร์ที่ใช้เขียนโค้ด
ไม่ควรตั้งวันคงที่เพื่อให้ certificate ผ่านในช่วงหนึ่งแล้วถือว่าแก้เสร็จ เพราะเมื่อปลายทางเปลี่ยน certificate หรือเวลาผ่านไป เงื่อนไขก็เปลี่ยนตามไปด้วย ต้องออกแบบให้บอร์ดรู้ว่าเวลาอยู่ในสถานะใด และมีทางเริ่มทำงานที่เหมาะกับการตรวจตัวตนของบริการ
ชื่อที่เชื่อมต่อก็ต้องตรงกับสิ่งที่ certificate รองรับ การเปลี่ยนจากชื่อโดเมนไปใช้ IP ตรงเพื่อข้าม DNS อาจทำให้เงื่อนไขตรวจชื่อเปลี่ยนไป และ server ที่ให้บริการหลายชื่อบน IP เดียวกันอาจใช้ SNI เพื่อเลือกการตั้งค่าของชื่อที่ร้องขอด้วย
จึงควรแยกการทดสอบเครือข่ายจากค่าที่จะใช้กับงานจริง การต่อ TCP ถึง IP ช่วยตรวจเส้นทางบางส่วนได้ แต่ไม่ได้เป็นหลักฐานว่า HTTPS สำหรับ hostname ที่แอปต้องการจะตรวจผ่านทั้งหมด และไม่ควรปิดการตรวจชื่อเพียงเพื่อทำให้สองกรณีดูเหมือนกัน
ESP-TLS มีวิธีเตรียมข้อมูลสำหรับตรวจ server หลายแบบ เช่น CA ที่แอปให้ไว้ global CA store หรือ certificate bundle ที่รองรับในชุดเครื่องมือ การเลือกใช้ต้องสอดคล้องกับไลบรารีและการตั้งค่าที่บิ้วมาจริง ไม่ใช่เพียงมีไฟล์ certificate อยู่ใน repo แล้วถือว่าถูกนำไปใช้แล้ว
ถ้าคอมพิวเตอร์เปิดได้แต่บอร์ดเปิดไม่ได้ ต้องดูว่าทั้งสองฝั่งมีแหล่งความเชื่อถือกับ certificate chain เหมือนกันหรือไม่ โดยเฉพาะบริการที่ใช้ CA ภายในองค์กร หรือ server ที่ส่ง intermediate มาไม่ครบตามที่ client ต้องใช้
การนำ certificate ใบใดมาใส่ต้องรู้หน้าที่ของมันด้วย การยึดกับใบปลายทางที่หมุนเปลี่ยนบ่อยกับการใช้ root ที่เหมาะสมมีภาระดูแลต่างกัน และถ้าออกแบบ pinning ไว้ก็ต้องมีแผนเปลี่ยนผ่านตามนั้น ไม่ใส่สิ่งที่คัดลอกมาโดยไม่รู้ว่าจะหมดอายุหรือเปลี่ยนเมื่อใด
Certificate bundle ที่ฝังใน firmware เป็นข้อมูลของชิ้นงานที่บิ้วไว้ ไม่ได้กลายเป็นชุด root ล่าสุดเองเพียงเพราะอุปกรณ์ต่ออินเทอร์เน็ตได้ จึงควรมีวิธีตามรุ่นและอัปเดตตามวงจรดูแล firmware พร้อมทดสอบเส้นทางที่ต้องรองรับก่อนปล่อยใช้กว้าง
TLS handshake ใช้ buffer และโครงสร้างภายในเพิ่มจากการส่งข้อมูลแบบธรรมดา หากเปิดหลาย connection หรือมีงานอื่นใช้หน่วยความจำในช่วงเดียวกัน ความล้มเหลวอาจเกี่ยวกับการจัดสรรหน่วยความจำ ไม่ใช่ certificate ผิดทุกครั้ง
จึงควรเก็บข้อมูล heap ตาม capability ที่เกี่ยวข้อง และดู largest free block ร่วมกับจำนวนว่างรวมในจุดก่อนเชื่อมต่อ ระหว่างทำงาน และหลังปิดการเชื่อมต่อ การเห็น RAM รวมเหลือยังไม่ตอบว่าก้อนที่ไลบรารีต้องการถูกจัดสรรได้ในพื้นที่ชนิดนั้นหรือไม่
เมื่อเชื่อมต่อผิดพลาดก็ควรตรวจการคืน handle และ buffer ของเส้นทาง error ด้วย เพราะถ้าลองใหม่แล้วมีทรัพยากรค้างอยู่ ปัญหาอาจสะสมจนรอบหลังล้มเหลวด้วยอีกสาเหตุ การเพิ่มจำนวน retry จึงไม่ใช่คำตอบของทุกกรณี
ส่วน protocol version, cipher และตัวเลือกเฉพาะต้องอ้างอิงความสามารถของ server กับ firmware ที่ใช้จริง ถ้าจำเป็นต้องปรับ ควรมีรหัส error และข้อกำหนดจากทั้งสองด้านรองรับ ไม่ลดเงื่อนไขแบบสุ่มจนเชื่อมผ่านโดยไม่รู้ว่าตัดอะไรออกไปบ้าง
เมื่อแก้แล้วควรทดสอบทั้งปลายทางที่ถูกต้องและกรณีที่ตั้งใจให้ตรวจไม่ผ่าน เช่น ชื่อไม่ตรงหรือ CA ที่ไม่อยู่ในขอบเขตความเชื่อถือ โดยใช้ระบบทดสอบที่ควบคุมได้ สิ่งที่ต้องการคือแยกตัวตนได้ตามกติกา ไม่ใช่เพียงเชื่อมต่อได้ทุก server
ESP-TLS มีตัวเลือกข้ามการตรวจ server สำหรับการทดสอบและระบุความเสี่ยงไว้ชัด หากใช้ตัวเลือกเช่นนี้เป็นการวินิจฉัย ก็ต้องไม่ยกผลนั้นมาเป็นหลักฐานว่าเส้นทางตรวจตัวตนปกติผ่านแล้ว และต้องตรวจค่าบิ้วก่อนนำ firmware ไปใช้งานจริง
เก็บรุ่น firmware รุ่น SDK hostname เวลาในบอร์ด และรหัส error ที่ตัดข้อมูลลับแล้วไว้กับผลแต่ละครั้ง จะช่วยเทียบเมื่อเปลี่ยน certificate หรือย้ายปลายทางในอนาคตได้ บทนี้ไม่ได้ยก log จำลองมาอ้างว่าเป็นอาการที่วัดพบจากบอร์ดของผู้ใช้
การต่อ HTTPS ไม่ผ่านควรเริ่มจากรู้ว่าหยุดที่ DNS TCP TLS หรือ HTTP แล้วตรวจเวลา ชื่อปลายทาง แหล่งความเชื่อถือ และทรัพยากรตามหลักฐาน เมื่อแก้พร้อมตรวจทั้งกรณีผ่านและปฏิเสธ เราจะรักษาความหมายของการเชื่อมต่อแบบตรวจตัวตนไว้ได้ และไม่ใช้การข้ามการตรวจมาแทนการแก้สาเหตุที่แท้จริง