Hantera IoT Edge-certifikat
Gäller för: IoT Edge 1.5 IoT Edge 1.4
Viktigt!
IoT Edge 1.5 LTS och IoT Edge 1.4 LTS stöds. IoT Edge 1.4 LTS upphör den 12 november 2024. Om du har en tidigare version läser du Uppdatera IoT Edge.
Alla IoT Edge-enheter använder certifikat för att skapa säkra anslutningar mellan körningen och de moduler som körs på enheten. IoT Edge-enheter som fungerar som gatewayer använder samma certifikat för att ansluta till sina underordnade enheter också.
Kommentar
Termen rotcertifikatutfärdare som används i den här artikeln refererar till den översta utfärdarens certifikat i certifikatkedjan för din IoT-lösning. Du behöver inte använda certifikatroten för en syndikerad certifikatutfärdare eller roten för organisationens certifikatutfärdare. Ofta är det faktiskt ett mellanliggande CA-certifikat.
Förutsättningar
Du bör känna till begreppen i Förstå hur Azure IoT Edge använder certifikat, särskilt hur IoT Edge använder certifikat.
En IoT Edge-enhet.
Om du inte har konfigurerat en IoT Edge-enhet kan du skapa en på en virtuell Azure-dator. Följ stegen i någon av de här snabbstartsartiklarna för att skapa en virtuell Linux-enhet eller Skapa en virtuell Windows-enhet.
Möjlighet att redigera IoT Edge-konfigurationsfilen
config.toml
efter konfigurationsmallen.Om du
config.toml
inte är baserad på mallen öppnar du mallen och använder den kommenterade vägledningen för att lägga till konfigurationsavsnitt efter mallens struktur.Om du har en ny IoT Edge-installation som inte har konfigurerats kopierar du mallen för att initiera konfigurationen. Använd inte det här kommandot om du har en befintlig konfiguration. Filen skrivs över.
sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
Formatkrav
Dricks
- Ett certifikat kan kodas i en binär representation med namnet DER (Distinguished Encoding Rules) eller en textrepresentation med namnet PEM (Privacy Enhanced Mail). PEM-formatet har ett
-----BEGIN CERTIFICATE-----
sidhuvud följt av base64-kodad DER följt av en-----END CERTIFICATE-----
sidfot. - På samma sätt som certifikatet kan den privata nyckeln kodas i binär DER eller textrepresentations-PEM.
- Eftersom PEM är avgränsat är det också möjligt att konstruera en PEM som kombinerar både
CERTIFICATE
ochPRIVATE KEY
sekventiellt i samma fil. - Slutligen kan certifikatet och den privata nyckeln kodas tillsammans i en binär representation med namnet PKCS#12, som krypteras med ett valfritt lösenord.
Filnamnstillägg är godtyckliga och du måste köra file
kommandot eller visa filen för att verifiera typen. I allmänhet använder filer följande tilläggskonventioner:
.cer
är ett certifikat i DER- eller PEM-formulär..pem
är antingen ett certifikat, en privat nyckel eller båda i PEM-format..pfx
är en PKCS#12-fil .
IoT Edge kräver att certifikatet och den privata nyckeln är:
- PEM-format
- Separata filer
- I de flesta fall med hela kedjan
Om du får en .pfx
fil från PKI-providern är det troligtvis certifikatet och den privata nyckeln som kodas tillsammans i en fil. Kontrollera att det är en PKCS#12-filtyp med hjälp file
av kommandot . Du kan konvertera en PKCS#12-fil .pfx
till PEM-filer med hjälp av kommandot openssl pkcs12.
Om PKI-providern tillhandahåller en .cer
fil kan den innehålla samma certifikat som .pfx
, eller så kan det vara PKI-providerns utfärdande (rotcertifikat). Kontrollera filen med openssl x509
kommandot . Om det är det utfärdande certifikatet:
- Om det är i DER-format (binärt) konverterar du det till PEM med
openssl x509 -in cert.cer -out cert.pem
. - Använd PEM-filen som förtroendepaket. Mer information om säkerhetspaketet finns i nästa avsnitt.
Viktigt!
PKI-infrastrukturen bör ha stöd för RSA-2048-bitarsnycklar och EC P-256-nycklar. Dina EST-servrar bör till exempel ha stöd för dessa nyckeltyper. Du kan använda andra nyckeltyper, men vi testar bara RSA-2048-bitarsnycklar och EC P-256-nycklar.
Behörighet som krävs
I följande tabell visas de fil- och katalogbehörigheter som krävs för IoT Edge-certifikaten. Den föredragna katalogen för certifikaten är /var/aziot/certs/
och /var/aziot/secrets/
för nycklar.
Fil eller katalog | Behörigheter | Ägare |
---|---|---|
/var/aziot/certs/ certifikatkatalog |
drwxr-xr-x (755) | aziotcs |
Certifikatfiler i /var/aziot/certs/ |
-wr-r--r-- (644) | aziotcs |
/var/aziot/secrets/ nyckelkatalog |
drwx------ (700) | aziotks |
Nyckelfiler i /var/aziot/secrets/ |
-wr------- (600) | aziotks |
Om du vill skapa katalogerna anger du behörigheterna och anger ägaren genom att köra följande kommandon:
# If the certificate and keys directories don't exist, create, set ownership, and set permissions
sudo mkdir -p /var/aziot/certs
sudo chown aziotcs:aziotcs /var/aziot/certs
sudo chmod 755 /var/aziot/certs
sudo mkdir -p /var/aziot/secrets
sudo chown aziotks:aziotks /var/aziot/secrets
sudo chmod 700 /var/aziot/secrets
# Give aziotcs ownership to certificates
# Read and write for aziotcs, read-only for others
sudo chown -R aziotcs:aziotcs /var/aziot/certs
sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \;
# Give aziotks ownership to private keys
# Read and write for aziotks, no permission for others
sudo chown -R aziotks:aziotks /var/aziot/secrets
sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \;
# Verify permissions of directories and files
sudo ls -Rla /var/aziot
Utdata från listan med rätt ägarskap och behörighet liknar följande utdata:
azureUser@vm:/var/aziot$ sudo ls -Rla /var/aziot
/var/aziot:
total 16
drwxr-xr-x 4 root root 4096 Dec 14 00:16 .
drwxr-xr-x 15 root root 4096 Dec 14 00:15 ..
drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 14 00:31 certs
drwx------ 2 aziotks aziotks 4096 Jan 23 17:23 secrets
/var/aziot/certs:
total 20
drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 14 00:31 .
drwxr-xr-x 4 root root 4096 Dec 14 00:16 ..
-rw-r--r-- 1 aziotcs aziotcs 1984 Jan 14 00:24 azure-iot-test-only.root.ca.cert.pem
-rw-r--r-- 1 aziotcs aziotcs 5887 Jan 14 00:27 iot-edge-device-ca-devicename-full-chain.cert.pem
/var/aziot/secrets:
total 16
drwx------ 2 aziotks aziotks 4096 Jan 23 17:23 .
drwxr-xr-x 4 root root 4096 Dec 14 00:16 ..
-rw------- 1 aziotks aziotks 3243 Jan 14 00:28 iot-edge-device-ca-devicename.key.pem
Hantera betrodd rotcertifikatutfärdarcertifikatutfärdarcertifikat (förtroendepaket)
Att använda ett självsignerat certifikatutfärdarcertifikat (CA) som en rot av förtroende med IoT Edge och moduler kallas för förtroendepaket. Förtroendepaketet är tillgängligt för IoT Edge och moduler för kommunikation med servrar. Om du vill konfigurera säkerhetspaketet anger du dess filsökväg i IoT Edge-konfigurationsfilen.
Hämta rotcertifikatutfärdarcertifikatet från en PKI-provider.
Kontrollera att certifikatet uppfyller formatkraven.
Kopiera PEM-filen och ge IoT Edge-certifikattjänsten åtkomst. Till exempel med
/var/aziot/certs
katalog:# Make the directory if doesn't exist sudo mkdir /var/aziot/certs -p # Change cert directory user and group ownership to aziotcs and set permissions sudo chown aziotcs:aziotcs /var/aziot/certs sudo chmod 755 /var/aziot/certs # Copy certificate into certs directory sudo cp root-ca.pem /var/aziot/certs # Give aziotcs ownership to certificate and set read and write permission for aziotcs, read-only for others sudo chown aziotcs:aziotcs /var/aziot/certs/root-ca.pem sudo chmod 644 /var/aziot/certs/root-ca.pem
I IoT Edge-konfigurationsfilen
config.toml
hittar du avsnittet Säkerhetspaketcertifikat . Om avsnittet saknas kan du kopiera det från konfigurationsmallfilen.Dricks
Om konfigurationsfilen inte finns på enheten ännu använder
/etc/aziot/config.toml.edge.template
du den som mall för att skapa en.trust_bundle_cert
Ange nyckeln till certifikatfilens plats.trust_bundle_cert = "file:///var/aziot/certs/root-ca.pem"
Tillämpa konfigurationen.
sudo iotedge config apply
Installera rotcertifikatutfärdare till OS-certifikatarkivet
Om du installerar certifikatet i säkerhetspaketfilen blir det tillgängligt för containermoduler men inte för att vara värd för moduler som Azure Device Update eller Defender. Om du använder komponenter på värdnivå eller stöter på andra TLS-problem installerar du även rotcertifikatutfärdarcertifikatet till operativsystemets certifikatarkiv:
sudo cp /var/aziot/certs/my-root-ca.pem /usr/local/share/ca-certificates/my-root-ca.pem.crt
sudo update-ca-certificates
Importera certifikat- och privata nyckelfiler
IoT Edge kan använda befintliga certifikat och privata nyckelfiler för att autentisera eller intyga till Azure, utfärda nya modulservercertifikat och autentisera till EST-servrar. Så här installerar du dem:
Kontrollera att certifikat- och privata nyckelfiler uppfyller formatkraven.
Kopiera PEM-filen till den IoT Edge-enhet där IoT Edge-moduler kan ha åtkomst. Till exempel katalogen
/var/aziot/
.# If the certificate and keys directories don't exist, create, set ownership, and set permissions sudo mkdir -p /var/aziot/certs sudo chown aziotcs:aziotcs /var/aziot/certs sudo chmod 755 /var/aziot/certs sudo mkdir -p /var/aziot/secrets sudo chown aziotks:aziotks /var/aziot/secrets sudo chmod 700 /var/aziot/secrets # Copy certificate and private key into the correct directory sudo cp my-cert.pem /var/aziot/certs sudo cp my-private-key.pem /var/aziot/secrets
Bevilja ägarskap till IoT Edge-certifikattjänsten
aziotcs
och nyckeltjänstenaziotks
till certifikatet respektive den privata nyckeln.# Give aziotcs ownership to certificate # Read and write for aziotcs, read-only for others sudo chown aziotcs:aziotcs /var/aziot/certs/my-cert.pem sudo chmod 644 /var/aziot/certs/my-cert.pem # Give aziotks ownership to private key # Read and write for aziotks, no permission for others sudo chown aziotks:aziotks /var/aziot/secrets/my-private-key.pem sudo chmod 600 /var/aziot/secrets/my-private-key.pem
I
config.toml
hittar du det relevanta avsnittet för vilken typ av certifikat som ska konfigureras. Du kan till exempel söka efter nyckelordetcert
.Med hjälp av exemplet från konfigurationsmallen konfigurerar du enhetsidentitetscertifikatet eller Edge CA-filerna. Exempelmönstret är:
cert = "file:///var/aziot/certs/my-cert.pem" pk = "file:///var/aziot/secrets/my-private-key.pem"
Tillämpa konfigurationen
sudo iotedge config apply
Kom ihåg att uppdatera filerna och konfigurationen manuellt innan certifikatet upphör att gälla för att förhindra fel när certifikaten upphör att gälla.
Exempel: Använda enhetsidentitetscertifikatfiler från PKI-providern
Begär ett TLS-klientcertifikat och en privat nyckel från PKI-providern.
Krav för enhetsidentitetscertifikat:
- Standardklientcertifikattillägg: extendedKeyUsage = clientAuth keyUsage = critical, digitalSignature
- Nyckelidentifierare som hjälper dig att skilja mellan utfärdande certifikatutfärdare med samma CN för CA-certifikatrotation.
- subjectKeyIdentifier = hash
- authorityKeyIdentifier = keyid:always,issuer:always
Kontrollera att det gemensamma namnet (CN) matchar IoT Edge-enhets-ID:t som registrerats med IoT Hub eller registrerings-ID med DPS. I följande enhetsidentitetscertifikat Subject: CN = my-device
är det till exempel det viktiga fält som måste matcha.
Exempel på enhetsidentitetscertifikat:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 48 (0x30)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN = myPkiCA
Validity
Not Before: Jun 28 21:27:30 2022 GMT
Not After : Jul 28 21:27:30 2022 GMT
Subject: CN = my-device
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:ad:b0:63:1f:48:19:9e:c4:9d:91:d1:b0:b0:e5:
...
80:58:63:6d:ab:56:9f:90:4e:3f:dd:df:74:cf:86:
04:af
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Subject Key Identifier:
C7:C2:DC:3C:53:71:B8:42:15:D5:6C:4B:5C:03:C2:2A:C5:98:82:7E
X509v3 Authority Key Identifier:
keyid:6E:57:C7:FC:FE:50:09:75:FA:D9:89:13:CB:D2:CA:F2:28:EF:9B:F6
Signature Algorithm: ecdsa-with-SHA256
30:45:02:20:3c:d2:db:06:3c:d7:65:b7:22:fe:df:9e:11:5b:
...
eb:da:fc:f1:6a:bf:31:63:db:5a:16:02:70:0f:cf:c8:e2
-----BEGIN CERTIFICATE-----
MIICdTCCAhugAwIBAgIBMDAKBggqhkjOPQQDAjAXMRUwEwYDVQQDDAxlc3RFeGFt
...
354RWw+eLOpQSkTqXxzjmfw/kVOOAQIhANvRmyCQVb8zLPtqdOVRkuva/PFqvzFj
21oWAnAPz8ji
-----END CERTIFICATE-----
Dricks
Om du vill testa utan åtkomst till certifikatfiler som tillhandahålls av en PKI läser du Skapa democertifikat för att testa enhetsfunktioner för att generera ett kortlivat identitetscertifikat för icke-produktionsenheter och en privat nyckel.
Konfigurationsexempel vid etablering med IoT Hub:
[provisioning]
source = "manual"
# ...
[provisioning.authentication]
method = "x509"
identity_cert = "file:///var/aziot/device-id.pem"
identity_pk = "file:///var/aziot/device-id.key.pem"
Konfigurationsexempel vid etablering med DPS:
[provisioning]
source = "dps"
# ...
[provisioning.attestation]
method = "x509"
registration_id = "my-device"
identity_cert = "file:///var/aziot/device-id.pem"
identity_pk = "file:///var/aziot/device-id.key.pem"
Omkostnader med manuell certifikathantering kan vara riskfyllda och felbenägna. För produktion rekommenderas användning av IoT Edge med automatisk certifikathantering.
Hantera Edge CA
Edge CA har två olika lägen:
- Snabbstart är standardbeteendet. Snabbstarten är avsedd för testning och är inte lämplig för produktion.
- Produktionsläget kräver att du anger din egen källa för Edge CA-certifikat och privat nyckel.
Snabbstart Edge CA
För att komma igång genererar IoT Edge automatiskt ett Edge CA-certifikat när det startas för första gången som standard. Det här självsignerade certifikatet är endast avsett för utvecklings- och testscenarier, inte produktion. Som standard upphör certifikatet att gälla efter 90 dagar. Förfallodatum kan konfigureras. Det här beteendet kallas snabbstart för Edge CA.
Snabbstart Edge CA gör det möjligt edgeHub
för och andra IoT Edge-moduler att ha ett giltigt servercertifikat när IoT Edge först installeras utan konfiguration. Certifikatet behövs eftersom edgeHub
moduler eller underordnade enheter behöver upprätta säkra kommunikationskanaler. Utan snabbstartscertifikatutfärdare för Edge skulle det vara betydligt svårare att komma igång eftersom du skulle behöva ange ett giltigt servercertifikat från en PKI-provider eller med verktyg som openssl
.
Viktigt!
Använd aldrig snabbstartscertifikatutfärdare för produktion eftersom det lokalt genererade certifikatet i den inte är ansluten till en PKI.
Säkerheten för en certifikatbaserad identitet härleds från en välhanterad PKI (infrastrukturen) där certifikatet (ett dokument) bara är en komponent. En välhanterad PKI gör det möjligt för definition, program, hantering och tillämpning av säkerhetsprinciper att inkludera men inte begränsat till certifikatutfärdande, återkallande och livscykelhantering.
Anpassa livslängden för snabbstarts-Edge CA
Om du vill konfigurera certifikatets giltighetstid till något annat än standardvärdet 90 dagar lägger du till värdet i dagar i avsnittet Edge CA-certifikat (snabbstart) i konfigurationsfilen.
[edge_ca]
auto_generated_edge_ca_expiry_days = 180
Ta bort innehållet i mapparna /var/lib/aziot/certd/certs
och /var/lib/aziot/keyd/keys
för att ta bort tidigare genererade certifikat och tillämpa sedan konfigurationen.
Förnya snabbstart Edge CA
Som standard förnyar IoT Edge automatiskt snabbstartscertifikatutfärdarcertifikatet för Edge när det är 80 % av certifikatets livslängd. Om ett certifikat till exempel har en livslängd på 90 dagar återskapar IoT Edge automatiskt Edge CA-certifikatet efter 72 dagar från utfärdandet.
Om du vill ändra logiken för automatisk förnyelse lägger du till följande inställningar i avsnittet Edge CA-certifikat i config.toml
. Till exempel:
[edge_ca.auto_renew]
rotate_key = true
threshold = "70%"
retry = "2%"
Edge CA i produktion
När du har flyttat in i ett produktionsscenario, eller om du vill skapa en gatewayenhet, kan du inte längre använda snabbstartens Edge CA.
Ett alternativ är att ange egna certifikat och hantera dem manuellt. För att undvika den riskfyllda och felbenägna manuella certifikathanteringsprocessen använder du dock en EST-server när det är möjligt.
Varning
Det gemensamma namnet (CN) för Edge CA-certifikatet kan inte matcha parametern för enhetsvärdnamn som definierats i enhetens konfigurationsfil config.toml eller enhets-ID:t som registrerats i IoT Hub.
Planera för förnyelse av Edge CA
När Edge CA-certifikatet förnyas återskapas alla certifikat som utfärdats som modulservercertifikat. För att ge modulerna nya servercertifikat startar IoT Edge om alla moduler när Edge CA-certifikatet förnyas.
Om du vill minimera potentiella negativa effekter av omstarter av modulen planerar du att förnya Edge CA-certifikatet vid en viss tidpunkt (till exempel threshold = "10d"
) och meddela beroenden av lösningen om stilleståndstiden.
Exempel: Använd Edge CA-certifikatfiler från PKI-provider
Begär följande filer från PKI-providern:
- PKI:s rotcertifikatutfärdarcertifikat
- Ett utfärdande/CA-certifikat och tillhörande privat nyckel
För att det utfärdande CA-certifikatet ska bli Edge CA måste det ha följande tillägg:
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, digitalSignature, keyCertSign
Exempel på resultatet Edge CA-certifikat:
openssl x509 -in my-edge-ca-cert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4098 (0x1002)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = myPkiCA
Validity
Not Before: Aug 27 00:00:50 2022 GMT
Not After : Sep 26 00:00:50 2022 GMT
Subject: CN = my-edge-ca.ca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
00:e1:cb:9c:c0:41:d2:ee:5d:8b:92:f9:4e:0d:3e:
...
25:f5:58:1e:8c:66:ab:d1:56:78:a5:9c:96:eb:01:
e4:e3:49
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
FD:64:48:BB:41:CE:C1:8A:8A:50:9B:2B:2D:6E:1D:E5:3F:86:7D:3E
X509v3 Authority Key Identifier:
keyid:9F:E6:D3:26:EE:2F:D7:84:09:63:84:C8:93:72:D5:13:06:8E:7F:D1
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Key Usage: critical
Digital Signature, Certificate Sign
Signature Algorithm: sha256WithRSAEncryption
20:c9:34:41:a3:a4:8e:7c:9c:6e:17:f5:a6:6f:e5:fc:6e:59:
...
7c:20:5d:e5:51:85:4c:4d:f7:f8:01:84:87:27:e3:76:65:47:
9e:6a:c3:2e:1a:f0:dc:9d
-----BEGIN CERTIFICATE-----
MIICdTCCAhugAwIBAgIBMDAKBggqhkjOPQQDAjAXMRUwEwYDVQQDDAxlc3RFeGFt
...
354RWw+eLOpQSkTqXxzjmfw/kVOOAQIhANvRmyCQVb8zLPtqdOVRkuva/PFqvzFj
21oWAnAPz8ji
-----END CERTIFICATE-----
När du har fått de senaste filerna uppdaterar du säkerhetspaketet:
trust_bundle_cert = "file:///var/aziot/root-ca.pem"
Konfigurera sedan IoT Edge för att använda certifikat- och privata nyckelfiler:
[edge_ca]
cert = "file:///var/aziot/my-edge-ca-cert.pem"
pk = "file:///var/aziot/my-edge-ca-private-key.key.pem"
Om du har använt andra certifikat för IoT Edge på enheten tidigare tar du bort filerna i /var/lib/aziot/certd/certs
och de privata nycklar som är associerade med certifikat (inte alla nycklar) i /var/lib/aziot/keyd/keys
. IoT Edge återskapar dem med det nya CA-certifikatet som du angav.
Den här metoden kräver att du uppdaterar filerna manuellt när certifikatet upphör att gälla. Undvik det här problemet genom att överväga att använda EST för automatisk hantering.
Automatisk certifikathantering med EST-server
IoT Edge kan interagera med en EST-server (Enrollment over Secure Transport) för automatisk utfärdande och förnyelse av certifikat. Est rekommenderas för produktion eftersom det ersätter behovet av manuell certifikathantering, vilket kan vara riskabelt och felbenäget. Den kan konfigureras globalt och åsidosättas för varje certifikattyp.
I det här scenariot förväntas bootstrap-certifikatet och den privata nyckeln vara långlivade och eventuellt installerade på enheten under tillverkningen. IoT Edge använder bootstrap-autentiseringsuppgifterna för att autentisera till EST-servern för den första begäran om att utfärda ett identitetscertifikat för efterföljande begäranden och för autentisering till DPS eller IoT Hub.
Få åtkomst till en EST-server. Om du inte har någon EST-server använder du något av följande alternativ för att börja testa:
Skapa en TEST EST-server med hjälp av stegen i Självstudie: Konfigurera registrering över säker transportserver för Azure IoT Edge.
Microsoft samarbetar med GlobalSign för att tillhandahålla ett demokonto.
I konfigurationsfilen
config.toml
för IoT Edge-enheten konfigurerar du sökvägen till ett betrott rotcertifikat som IoT Edge använder för att verifiera EST-serverns TLS-certifikat. Det här steget är valfritt om EST-servern har ett offentligt betrott rot-TLS-certifikat.[cert_issuance.est] trusted_certs = [ "file:///var/aziot/root-ca.pem", ]
Ange en standard-URL för EST-servern. I
config.toml
lägger du till följande avsnitt med URL:en för EST-servern:[cert_issuance.est.urls] default = "https://example.org/.well-known/est"
Om du vill konfigurera EST-certifikatet för autentisering lägger du till följande avsnitt med sökvägen till certifikatet och den privata nyckeln:
[cert_issuance.est.auth] bootstrap_identity_cert = "file:///var/aziot/my-est-id-bootstrap-cert.pem" bootstrap_identity_pk = "file:///var/aziot/my-est-id-bootstrap-pk.key.pem" [cert_issuance.est.identity_auto_renew] rotate_key = true threshold = "80%" retry = "4%"
Tillämpa konfigurationsändringarna.
sudo iotedge config apply
Inställningarna i [cert_issuance.est.identity_auto_renew]
beskrivs i nästa avsnitt.
Autentisering av användarnamn och lösenord
Om det inte går att autentisering till EST-servern med certifikat kan du använda en delad hemlighet eller ett användarnamn och lösenord i stället.
[cert_issuance.est.auth]
username = "username"
password = "password"
Konfigurera parametrar för automatisk förnyelse
I stället för att hantera certifikatfilerna manuellt har IoT Edge den inbyggda möjligheten att hämta och förnya certifikat innan de upphör att gälla. Certifikatförnyelse kräver en utfärdandemetod som IoT Edge kan hantera. Registrering via EN EST-server (Secure Transport) är en utfärdandemetod, men IoT Edge kan också automatiskt förnya snabbstartscertifikatutfärdarcertifikatutfärdarna som standard. Certifikatförnyelse konfigureras per typ av certifikat.
I
config.toml
hittar du det relevanta avsnittet för vilken typ av certifikat som ska konfigureras. Du kan till exempel söka efter nyckelordetauto_renew
.Med hjälp av exemplet från konfigurationsmallen konfigurerar du enhetsidentitetscertifikatet, Edge CA eller EST-identitetscertifikat. Exempelmönstret är:
[REPLACE_WITH_CERT_TYPE] # ... method = "est" # ... [REPLACE_WITH_CERT_TYPE.auto_renew] rotate_key = true threshold = "80%" retry = "4%"
Tillämpa konfigurationen
sudo iotege config apply
I följande tabell visas vad varje alternativ i auto_renew
gör:
Parameter | Description |
---|---|
rotate_key |
Styr om den privata nyckeln ska roteras när IoT Edge förnyar certifikatet. |
threshold |
Anger när IoT Edge ska börja förnya certifikatet. Det kan anges som: - Procent: heltal mellan 0 och 100 följt av % . Förnyelsen startar i förhållande till certifikatets livslängd. När det till 80% exempel är inställt på börjar ett certifikat som är giltigt i 100 dagar att förnyas 20 dagar innan det upphör att gälla. - Absolut tid: heltal följt av min (minuter) eller day (dagar). Förnyelsen startar i förhållande till certifikatets förfallotid. När det till 4day exempel är inställt på i fyra dagar eller 10min i 10 minuter börjar certifikatet förnyas vid den tidpunkten innan det upphör att gälla. För att undvika oavsiktlig felkonfiguration där threshold är större än certifikatets livslängd rekommenderar vi att du använder procent i stället när det är möjligt. |
retry |
styr hur ofta förnyelse ska göras om vid fel. Precis som threshold kan den anges som en procentandel eller absolut tid med samma format. |
Exempel: förnya enhetsidentitetscertifikatet automatiskt med EST
Om du vill använda EST och IoT Edge för automatisk utfärdande och förnyelse av enhetsidentitetscertifikat, vilket rekommenderas för produktion, måste IoT Edge etableras som en del av en DPS CA-baserad registreringsgrupp. Till exempel:
## DPS provisioning with X.509 certificate
[provisioning]
source = "dps"
# ...
[provisioning.attestation]
method = "x509"
registration_id = "my-device"
[provisioning.attestation.identity_cert]
method = "est"
common_name = "my-device"
[provisioning.attestation.identity_cert.auto_renew]
rotate_key = true
threshold = "80%"
retry = "4%"
Automatisk förnyelse för Edge CA måste aktiveras när utfärdandemetoden är inställd på EST. Förfallotid för Edge CA måste undvikas eftersom det bryter många IoT Edge-funktioner. Om en situation kräver total kontroll över Edge CA-certifikatets livscykel använder du den manuella Edge CA-hanteringsmetoden i stället.
Använd inte EST eller auto_renew
med andra etableringsmetoder, inklusive manuell X.509-etablering med IoT Hub och DPS med individuell registrering. IoT Edge kan inte uppdatera certifikatets tumavtryck i Azure när ett certifikat förnyas, vilket förhindrar att IoT Edge återansluter.
Exempel: automatisk Edge CA-hantering med EST
Använd est automatic Edge CA-utfärdande och förnyelse för produktion. När EST-servern har konfigurerats kan du använda den globala inställningen eller åsidosätta den på liknande sätt som i det här exemplet:
[edge_ca]
method = "est"
common_name = "my-edge-CA"
url = "https://ca.example.org/.well-known/est"
bootstrap_identity_cert = "file:///var/aziot/my-est-id-bootstrap-cert.pem"
bootstrap_identity_pk = "file:///var/aziot/my-est-id-bootstrap-pk.key.pem"
[edge_ca.auto_renew]
rotate_key = true
threshold = "90%"
retry = "2%"
Modulservercertifikat
Edge Daemon utfärdar modulserver- och identitetscertifikat för användning av Edge-moduler. Det är fortfarande Edge-modulernas ansvar att förnya sina identitets- och servercertifikat efter behov.
Förnyelse
Servercertifikat kan utfärdas från Edge CA-certifikatet. Oavsett utfärdandemetod måste dessa certifikat förnyas av modulen. Om du utvecklar en anpassad modul måste du implementera förnyelselogik i modulen.
EdgeHub-modulen stöder en funktion för certifikatförnyelse. Du kan konfigurera förnyelse av edgeHub-modulservercertifikatet med hjälp av följande miljövariabler:
- ServerCertificateRenewAfterInMs: Anger varaktigheten i millisekunder när edgeHub-servercertifikatet förnyas oavsett certifikatets giltighetstid.
- MaxCheckCertExpiryInMs: Anger varaktigheten i millisekunder när edgeHub-tjänsten kontrollerar att edgeHub-servercertifikatet upphör att gälla. Om variabeln har angetts utförs kontrollen oavsett certifikatets giltighetstid.
Mer information om miljövariablerna finns i Miljövariabler för EdgeHub och EdgeAgent.
Ändringar i 1.2 och senare
- Certifikatet för enhetscertifikatutfärdare har bytt namn till Edge CA-certifikat.
- Ca-certifikatet för arbetsbelastningen var inaktuellt. Nu genererar IoT Edge-säkerhetshanteraren IoT Edge-hubbservercertifikatet
edgeHub
direkt från Edge CA-certifikatet, utan mellanliggande ca-certifikat för arbetsbelastning mellan dem. - Standardkonfigurationsfilen har ett nytt namn och en ny plats, från
/etc/iotedge/config.yaml
till/etc/aziot/config.toml
som standard. Kommandotiotedge config import
kan användas för att migrera konfigurationsinformation från den gamla platsen och syntaxen till den nya.
Nästa steg
Att installera certifikat på en IoT Edge-enhet är ett nödvändigt steg innan du distribuerar lösningen i produktion. Läs mer om hur du förbereder distributionen av din IoT Edge-lösning i produktion.