Ho sentim, el teu navegador no admet JavaScript!
Inicia sessió

Com configurar la verificació de certificats MQTTS i HTTPS en un mesurador d'energia IAMMETER

Els mesuradors d'energia IAMMETER amb firmware i.91.065.9 i versions posteriors poden verificar el certificat del servidor quan pugen dades mitjançant MQTTS o HTTPS. Això afegeix la verificació de la cadena de certificats i del nom d'amfitrió del servidor per protegir les connexions de sortida.

Aquest article se centra en la configuració de confiança TLS. No configura temes MQTT, càrregues JSON ni la descoberta de Home Assistant. Per al flux de publicació MQTT, consulteu Mesurador d'energia MQTT: publiqueu dades d'IAMMETER al vostre broker MQTT.

En aquesta pàgina

Trieu un mode de verificació de certificats

Els clients MQTTS i HTTPS d'IAMMETER admeten tres modes de verificació del certificat del servidor:

Mode Cadena de certificats Nom d'amfitrió del servidor Ús previst
builtin Verificada amb les CA arrel integrades al firmware Verificat Recomanat per a serveis públics que utilitzen una cadena de certificats compatible
custom Verificada amb una CA arrel PEM proporcionada per l'usuari Verificat PKI privada, desplegaments autosignats o arrels públiques no incloses al firmware
none No verificada No verificat Només per a compatibilitat temporal o diagnòstic

Aquesta configuració s'aplica quan el dispositiu IAMMETER actua com a client TLS i puja dades a un broker MQTTS o a un servidor HTTPS. No habilita HTTPS al servidor web local del dispositiu.

builtin

builtin és el mode per defecte. S'utilitza quan no s'ha desat cap configuració de verificació TLS prèviament i es restaura després d'eliminar la configuració de CA TLS o de restablir el dispositiu als valors de fàbrica.

El firmware conté aquestes CA arrel:

  • DigiCert Global Root G2
  • ISRG Root X1

El dispositiu verifica tant la cadena de certificats com el nom d'amfitrió del servidor. El broker MQTTS o el servidor HTTPS ha de presentar un certificat que enllaci amb una d'aquestes arrels, i el seu Subject Alternative Name (SAN) ha de coincidir amb l'adreça del servidor configurada.

Si l'adreça de càrrega utilitza una adreça IP, el certificat ha de contenir exactament aquesta adreça IP al seu SAN. Un nom DNS no coincideix amb una adreça IP, encara que tots dos resolguin al mateix servidor.

custom

custom fa la mateixa validació de cadena i de nom d'amfitrió que builtin, però confia en el certificat de CA PEM pujat per l'administrador. Utilitzeu-lo quan:

  • el certificat del servidor l'emet una CA privada;
  • el desplegament utilitza un certificat de servidor autosignat; o
  • la CA arrel pública necessària no està inclosa al firmware.

Per a una PKI privada, pugeu el seu certificat de CA arrel. El servidor TLS encara ha d'enviar els certificats intermediaris necessaris durant l'apretada de mans. Per a un certificat de servidor autosignat, aquest certificat es pot pujar com a àncora de confiança, però el seu SAN ha de coincidir igualment amb el nom d'amfitrió o l'adreça IP configurats.

none

none estableix igualment una connexió TLS xifrada, però no verifica la cadena de certificats ni el nom d'amfitrió. Això és similar al comportament TLS heretat sense autenticació del servidor.

Aquest mode és vulnerable a atacs d'intermediari. Utilitzeu-lo només temporalment per a compatibilitat o diagnòstic. En producció, preferiu builtin o custom.

Requisits i límits importants

Les API de configuració de CA TLS requereixen que estigui activada la Local Admin Security. Cada sol·licitud ha d'incloure el nom d'usuari i la contrasenya de l'administrador configurats mitjançant autenticació bàsica HTTP.

L'ordinador que executa curl o la interfície Swagger ha de poder arribar a l'adreça IP local del dispositiu. Els clients MQTTS i HTTPS comparteixen un únic mode de verificació i una única CA personalitzada, de manera que un canvi s'aplica al mode de càrrega segura que utilitzi el dispositiu.

Reinicieu el dispositiu després de canviar la configuració TLS perquè el client de sortida es torni a crear amb la configuració nova.

Els exemples utilitzen aquests marcadors de posició:

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

Substituïu-los per l'adreça real del dispositiu i les credencials de l'administrador.

Comproveu el mode TLS actual

API:

GET /api/tls/ca/status

Exemple:

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

Resposta d'exemple:

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

La resposta indica el mode seleccionat i, quan hi és present, la longitud i el resum SHA-256 de la CA personalitzada desada.

Seleccioneu la verificació builtin

API:

POST /api/tls/ca/select

Exemple:

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

Reinicieu el dispositiu després d'una resposta correcta.

Seleccioneu none per a diagnòstics temporals

API:

POST /api/tls/ca/select

Exemple:

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

La resposta inclou un avís que la verificació del certificat del servidor està desactivada. Reinicieu el dispositiu després de canviar el mode i torneu a builtin o custom un cop acabat el diagnòstic.

Pugeu i seleccioneu una CA personalitzada

Pujar una CA i seleccionar custom són operacions separades. Pujar una CA no canvia automàticament el mode actiu.

Requisits del fitxer de CA personalitzada

El fitxer pujat ha de complir tots aquests requisits:

  • format de certificat PEM;
  • cos de la sol·licitud en brut, no JSON ni multipart/form-data;
  • Content-Type: application/x-pem-file;
  • longitud d'1 a 3072 bytes, incloent-hi les capçaleres PEM, els finals de línia i els espais en blanc;
  • ha de contenir -----BEGIN CERTIFICATE----- i -----END CERTIFICATE-----;
  • no ha de contenir cap clau privada.

El límit de 3072 bytes s'aplica al cos complet de la sol·licitud HTTP. Un fitxer PEM de 3072 bytes s'accepta; un fitxer de 3073 bytes es rebutja.

Comproveu la mida del fitxer abans de pujar-lo:

wc -c root-ca.pem

Pas 1: Pugeu la CA

API:

POST /api/tls/ca/upload

Exemple:

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

Resposta correcta d'exemple:

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

El dispositiu desa la CA en diversos blocs KV i verifica la longitud i el resum SHA-256 desats abans de marcar-la com a activa. Una escriptura interrompuda no substitueix la CA vàlida anterior.

Pas 2: Seleccioneu custom

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

El dispositiu rebutja aquesta sol·licitud quan no hi ha cap CA personalitzada vàlida desada. No recorre silenciosament a none.

Pas 3: Reinicieu i verifiqueu

Reinicieu el dispositiu des de la seva interfície web local o utilitzeu l'API de reinici protegida:

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

Un cop el dispositiu es torni a connectar, consulteu l'estat de nou:

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

Confirmeu que mode és custom, que customCaValid és 1 i que la longitud i el resum SHA-256 indicats coincideixen amb el certificat pujat.

Elimineu la CA personalitzada

API:

POST /api/tls/ca/delete

Exemple:

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

Eliminar la CA personalitzada també restaura el mode a builtin. Reinicieu el dispositiu després d'eliminar-la.

Utilitzeu la interfície Swagger d'IAMMETER

Aquestes mateixes API es poden provar sense escriure manualment comandes curl:

IAMMETER WEM API Test - TLS CA

  1. Obriu la pàgina WEM API Test en un ordinador que pugui arribar a l'adreça IP local del dispositiu.
  2. Introduïu l'adreça del dispositiu, com ara 192.168.1.80, i seleccioneu Apply.
  3. Seleccioneu Authorize i introduïu el nom d'usuari i la contrasenya de l'administrador.
  4. Obriu el grup TLS CA - Authenticated.
  5. Utilitzeu GET /api/tls/ca/status per inspeccionar la configuració actual.
  6. Utilitzeu l'operació de pujada, selecció o eliminació segons calgui.
  7. Reinicieu el dispositiu després de canviar el mode o el certificat.

La pàgina Swagger s'executa al navegador i envia les sol·licituds directament des d'aquell ordinador al dispositiu IAMMETER. No fa de proxy a través d'IAMMETER Cloud, de manera que el navegador ha de tenir connectivitat de xarxa directa amb la IP del dispositiu.

Resoleu problemes de verificació de certificats

admin security required

Activeu la Local Admin Security abans d'utilitzar les API de CA TLS. Aquesta configuració no es pot canviar de manera anònima.

custom CA is missing or invalid

Pugeu correctament una CA PEM vàlida abans de seleccionar custom. Consulteu /api/tls/ca/status i confirmeu que customCaValid és 1.

La connexió TLS falla en builtin o custom

Comproveu tot el següent:

  • el nom d'amfitrió o la IP configurats coincideixen amb el SAN del certificat;
  • el certificat és actualment vàlid i l'hora del dispositiu és correcta;
  • el servidor envia els certificats intermediaris necessaris;
  • la CA arrel seleccionada va emetre el certificat del servidor, o hi confia en última instància;
  • el dispositiu s'ha reiniciat després de canviar la configuració TLS.

TLS funciona amb none però falla en modes verificats

Normalment això indica un problema de cadena de certificats, de nom d'amfitrió, de temps de validesa o de rellotge del dispositiu. Mantenir none activat amaga la fallada d'autenticació, però no la resol. Corregiu el desplegament del certificat o pugeu la CA arrel adequada i utilitzeu custom.

Amunt