วิธีกำหนดค่าการตรวจสอบใบรับรอง MQTTS และ HTTPS บนมิเตอร์ IAMMETER

มิเตอร์ IAMMETER ที่ใช้เฟิร์มแวร์ i.91.065.9 หรือใหม่กว่าสามารถตรวจสอบใบรับรองของเซิร์ฟเวอร์ขณะส่งข้อมูลผ่าน MQTTS หรือ HTTPS ได้ ฟังก์ชันนี้เพิ่มการตรวจสอบสายโซ่ใบรับรองและชื่อโฮสต์ของเซิร์ฟเวอร์ให้กับการเชื่อมต่อขาออกที่ปลอดภัย

บทความนี้อธิบายการกำหนดค่าความเชื่อถือของ TLS ไม่ได้ครอบคลุมการตั้งค่า MQTT topic, เพย์โหลด JSON หรือการค้นหาอุปกรณ์ของ Home Assistant สำหรับการเผยแพร่ข้อมูลผ่าน MQTT โปรดดู มิเตอร์ MQTT: ส่งข้อมูล IAMMETER ไปยัง MQTT broker ของคุณ

เนื้อหาในหน้านี้

• เลือกโหมดการตรวจสอบใบรับรอง
• ข้อกำหนดและข้อจำกัดที่สำคัญ
• ตรวจสอบโหมด TLS ปัจจุบัน
• เลือกการตรวจสอบแบบ builtin
• เลือก none เพื่อวินิจฉัยปัญหาชั่วคราว
• อัปโหลดและเลือก CA ที่กำหนดเอง
• ลบ CA ที่กำหนดเอง
• ใช้ Swagger UI ของ IAMMETER
• แก้ปัญหาการตรวจสอบใบรับรอง

เลือกโหมดการตรวจสอบใบรับรอง

ไคลเอนต์ MQTTS และ HTTPS ของ IAMMETER รองรับการตรวจสอบใบรับรองเซิร์ฟเวอร์สามโหมด:

การตั้งค่าเหล่านี้ใช้เมื่ออุปกรณ์ IAMMETER ทำหน้าที่เป็นไคลเอนต์ TLS และส่งข้อมูลไปยัง MQTTS broker หรือเซิร์ฟเวอร์ HTTPS ไม่ได้เปิดใช้งาน HTTPS ให้กับเว็บเซิร์ฟเวอร์ภายในอุปกรณ์

builtin

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

เฟิร์มแวร์มี Root CA ต่อไปนี้:

• DigiCert Global Root G2
• ISRG Root X1

อุปกรณ์จะตรวจสอบทั้งสายโซ่ใบรับรองและชื่อโฮสต์ของเซิร์ฟเวอร์ MQTTS broker หรือเซิร์ฟเวอร์ HTTPS ต้องส่งใบรับรองที่มีสายโซ่เชื่อมไปยัง Root CA เหล่านี้ และฟิลด์ Subject Alternative Name (SAN) ต้องตรงกับที่อยู่เซิร์ฟเวอร์ที่กำหนดไว้

หากที่อยู่ปลายทางเป็น IP address ฟิลด์ SAN ของใบรับรองต้องมี IP address นั้นตรงกันทุกประการ ชื่อ DNS ไม่ถือว่าตรงกับ IP address แม้ว่าทั้งสองจะชี้ไปยังเซิร์ฟเวอร์เดียวกันก็ตาม

custom

custom ตรวจสอบสายโซ่และชื่อโฮสต์เช่นเดียวกับ builtin แต่เชื่อถือใบรับรอง CA รูปแบบ PEM ที่ผู้ดูแลระบบอัปโหลด ใช้โหมดนี้เมื่อ:

• ใบรับรองเซิร์ฟเวอร์ออกโดย CA ส่วนตัว
• ระบบใช้ใบรับรองเซิร์ฟเวอร์ที่ลงนามด้วยตนเอง หรือ
• Root CA สาธารณะที่ต้องการไม่ได้ฝังอยู่ในเฟิร์มแวร์

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

none

none ยังคงสร้างการเชื่อมต่อ TLS ที่เข้ารหัส แต่จะไม่ตรวจสอบสายโซ่ใบรับรองหรือชื่อโฮสต์ พฤติกรรมนี้คล้ายกับ TLS แบบเดิมที่ไม่มีการยืนยันตัวตนของเซิร์ฟเวอร์

โหมดนี้มีความเสี่ยงต่อการโจมตีแบบคนกลาง (man-in-the-middle) ให้ใช้เพียงชั่วคราวเพื่อความเข้ากันได้หรือการวินิจฉัยปัญหา สำหรับการใช้งานจริงควรเลือก builtin หรือ custom

ข้อกำหนดและข้อจำกัดที่สำคัญ

API สำหรับกำหนดค่า TLS CA ต้องเปิดใช้งาน Local Admin Security ก่อน ทุกคำขอต้องส่งชื่อผู้ใช้และรหัสผ่านผู้ดูแลระบบที่ตั้งไว้ผ่าน HTTP Basic Authentication

คอมพิวเตอร์ที่ใช้ curl หรือ Swagger UI ต้องเข้าถึง IP address ภายในเครือข่ายของอุปกรณ์ได้ ไคลเอนต์ MQTTS และ HTTPS ใช้โหมดการตรวจสอบหนึ่งค่าและ CA ที่กำหนดเองหนึ่งชุดร่วมกัน ดังนั้นการเปลี่ยนแปลงจะมีผลต่อโหมดการส่งข้อมูลแบบปลอดภัยที่อุปกรณ์ใช้อยู่

รีสตาร์ตอุปกรณ์หลังจากเปลี่ยนการกำหนดค่า TLS เพื่อสร้างไคลเอนต์ขาออกใหม่ด้วยค่าที่เปลี่ยนแล้ว

ตัวอย่างใช้ค่าตัวแทนต่อไปนี้:

DEVICE_IP="192.168.1.80"
ADMIN_USER="admin"
ADMIN_PASSWORD="ExamplePassword1"

แทนที่ค่าเหล่านี้ด้วยที่อยู่อุปกรณ์และข้อมูลเข้าสู่ระบบของผู้ดูแลระบบจริง

ตรวจสอบโหมด TLS ปัจจุบัน

API:

GET /api/tls/ca/status

ตัวอย่าง:

curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
  "http://$DEVICE_IP/api/tls/ca/status"

ตัวอย่างการตอบกลับ:

{
  "successful": 1,
  "mode": "builtin",
  "customCaValid": 0,
  "customCaLength": 0,
  "customCaSha256": "",
  "restartRequiredAfterChange": 1
}

การตอบกลับแสดงโหมดที่เลือก และหากมีการบันทึก CA ที่กำหนดเอง จะแสดงความยาวและค่าแฮช SHA-256 ของ CA ด้วย

เลือกการตรวจสอบแบบ builtin

API:

POST /api/tls/ca/select

ตัวอย่าง:

curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
  -X POST "http://$DEVICE_IP/api/tls/ca/select" \
  -H "Content-Type: application/json" \
  -d '{"mode":"builtin"}'

รีสตาร์ตอุปกรณ์หลังจากได้รับการตอบกลับว่าสำเร็จ

เลือก none เพื่อวินิจฉัยปัญหาชั่วคราว

API:

POST /api/tls/ca/select

ตัวอย่าง:

curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
  -X POST "http://$DEVICE_IP/api/tls/ca/select" \
  -H "Content-Type: application/json" \
  -d '{"mode":"none"}'

การตอบกลับจะแจ้งเตือนว่าการตรวจสอบใบรับรองเซิร์ฟเวอร์ถูกปิด รีสตาร์ตอุปกรณ์หลังเปลี่ยนโหมด และกลับไปใช้ builtin หรือ custom เมื่อวินิจฉัยปัญหาเสร็จแล้ว

อัปโหลดและเลือก CA ที่กำหนดเอง

การอัปโหลด CA และการเลือก custom เป็นคนละขั้นตอน การอัปโหลด CA ไม่ได้เปลี่ยนโหมดที่ใช้งานอยู่โดยอัตโนมัติ

ข้อกำหนดของไฟล์ CA ที่กำหนดเอง

ไฟล์ที่อัปโหลดต้องเป็นไปตามข้อกำหนดทั้งหมดนี้:

• ใช้รูปแบบใบรับรอง PEM
• ส่งเนื้อหาคำขอแบบดิบ ไม่ใช่ JSON หรือ multipart/form-data
• ใช้ Content-Type: application/x-pem-file
• มีความยาวตั้งแต่ 1 ถึง 3072 ไบต์ รวมส่วนหัว PEM อักขระขึ้นบรรทัดใหม่ และช่องว่าง
• มี -----BEGIN CERTIFICATE----- และ -----END CERTIFICATE-----
• ไม่มีคีย์ส่วนตัว

ขีดจำกัด 3072 ไบต์ใช้กับเนื้อหาคำขอ HTTP ทั้งหมด ไฟล์ PEM ขนาด 3072 ไบต์จะได้รับการยอมรับ แต่ไฟล์ขนาด 3073 ไบต์จะถูกปฏิเสธ

ตรวจสอบขนาดไฟล์ก่อนอัปโหลด:

wc -c root-ca.pem

ขั้นตอนที่ 1: อัปโหลด CA

API:

POST /api/tls/ca/upload

ตัวอย่าง:

curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
  -X POST "http://$DEVICE_IP/api/tls/ca/upload" \
  -H "Content-Type: application/x-pem-file" \
  --data-binary @root-ca.pem

ตัวอย่างการตอบกลับเมื่อสำเร็จ:

{
  "successful": 1,
  "length": 1939,
  "sha256": "64-character SHA-256 digest",
  "message": "CA uploaded; select custom mode and restart"
}

อุปกรณ์บันทึก CA ไว้ในบล็อก KV หลายบล็อก และตรวจสอบความยาวกับค่าแฮช SHA-256 ที่บันทึกไว้ก่อนทำเครื่องหมายว่าใช้งานได้ หากการเขียนถูกขัดจังหวะ CA ที่ถูกต้องชุดเดิมจะไม่ถูกแทนที่

ขั้นตอนที่ 2: เลือก custom

curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
  -X POST "http://$DEVICE_IP/api/tls/ca/select" \
  -H "Content-Type: application/json" \
  -d '{"mode":"custom"}'

อุปกรณ์จะปฏิเสธคำขอนี้หากไม่มี CA ที่กำหนดเองที่ถูกต้องบันทึกอยู่ และจะไม่เปลี่ยนไปใช้ none โดยไม่แจ้งให้ทราบ

ขั้นตอนที่ 3: รีสตาร์ตและตรวจสอบ

รีสตาร์ตอุปกรณ์จากเว็บ UI ภายในเครื่อง หรือใช้ API รีสตาร์ตที่มีการป้องกัน:

curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
  "http://$DEVICE_IP/api/restart?reset=false"

หลังจากอุปกรณ์เชื่อมต่อกลับมา ให้สอบถามสถานะอีกครั้ง:

curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
  "http://$DEVICE_IP/api/tls/ca/status"

ตรวจสอบว่า mode เป็น custom, customCaValid เป็น 1 และความยาวกับค่าแฮช SHA-256 ตรงกับใบรับรองที่อัปโหลด

ลบ CA ที่กำหนดเอง

API:

POST /api/tls/ca/delete

ตัวอย่าง:

curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
  -X POST "http://$DEVICE_IP/api/tls/ca/delete"

การลบ CA ที่กำหนดเองจะคืนค่าโหมดเป็น builtin ด้วย รีสตาร์ตอุปกรณ์หลังลบ

ใช้ Swagger UI ของ IAMMETER

คุณสามารถทดสอบ API เดียวกันได้โดยไม่ต้องเขียนคำสั่ง curl เอง:

IAMMETER WEM API Test - TLS CA

1. เปิดหน้า WEM API Test บนคอมพิวเตอร์ที่เข้าถึง IP address ภายในเครือข่ายของอุปกรณ์ได้
2. ป้อนที่อยู่อุปกรณ์ เช่น 192.168.1.80 แล้วเลือก Apply
3. เลือก Authorize แล้วป้อนชื่อผู้ใช้และรหัสผ่านผู้ดูแลระบบ
4. เปิดกลุ่ม TLS CA - Authenticated
5. ใช้ GET /api/tls/ca/status เพื่อตรวจสอบการกำหนดค่าปัจจุบัน
6. ใช้การอัปโหลด การเลือก หรือการลบตามต้องการ
7. รีสตาร์ตอุปกรณ์หลังเปลี่ยนโหมดหรือใบรับรอง

หน้า Swagger ทำงานในเบราว์เซอร์ และส่งคำขอจากคอมพิวเตอร์เครื่องนั้นไปยังอุปกรณ์ IAMMETER โดยตรง ไม่ได้ส่งต่อคำขอผ่าน IAMMETER Cloud ดังนั้นเบราว์เซอร์ต้องมีการเข้าถึง IP address ของอุปกรณ์ผ่านเครือข่ายโดยตรง

แก้ปัญหาการตรวจสอบใบรับรอง

admin security required

เปิด Local Admin Security ก่อนใช้ API TLS CA ไม่สามารถแก้ไขการตั้งค่าเหล่านี้โดยไม่ยืนยันตัวตนได้

custom CA is missing or invalid

อัปโหลด CA รูปแบบ PEM ที่ถูกต้องให้สำเร็จก่อนเลือก custom สอบถาม /api/tls/ca/status และยืนยันว่า customCaValid เป็น 1

เชื่อมต่อ TLS ไม่สำเร็จเมื่อใช้ builtin หรือ custom

ตรวจสอบทุกข้อต่อไปนี้:

• ชื่อโฮสต์หรือ IP address ที่กำหนดตรงกับ SAN ของใบรับรอง
• ใบรับรองยังอยู่ในช่วงเวลาที่ใช้ได้ และนาฬิกาของอุปกรณ์ถูกต้อง
• เซิร์ฟเวอร์ส่งใบรับรองตัวกลางที่จำเป็น
• Root CA ที่เลือกเป็นผู้ออกใบรับรองเซิร์ฟเวอร์ หรือเป็นต้นทางความเชื่อถือสุดท้ายของสายโซ่ใบรับรองนั้น
• รีสตาร์ตอุปกรณ์แล้วหลังเปลี่ยน TLS

TLS ใช้งานได้กับ none แต่ไม่ได้กับโหมดที่ตรวจสอบใบรับรอง

โดยทั่วไปอาการนี้บ่งชี้ว่ามีปัญหากับสายโซ่ใบรับรอง ชื่อโฮสต์ ช่วงเวลาที่ใบรับรองใช้ได้ หรือนาฬิกาของอุปกรณ์ การใช้ none ต่อไปเป็นเพียงการซ่อนความล้มเหลวในการยืนยันตัวตน ไม่ใช่การแก้ไข ให้แก้การติดตั้งใบรับรอง หรืออัปโหลด Root CA ที่ถูกต้องแล้วใช้ custom