Kako nastaviti preverjanje potrdil MQTTS in HTTPS na števcu IAMMETER
Števci IAMMETER s strojno programsko opremo i.91.065.9 in novejšo lahko pri pošiljanju podatkov prek MQTTS ali HTTPS preverijo potrdilo strežnika. S tem varnim odhodnim povezavam dodajo preverjanje verige potrdil in imena strežnika.
Članek se osredotoča na nastavitev zaupanja TLS. Ne nastavlja tem MQTT, podatkov JSON ali odkrivanja Home Assistant. Za objavljanje MQTT glejte Števec MQTT: objavite podatke IAMMETER svojemu posredniku MQTT.
Na tej strani
- Izberite način preverjanja potrdil
- Zahteve in pomembne omejitve
- Preverite trenutni način TLS
- Izberite preverjanje builtin
- Izberite none za začasno diagnostiko
- Naložite in izberite lastni CA
- Izbrišite lastni CA
- Uporabite IAMMETER Swagger UI
- Odpravljanje težav pri preverjanju potrdil
Izberite način preverjanja potrdil
Odjemalca MQTTS in HTTPS v IAMMETER podpirata tri načine preverjanja strežniškega potrdila:
| Način | Veriga potrdil | Ime strežnika | Namen |
|---|---|---|---|
builtin |
Preverjena s korenskimi CA v strojni programski opremi | Preverjeno | Priporočeno za javne storitve s podprto verigo |
custom |
Preverjena z uporabnikovim korenskim PEM CA | Preverjeno | Zasebna PKI, samopodpisana potrdila ali manjkajoči javni koreni |
none |
Ni preverjena | Ni preverjeno | Samo začasna združljivost ali diagnostika |
Nastavitve veljajo, ko naprava IAMMETER deluje kot odjemalec TLS in pošilja podatke posredniku MQTTS ali strežniku HTTPS. Ne omogočijo HTTPS na lokalnem spletnem strežniku naprave.
builtin
builtin je privzeti način. Uporabi se, če nastavitev preverjanja TLS še ni shranjena, in se povrne po brisanju konfiguracije TLS CA ali ponastavitvi naprave na tovarniške nastavitve.
Strojna programska oprema vsebuje te korenske CA:
- DigiCert Global Root G2
- ISRG Root X1
Naprava preverja verigo potrdil in ime strežnika. Posrednik MQTTS ali strežnik HTTPS mora predložiti potrdilo z verigo do enega od teh korenov, njegov Subject Alternative Name (SAN) pa se mora ujemati z nastavljenim naslovom strežnika.
Če naslov za pošiljanje uporablja IP, mora SAN potrdila vsebovati točno ta IP. Ime DNS se ne ujema z naslovom IP, tudi če oba kažeta na isti strežnik.
custom
custom preverja verigo in ime enako kot builtin, vendar zaupa potrdilu PEM CA, ki ga naloži skrbnik. Uporabite ga, ko:
- strežniško potrdilo izda zasebni CA;
- postavitev uporablja samopodpisano strežniško potrdilo; ali
- potrebni javni korenski CA ni vključen v strojno programsko opremo.
Pri zasebni PKI naložite njeno korensko potrdilo CA. Strežnik TLS mora med rokovanjem še vedno poslati potrebna vmesna potrdila. Samopodpisano strežniško potrdilo je mogoče naložiti kot sidro zaupanja, njegov SAN pa se mora še vedno ujemati z nastavljenim imenom ali naslovom IP.
none
none še vedno vzpostavi šifrirano povezavo TLS, vendar ne preverja verige potrdil ali imena strežnika. To je podobno starejšemu TLS brez preverjanja pristnosti strežnika.
Ta način je ranljiv za napade posrednika. Uporabljajte ga samo začasno za združljivost ali diagnostiko. V produkciji dajte prednost builtin ali custom.
Zahteve in pomembne omejitve
Konfiguracijski API-ji TLS CA zahtevajo omogočen Local Admin Security. Vsaka zahteva mora vključevati nastavljeno skrbniško uporabniško ime in geslo prek HTTP Basic Authentication.
Računalnik z curl ali Swagger UI mora doseči lokalni IP naprave. Odjemalca MQTTS in HTTPS si delita en način preverjanja in en lastni CA, zato sprememba velja za varni način pošiljanja, ki ga naprava uporablja.
Po spremembi TLS napravo znova zaženite, da se odhodni odjemalec ustvari z novimi nastavitvami.
Primeri uporabljajo te nadomestne vrednosti:
DEVICE_IP="192.168.1.80"
ADMIN_USER="admin"
ADMIN_PASSWORD="ExamplePassword1"
Zamenjajte jih z dejanskim naslovom naprave in skrbniškimi podatki.
Preverite trenutni način TLS
API:
GET /api/tls/ca/status
Primer:
curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
"http://$DEVICE_IP/api/tls/ca/status"
Primer odgovora:
{
"successful": 1,
"mode": "builtin",
"customCaValid": 0,
"customCaLength": 0,
"customCaSha256": "",
"restartRequiredAfterChange": 1
}
Odgovor prikaže izbrani način ter, če obstaja, dolžino in izvleček SHA-256 shranjenega lastnega CA.
Izberite preverjanje builtin
API:
POST /api/tls/ca/select
Primer:
curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
-X POST "http://$DEVICE_IP/api/tls/ca/select" \
-H "Content-Type: application/json" \
-d '{"mode":"builtin"}'
Po uspešnem odgovoru napravo znova zaženite.
Izberite none za začasno diagnostiko
API:
POST /api/tls/ca/select
Primer:
curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
-X POST "http://$DEVICE_IP/api/tls/ca/select" \
-H "Content-Type: application/json" \
-d '{"mode":"none"}'
Odgovor opozori, da je preverjanje strežniškega potrdila izklopljeno. Po spremembi načina napravo znova zaženite in se po diagnostiki vrnite na builtin ali custom.
Naložite in izberite lastni CA
Nalaganje CA in izbira custom sta ločeni operaciji. Nalaganje ne spremeni samodejno aktivnega načina.
Zahteve za datoteko lastnega CA
Naložena datoteka mora izpolnjevati vse zahteve:
- oblika potrdila PEM;
- surovo telo zahteve, ne JSON ali
multipart/form-data; Content-Type: application/x-pem-file;- dolžina od 1 do 3072 bajtov, skupaj z glavami PEM, konci vrstic in presledki;
- vsebuje
-----BEGIN CERTIFICATE-----in-----END CERTIFICATE-----; - ne vsebuje zasebnega ključa.
Omejitev 3072 bajtov velja za celotno telo HTTP zahteve. Datoteka PEM s 3072 bajti je sprejeta, s 3073 bajti pa zavrnjena.
Pred nalaganjem preverite velikost datoteke:
wc -c root-ca.pem
Korak 1: Naložite CA
API:
POST /api/tls/ca/upload
Primer:
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
Primer uspešnega odgovora:
{
"successful": 1,
"length": 1939,
"sha256": "64-character SHA-256 digest",
"message": "CA uploaded; select custom mode and restart"
}
Naprava shrani CA v več blokov KV in pred oznako aktivnega preveri shranjeno dolžino in izvleček SHA-256. Prekinjen zapis ne zamenja prejšnjega veljavnega CA.
Korak 2: Izberite custom
curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
-X POST "http://$DEVICE_IP/api/tls/ca/select" \
-H "Content-Type: application/json" \
-d '{"mode":"custom"}'
Naprava zavrne zahtevo, če veljaven lastni CA ni shranjen. Ne preklopi tiho na none.
Korak 3: Znova zaženite in preverite
Napravo znova zaženite iz lokalnega spletnega vmesnika ali uporabite zaščiteni API za ponovni zagon:
curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
"http://$DEVICE_IP/api/restart?reset=false"
Ko se naprava znova poveže, ponovno preverite stanje:
curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
"http://$DEVICE_IP/api/tls/ca/status"
Potrdite, da je mode enak custom, customCaValid enak 1, ter da se dolžina in izvleček SHA-256 ujemata z naloženim potrdilom.
Izbrišite lastni CA
API:
POST /api/tls/ca/delete
Primer:
curl --user "$ADMIN_USER:$ADMIN_PASSWORD" \
-X POST "http://$DEVICE_IP/api/tls/ca/delete"
Brisanje lastnega CA povrne tudi način builtin. Po brisanju napravo znova zaženite.
Uporabite IAMMETER Swagger UI
Iste API-je lahko preizkusite brez ročnega pisanja ukazov curl:
IAMMETER WEM API Test - TLS CA
- Odprite WEM API Test v računalniku, ki doseže lokalni IP naprave.
- Vnesite naslov naprave, na primer
192.168.1.80, in izberite Apply. - Izberite Authorize ter vnesite skrbniško ime in geslo.
- Odprite skupino TLS CA - Authenticated.
- S
GET /api/tls/ca/statuspreglejte trenutno konfiguracijo. - Po potrebi uporabite nalaganje, izbiro ali brisanje.
- Po spremembi načina ali potrdila napravo znova zaženite.
Stran Swagger deluje v brskalniku in zahteve pošilja neposredno iz računalnika v napravo IAMMETER. Ne uporablja posredovanja prek IAMMETER Cloud, zato mora imeti brskalnik neposredno omrežno povezavo do IP naprave.
Odpravljanje težav pri preverjanju potrdil
admin security required
Pred uporabo API-jev TLS CA omogočite Local Admin Security. Teh nastavitev ni mogoče spreminjati anonimno.
custom CA is missing or invalid
Pred izbiro custom uspešno naložite veljaven PEM CA. Poizvedite /api/tls/ca/status in potrdite, da je customCaValid enak 1.
Povezava TLS ne uspe v builtin ali custom
Preverite vse naslednje:
- nastavljeno ime ali IP se ujema s SAN potrdila;
- potrdilo je trenutno veljavno in ura naprave je pravilna;
- strežnik pošilja potrebna vmesna potrdila;
- izbrani korenski CA je izdal strežniško potrdilo ali mu zaupa prek verige;
- naprava je bila po spremembi TLS znova zagnana.
TLS deluje v none, v načinih preverjanja pa ne
To običajno kaže na težavo z verigo potrdil, imenom strežnika, časom veljavnosti ali uro naprave. Če pustite none, napako preverjanja pristnosti samo skrijete, ne odpravite. Popravite postavitev potrdil ali naložite ustrezni korenski CA in uporabite custom.
