Konfigurer sertifikatverifisering for MQTTS og HTTPS på en IAMMETER-energimåler

IAMMETER-energimålere med fastvare i.91.065.9 eller nyere kan verifisere serversertifikatet når de laster opp data via MQTTS eller HTTPS. Det legger til kontroll av sertifikatkjeden og serverens vertsnavn for sikre utgående forbindelser.

Artikkelen handler om TLS-tillitskonfigurasjon. Den konfigurerer ikke MQTT-emner, JSON-payloads eller Home Assistant-discovery. Se MQTT-energimåler: publiser IAMMETER-data til din MQTT-broker for MQTT-publisering.

På denne siden

• Velg en sertifikatverifiseringsmodus
• Krav og viktige avgrensninger
• Kontroller gjeldende TLS-modus
• Velg builtin-verifisering
• Velg none for midlertidig diagnostikk
• Last opp og velg en egen CA
• Slett egen CA
• Bruk IAMMETER Swagger UI
• Feilsøk sertifikatverifisering

Velg en sertifikatverifiseringsmodus

IAMMETERs MQTTS- og HTTPS-klienter støtter tre moduser for verifisering av serversertifikater:

Innstillingene gjelder når IAMMETER-enheten er TLS-klient og laster opp data til en MQTTS-broker eller HTTPS-server. De aktiverer ikke HTTPS på enhetens lokale webserver.

builtin

builtin er standardmodus. Den brukes når ingen TLS-verifiseringsinnstilling tidligere er lagret, og gjenopprettes når TLS CA-konfigurasjonen slettes eller enheten tilbakestilles til fabrikkinnstillinger.

Fastvaren inneholder disse rot-CA-ene:

• DigiCert Global Root G2
• ISRG Root X1

Enheten verifiserer både sertifikatkjeden og vertsnavnet. MQTTS-brokeren eller HTTPS-serveren må presentere et sertifikat med en kjede til en av disse røttene, og Subject Alternative Name (SAN) må samsvare med konfigurert serveradresse.

Hvis opplastingsadressen er en IP-adresse, må sertifikatets SAN inneholde nøyaktig den IP-en. Et DNS-navn samsvarer ikke med en IP-adresse selv om begge peker på samme server.

custom

custom utfører samme kjede- og vertsnavnkontroll som builtin, men stoler på PEM-CA-sertifikatet lastet opp av administratoren. Bruk det når:

• serversertifikatet er utstedt av en privat CA;
• oppsettet bruker et selvsignert serversertifikat; eller
• nødvendig offentlig rot-CA ikke finnes i fastvaren.

Ved privat PKI laster du opp rot-CA-sertifikatet. TLS-serveren må fortsatt sende nødvendige mellomsertifikater under håndtrykket. Et selvsignert serversertifikat kan lastes opp som tillitsanker, men SAN må fortsatt samsvare med konfigurert vertsnavn eller IP-adresse.

none

none oppretter fortsatt en kryptert TLS-forbindelse, men verifiserer ikke sertifikatkjeden eller vertsnavnet. Det ligner eldre TLS-oppførsel uten serverautentisering.

Modusen er sårbar for mellommannsangrep. Bruk den bare midlertidig til kompatibilitet eller diagnostikk. Foretrekk builtin eller custom i produksjon.

Krav og viktige avgrensninger

Konfigurasjons-API-ene for TLS CA krever aktivert Local Admin Security. Hver forespørsel må inneholde konfigurert administratorbrukernavn og passord via HTTP Basic Authentication.

Datamaskinen med curl eller Swagger UI må nå enhetens lokale IP. MQTTS- og HTTPS-klientene deler én verifiseringsmodus og én egen CA, så endringen gjelder den sikre opplastingsmodusen enheten bruker.

Start enheten på nytt etter TLS-endringer, slik at den utgående klienten opprettes på nytt med de nye innstillingene.

Eksemplene bruker disse plassholderne:

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

Erstatt dem med faktisk enhetsadresse og administratoropplysninger.

Kontroller gjeldende TLS-modus

API:

GET /api/tls/ca/status

Eksempel:

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

Eksempelsvar:

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

Svaret viser valgt modus og, hvis en egen CA er lagret, lengden og SHA-256-hashen.

Velg builtin-verifisering

API:

POST /api/tls/ca/select

Eksempel:

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

Start enheten på nytt etter et vellykket svar.

Velg none for midlertidig diagnostikk

API:

POST /api/tls/ca/select

Eksempel:

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

Svaret advarer om at serversertifikatverifisering er deaktivert. Start på nytt etter modusendringen, og gå tilbake til builtin eller custom etter diagnostikken.

Last opp og velg en egen CA

Opplasting av en CA og valg av custom er separate handlinger. Opplasting endrer ikke aktiv modus automatisk.

Krav til egen CA-fil

Den opplastede filen må oppfylle alle disse kravene:

• PEM-sertifikatformat;
• rå forespørselskropp, ikke JSON eller multipart/form-data;
• Content-Type: application/x-pem-file;
• 1 til 3072 byte inkludert PEM-overskrifter, linjeskift og blanktegn;
• inneholder -----BEGIN CERTIFICATE----- og -----END CERTIFICATE-----;
• inneholder ingen privat nøkkel.

Grensen på 3072 byte gjelder hele HTTP-forespørselskroppen. En PEM-fil på 3072 byte godtas, en på 3073 byte avvises.

Kontroller filstørrelsen før opplasting:

wc -c root-ca.pem

Trinn 1: Last opp CA-en

API:

POST /api/tls/ca/upload

Eksempel:

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

Eksempel på vellykket svar:

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

Enheten lagrer CA-en i flere KV-blokker og verifiserer lagret lengde og SHA-256-hash før den merkes aktiv. En avbrutt skriving erstatter ikke tidligere gyldig CA.

Trinn 2: Velg 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 avviser forespørselen når ingen gyldig egen CA er lagret. Den faller ikke stille tilbake til none.

Trinn 3: Start på nytt og verifiser

Start enheten på nytt fra lokalt webgrensesnitt, eller bruk det beskyttede omstarts-API-et:

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

Etter at enheten kobler til igjen, spør etter status på nytt:

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

Bekreft at mode er custom, customCaValid er 1, og at rapportert lengde og SHA-256-hash samsvarer med det opplastede sertifikatet.

Slett egen CA

API:

POST /api/tls/ca/delete

Eksempel:

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

Sletting av egen CA gjenoppretter også modusen builtin. Start enheten på nytt etter sletting.

Bruk IAMMETER Swagger UI

De samme API-ene kan testes uten å skrive curl-kommandoer manuelt:

IAMMETER WEM API Test - TLS CA

1. Åpne WEM API Test på en datamaskin som når enhetens lokale IP.
2. Angi enhetsadressen, for eksempel 192.168.1.80, og velg Apply.
3. Velg Authorize, og angi administratorbrukernavn og passord.
4. Åpne gruppen TLS CA - Authenticated.
5. Bruk GET /api/tls/ca/status til å undersøke konfigurasjonen.
6. Bruk opplasting, valg eller sletting etter behov.
7. Start på nytt etter endring av modus eller sertifikat.

Swagger-siden kjører i nettleseren og sender forespørsler direkte fra datamaskinen til IAMMETER-enheten. Den bruker ikke IAMMETER Cloud som proxy, så nettleseren trenger direkte nettverkstilgang til enhetens IP.

Feilsøk sertifikatverifisering

admin security required

Aktiver Local Admin Security før du bruker TLS CA-API-ene. Disse innstillingene kan ikke endres anonymt.

custom CA is missing or invalid

Last opp en gyldig PEM-CA før du velger custom. Spør /api/tls/ca/status, og bekreft at customCaValid er 1.

TLS-forbindelsen feiler i builtin eller custom

Kontroller alle følgende punkter:

• konfigurert vertsnavn eller IP samsvarer med sertifikatets SAN;
• sertifikatet er gyldig nå, og enhetens tid er korrekt;
• serveren sender nødvendige mellomsertifikater;
• valgt rot-CA har utstedt eller via kjeden stoler på serversertifikatet;
• enheten ble startet på nytt etter TLS-endringen.

TLS virker i none, men feiler i verifiserte moduser

Dette tyder vanligvis på et problem med sertifikatkjeden, vertsnavnet, gyldighetsperioden eller enhetens klokke. Å beholde none skjuler autentiseringsfeilen, men løser den ikke. Rett sertifikatoppsettet, eller last opp riktig rot-CA og bruk custom.