Jak nastavit ověřování certifikátů MQTTS a HTTPS na elektroměru IAMMETER

Elektroměry IAMMETER s firmwarem i.91.065.9 a novějším mohou při odesílání dat přes MQTTS nebo HTTPS ověřovat certifikát serveru. Zabezpečeným odchozím spojením tak přidávají ověření certifikačního řetězce a názvu serveru.

Článek se zaměřuje na nastavení důvěry TLS. Nenastavuje témata MQTT, JSON payloady ani automatické zjišťování Home Assistant. Postup publikování MQTT najdete v MQTT elektroměr: publikování dat IAMMETER do vašeho MQTT brokeru.

Na této stránce

• Vyberte režim ověřování certifikátů
• Požadavky a důležité hranice
• Zkontrolujte aktuální režim TLS
• Zvolte ověřování builtin
• Zvolte none pro dočasnou diagnostiku
• Nahrajte a vyberte vlastní CA
• Smažte vlastní CA
• Použijte IAMMETER Swagger UI
• Řešení problémů s ověřováním certifikátů

Vyberte režim ověřování certifikátů

Klienti MQTTS a HTTPS v IAMMETER podporují tři režimy ověřování certifikátu serveru:

Nastavení platí, když zařízení IAMMETER funguje jako klient TLS a odesílá data brokeru MQTTS nebo serveru HTTPS. Nezapíná HTTPS na místním webovém serveru zařízení.

builtin

builtin je výchozí režim. Použije se, pokud nebylo uloženo nastavení ověřování TLS, a obnoví se po smazání konfigurace TLS CA nebo obnovení továrního nastavení zařízení.

Firmware obsahuje tyto kořenové CA:

• DigiCert Global Root G2
• ISRG Root X1

Zařízení ověřuje řetězec certifikátů i název serveru. Broker MQTTS nebo server HTTPS musí předložit certifikát s řetězcem k jednomu z těchto kořenů a jeho Subject Alternative Name (SAN) musí odpovídat nastavené adrese serveru.

Pokud adresa pro odesílání používá IP, certifikát musí obsahovat přesně tuto IP v SAN. Název DNS neodpovídá IP adrese, i když oba vedou na stejný server.

custom

custom provádí stejné ověření řetězce a názvu jako builtin, ale důvěřuje PEM CA certifikátu nahranému správcem. Použijte jej, když:

• certifikát serveru vydala soukromá CA;
• nasazení používá serverový certifikát podepsaný sebou samým; nebo
• požadovaná veřejná kořenová CA není ve firmwaru.

Pro soukromou PKI nahrajte její kořenový CA certifikát. TLS server musí při handshake stále posílat potřebné mezilehlé certifikáty. Certifikát serveru podepsaný sebou samým lze nahrát jako kotvu důvěry, jeho SAN ale musí odpovídat nastavenému názvu nebo IP adrese.

none

none stále vytváří šifrované TLS spojení, ale neověřuje certifikační řetězec ani název serveru. Odpovídá to staršímu chování TLS bez autentizace serveru.

Tento režim je zranitelný vůči útokům prostředníka. Používejte jej jen dočasně pro kompatibilitu nebo diagnostiku. V produkci upřednostněte builtin nebo custom.

Požadavky a důležité hranice

Konfigurační API TLS CA vyžadují zapnuté Local Admin Security. Každý požadavek musí obsahovat nastavené uživatelské jméno a heslo správce pomocí HTTP Basic Authentication.

Počítač s curl nebo Swagger UI musí dosáhnout na místní IP zařízení. Klienti MQTTS a HTTPS sdílejí jeden ověřovací režim a jednu vlastní CA, takže změna ovlivní používaný režim zabezpečeného odesílání.

Po změně konfigurace TLS zařízení restartujte, aby se odchozí klient znovu vytvořil s novými parametry.

Příklady používají tyto zástupné hodnoty:

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

Nahraďte je skutečnou adresou zařízení a přihlašovacími údaji správce.

Zkontrolujte aktuální režim TLS

API:

GET /api/tls/ca/status

Příklad:

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

Příklad odpovědi:

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

Odpověď uvádí zvolený režim a případně délku a otisk SHA-256 uložené vlastní CA.

Zvolte ověřování builtin

API:

POST /api/tls/ca/select

Příklad:

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

Po úspěšné odpovědi zařízení restartujte.

Zvolte none pro dočasnou diagnostiku

API:

POST /api/tls/ca/select

Příklad:

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

Odpověď obsahuje varování, že ověřování certifikátu serveru je vypnuté. Po změně režimu zařízení restartujte a po diagnostice přepněte zpět na builtin nebo custom.

Nahrajte a vyberte vlastní CA

Nahrání CA a volba custom jsou samostatné operace. Nahrání CA samo nezmění aktivní režim.

Požadavky na soubor vlastní CA

Nahrávaný soubor musí splnit všechny následující požadavky:

• formát certifikátu PEM;
• surové tělo požadavku, nikoli JSON ani multipart/form-data;
• Content-Type: application/x-pem-file;
• délka 1 až 3072 bajtů včetně hlaviček PEM, konců řádků a mezer;
• obsahuje -----BEGIN CERTIFICATE----- a -----END CERTIFICATE-----;
• neobsahuje soukromý klíč.

Limit 3072 bajtů platí pro celé tělo HTTP požadavku. PEM soubor o 3072 bajtech je přijat, soubor o 3073 bajtech odmítnut.

Před nahráním zkontrolujte velikost souboru:

wc -c root-ca.pem

Krok 1: Nahrajte CA

API:

POST /api/tls/ca/upload

Příklad:

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

Příklad úspěšné odpovědi:

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

Zařízení ukládá CA do více bloků KV a před označením za aktivní ověřuje uloženou délku a otisk SHA-256. Přerušený zápis nenahradí předchozí platnou CA.

Krok 2: Vyberte custom

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

Pokud není uložena platná vlastní CA, zařízení požadavek odmítne. Nepřepne tiše na none.

Krok 3: Restartujte a ověřte

Restartujte zařízení z místního webového rozhraní nebo použijte chráněné API pro restart:

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

Po opětovném připojení zařízení znovu zjistěte stav:

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

Ověřte, že mode je custom, customCaValid je 1 a uvedená délka i otisk SHA-256 odpovídají nahranému certifikátu.

Smažte vlastní CA

API:

POST /api/tls/ca/delete

Příklad:

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

Smazání vlastní CA zároveň vrací režim na builtin. Po smazání zařízení restartujte.

Použijte IAMMETER Swagger UI

Stejná API můžete testovat bez ručního psaní příkazů curl:

IAMMETER WEM API Test - TLS CA

1. Otevřete WEM API Test na počítači s přístupem k místní IP zařízení.
2. Zadejte adresu zařízení, například 192.168.1.80, a vyberte Apply.
3. Vyberte Authorize a zadejte jméno a heslo správce.
4. Otevřete skupinu TLS CA - Authenticated.
5. Pomocí GET /api/tls/ca/status zobrazte aktuální konfiguraci.
6. Podle potřeby použijte nahrání, výběr nebo smazání.
7. Po změně režimu či certifikátu zařízení restartujte.

Stránka Swagger běží v prohlížeči a posílá požadavky přímo z tohoto počítače do zařízení IAMMETER. Nepoužívá proxy IAMMETER Cloud, proto musí mít prohlížeč přímé síťové spojení s IP zařízení.

Řešení problémů s ověřováním certifikátů

admin security required

Před použitím API TLS CA zapněte Local Admin Security. Tato nastavení nelze měnit anonymně.

custom CA is missing or invalid

Před volbou custom úspěšně nahrajte platnou PEM CA. Dotazem na /api/tls/ca/status ověřte, že customCaValid je 1.

Spojení TLS selhává v builtin nebo custom

Zkontrolujte všechny tyto body:

• nastavený název nebo IP odpovídá SAN certifikátu;
• certifikát je právě platný a čas zařízení je správný;
• server posílá potřebné mezilehlé certifikáty;
• vybraná kořenová CA vydala certifikát serveru nebo mu prostřednictvím řetězce důvěřuje;
• zařízení bylo po změně TLS konfigurace restartováno.

TLS funguje v none, ale selhává v ověřovaných režimech

Obvykle jde o problém certifikačního řetězce, názvu serveru, doby platnosti nebo hodin zařízení. Ponechání none pouze skryje selhání autentizace, nevyřeší jej. Opravte nasazení certifikátů nebo nahrajte správnou kořenovou CA a použijte custom.