Konfigurera certifikatverifiering för MQTTS och HTTPS på en IAMMETER-energimätare

IAMMETER-energimätare med firmware i.91.065.9 eller senare kan verifiera servercertifikatet när de laddar upp data via MQTTS eller HTTPS. Det tillför kontroll av certifikatkedja och servervärdnamn för säkra utgående anslutningar.

Artikeln handlar om TLS-tillitskonfiguration. Den konfigurerar inte MQTT-ämnen, JSON-payloads eller Home Assistant-discovery. För MQTT-publicering, se MQTT-energimätare: publicera IAMMETER-data till din MQTT-broker.

På den här sidan

• Välj ett läge för certifikatverifiering
• Krav och viktiga avgränsningar
• Kontrollera aktuellt TLS-läge
• Välj builtin-verifiering
• Välj none för tillfällig diagnostik
• Ladda upp och välj en egen CA
• Ta bort egen CA
• Använd IAMMETER Swagger UI
• Felsök certifikatverifieringen

Välj ett läge för certifikatverifiering

IAMMETERs MQTTS- och HTTPS-klienter stöder tre verifieringslägen för servercertifikat:

Inställningarna gäller när IAMMETER-enheten agerar TLS-klient och laddar upp data till en MQTTS-broker eller HTTPS-server. De aktiverar inte HTTPS på enhetens lokala webbserver.

builtin

builtin är standardläget. Det används när ingen TLS-verifieringsinställning tidigare har sparats och återställs när TLS CA-konfigurationen tas bort eller enheten fabriksåterställs.

Firmware innehåller dessa rot-CA:er:

• DigiCert Global Root G2
• ISRG Root X1

Enheten verifierar både certifikatkedjan och servervärdnamnet. MQTTS-brokern eller HTTPS-servern måste visa ett certifikat vars kedja går till en av dessa rötter, och dess Subject Alternative Name (SAN) måste matcha den konfigurerade serveradressen.

Om uppladdningsadressen använder en IP-adress måste certifikatets SAN innehålla exakt den IP-adressen. Ett DNS-namn matchar inte en IP-adress även om båda pekar på samma server.

custom

custom gör samma kedje- och värdnamnskontroll som builtin, men litar på PEM-CA-certifikatet som administratören laddat upp. Använd det när:

• servercertifikatet har utfärdats av en privat CA;
• installationen använder ett självsignerat servercertifikat; eller
• den nödvändiga offentliga rot-CA:n inte ingår i firmware.

För privat PKI laddar du upp dess rot-CA-certifikat. TLS-servern ska fortfarande skicka nödvändiga mellanliggande certifikat under handskakningen. Ett självsignerat servercertifikat kan laddas upp som tillitsankare, men SAN måste fortfarande matcha det konfigurerade värdnamnet eller IP-adressen.

none

none upprättar fortfarande en krypterad TLS-anslutning, men kontrollerar inte certifikatkedja eller värdnamn. Det liknar äldre TLS-beteende utan serverautentisering.

Läget är sårbart för man-in-the-middle-attacker. Använd det bara tillfälligt för kompatibilitet eller diagnostik. Föredra builtin eller custom i produktion.

Krav och viktiga avgränsningar

Konfigurations-API:erna för TLS CA kräver aktiverad Local Admin Security. Varje begäran måste innehålla konfigurerat administratörsanvändarnamn och lösenord via HTTP Basic Authentication.

Datorn som kör curl eller Swagger UI måste nå enhetens lokala IP. MQTTS- och HTTPS-klienterna delar ett verifieringsläge och en egen CA, så ändringen gäller det säkra uppladdningsläge som enheten använder.

Starta om enheten efter ändrad TLS-konfiguration så att den utgående klienten återskapas med de nya inställningarna.

Exemplen använder dessa platshållare:

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

Ersätt dem med verklig enhetsadress och administratörsuppgifter.

Kontrollera aktuellt TLS-läge

API:

GET /api/tls/ca/status

Exempel:

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

Exempelsvar:

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

Svaret visar valt läge och, om en egen CA finns lagrad, dess längd och SHA-256-hash.

Välj builtin-verifiering

API:

POST /api/tls/ca/select

Exempel:

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

Starta om enheten efter ett lyckat svar.

Välj none för tillfällig diagnostik

API:

POST /api/tls/ca/select

Exempel:

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

Svaret varnar för att servercertifikatverifieringen är inaktiverad. Starta om efter lägesbytet och återgå till builtin eller custom efter diagnostiken.

Ladda upp och välj en egen CA

Att ladda upp en CA och välja custom är separata åtgärder. Uppladdningen ändrar inte automatiskt det aktiva läget.

Krav på egen CA-fil

Den uppladdade filen måste uppfylla alla följande krav:

• PEM-certifikatformat;
• rå begärandekropp, inte JSON eller multipart/form-data;
• Content-Type: application/x-pem-file;
• längd 1–3072 byte inklusive PEM-rubriker, radslut och blanktecken;
• innehåller -----BEGIN CERTIFICATE----- och -----END CERTIFICATE-----;
• innehåller ingen privat nyckel.

Gränsen 3072 byte gäller hela HTTP-begärandekroppen. En PEM-fil på 3072 byte accepteras; en på 3073 byte avvisas.

Kontrollera filstorleken före uppladdning:

wc -c root-ca.pem

Steg 1: Ladda upp CA:n

API:

POST /api/tls/ca/upload

Exempel:

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

Exempel på lyckat svar:

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

Enheten lagrar CA:n i flera KV-block och verifierar sparad längd och SHA-256-hash innan den markeras aktiv. En avbruten skrivning ersätter inte den tidigare giltiga CA:n.

Steg 2: Välj custom

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

Enheten avvisar begäran om ingen giltig egen CA är lagrad. Den växlar inte tyst till none.

Steg 3: Starta om och verifiera

Starta om från enhetens lokala webbgränssnitt eller använd det skyddade omstarts-API:et:

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

När enheten har återanslutit frågar du efter status igen:

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

Bekräfta att mode är custom, att customCaValid är 1 och att rapporterad längd och SHA-256-hash matchar det uppladdade certifikatet.

Ta bort egen CA

API:

POST /api/tls/ca/delete

Exempel:

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

Att ta bort egen CA återställer också läget till builtin. Starta om enheten efter borttagningen.

Använd IAMMETER Swagger UI

Samma API:er kan testas utan att skriva curl-kommandon manuellt:

IAMMETER WEM API Test - TLS CA

1. Öppna WEM API Test på en dator som når enhetens lokala IP.
2. Ange enhetens adress, exempelvis 192.168.1.80, och välj Apply.
3. Välj Authorize och ange administratörsanvändarnamn och lösenord.
4. Öppna gruppen TLS CA - Authenticated.
5. Använd GET /api/tls/ca/status för att granska konfigurationen.
6. Använd uppladdning, val eller borttagning efter behov.
7. Starta om efter ändring av läge eller certifikat.

Swagger-sidan körs i webbläsaren och skickar begäranden direkt från datorn till IAMMETER-enheten. Den använder inte IAMMETER Cloud som proxy, så webbläsaren behöver direkt nätverkskontakt med enhetens IP.

Felsök certifikatverifieringen

admin security required

Aktivera Local Admin Security innan du använder TLS CA-API:erna. Dessa inställningar kan inte ändras anonymt.

custom CA is missing or invalid

Ladda upp en giltig PEM-CA innan du väljer custom. Fråga /api/tls/ca/status och bekräfta att customCaValid är 1.

TLS-anslutningen misslyckas i builtin eller custom

Kontrollera samtliga punkter:

• konfigurerat värdnamn eller IP matchar certifikatets SAN;
• certifikatet är giltigt nu och enhetens tid är korrekt;
• servern skickar nödvändiga mellanliggande certifikat;
• vald rot-CA har utfärdat eller via kedjan litar på servercertifikatet;
• enheten startades om efter TLS-ändringen.

TLS fungerar i none men inte i verifierade lägen

Det tyder oftast på problem med certifikatkedjan, värdnamnet, giltighetstiden eller enhetens klocka. Att behålla none döljer autentiseringsfelet men löser det inte. Rätta certifikatinstallationen eller ladda upp rätt rot-CA och använd custom.