Opis sposobu, w jaki usługa Azure IoT Edge używa certyfikatów

Dotyczy: IoT Edge 1.5 IoT Edge 1.4

Ważne

Obsługiwane są wersje usługi IoT Edge 1.5 LTS i IoT Edge 1.4 LTS. Usługa IoT Edge 1.4 LTS kończy się 12 listopada 2024 r. Jeśli korzystasz z wcześniejszej wersji, zobacz aktualizację Azure IoT Edge.

Usługa IoT Edge używa różnych typów certyfikatów do różnych celów. W tym artykule przedstawiono różne sposoby korzystania z certyfikatów usługi IoT Edge w scenariuszach bram usługi Azure IoT Hub i usługi IoT Edge.

Ważne

W przypadku zwięzłości ten artykuł dotyczy usługi IoT Edge w wersji 1.2 lub nowszej. Pojęcia dotyczące certyfikatów w wersji 1.1 są podobne, ale istnieją pewne różnice:

• Nazwa certyfikatu urzędu certyfikacji urządzenia w wersji 1.1 została zmieniona na Certyfikat urzędu certyfikacji usługi Edge.
• Certyfikat urzędu certyfikacji obciążenia w wersji 1.1 został wycofany. W wersji 1.2 lub nowszej środowisko uruchomieniowe modułu usługi IoT Edge generuje wszystkie certyfikaty serwera bezpośrednio z certyfikatu urzędu certyfikacji brzegowego bez pośredniego certyfikatu urzędu certyfikacji między nimi w łańcuchu certyfikatów.

Podsumowanie

Te podstawowe scenariusze to miejsce, w których narzędzia IoT Edge używają certyfikatów. Skorzystaj z linków, aby dowiedzieć się więcej na temat każdego scenariusza.

Aktor	Purpose	Certyfikat
IoT Edge	Zapewnia komunikację z odpowiednim centrum IoT Hub	Certyfikat serwera IoT Hub
Usługa IoT Hub	Pomaga zapewnić, że żądanie pochodzi z wiarygodnego urządzenia usługi IoT Edge	Certyfikat tożsamości IoT Edge
Urządzenie podrzędne IoT	Zapewnia komunikację z odpowiednią bramą Azure IoT Edge	Certyfikat serwera modułu IoT Edge Hub edgeHub, wydany przez urząd certyfikacji usługi Edge
IoT Edge	Podpisuje nowe certyfikaty serwera modułu. Na przykład edgeHub	Certyfikat urzędu certyfikacji usługi Edge
IoT Edge	Pomaga zapewnić, że żądanie pochodzi z wiarygodnego urządzenia podrzędnego	Certyfikat tożsamości urządzenia IoT

Wymagania wstępne

• Musisz mieć podstawową wiedzę na temat kryptografii klucza publicznego, par kluczy oraz sposobu szyfrowania lub odszyfrowywania danych za pomocą klucza publicznego i klucza prywatnego. Aby uzyskać więcej informacji na temat sposobu korzystania z kryptografii klucza publicznego w usłudze IoT Edge, zobacz Understanding Public Key Cryptography and X.509 Public Key Infrastructure (Opis kryptografii klucza publicznego i infrastruktury kluczy publicznych X.509).
• Musisz mieć podstawową wiedzę na temat tego, jak usługa IoT Edge odnosi się do usługi IoT Hub. Aby uzyskać więcej informacji, zobacz Omówienie środowiska uruchomieniowego usługi Azure IoT Edge i jego architektury.

Scenariusz pojedynczego urządzenia

Aby ułatwić zrozumienie pojęć dotyczących certyfikatów usługi IoT Edge, wyobraź sobie scenariusz, w którym urządzenie usługi IoT Edge o nazwie EdgeGateway łączy się z usługą Azure IoT Hub o nazwie ContosoIotHub. W tym przykładzie wszystkie uwierzytelnianie odbywa się przy użyciu uwierzytelniania certyfikatu X.509, a nie kluczy symetrycznych. Aby ustanowić zaufanie w tym scenariuszu, musimy zagwarantować, że urządzenie usługi IoT Hub i usługi IoT Edge jest autentyczne: "Czy to urządzenie jest prawdziwe i prawidłowe?" i "Czy tożsamość usługi IoT Hub jest poprawna?". Scenariusz można zilustrować w następujący sposób:

Wyjaśnimy odpowiedzi na każde pytanie, a następnie rozszerzymy przykład w kolejnych sekcjach artykułu.

Urządzenie weryfikuje tożsamość usługi IoT Hub

Jak usługa EdgeGateway sprawdza, czy komunikuje się z prawdziwą firmą ContosoIotHub? Gdy usługa EdgeGateway chce komunikować się z chmurą, łączy się z punktem końcowym ContosoIoTHub.Azure-devices.NET. Aby upewnić się, że punkt końcowy jest autentyczny, usługa IoT Edge potrzebuje firmy ContosoIoTHub do pokazania identyfikacji (ID). Identyfikator musi być wystawiony przez urząd, któremu ufa EdgeGateway . Aby zweryfikować tożsamość usługi IoT Hub, usługa IoT Edge i usługa IoT Hub używają protokołu uzgadniania TLS do weryfikowania tożsamości serwera usługi IoT Hub. Uzgadnianie protokołu TLS zostało zilustrowane na poniższym diagramie. Aby zachować prosty przykład, pominięto niektóre szczegóły. Aby dowiedzieć się więcej na temat protokołu uzgadniania TLS, zobacz Uzgadnianie protokołu TLS w Wikipedii.

Uwaga

W tym przykładzie contosoIoTHub reprezentuje nazwę hosta usługi IoT Hub ContosoIotHub.Azure-devices.NET.

W tym kontekście nie musisz znać dokładnych szczegółów algorytmu kryptograficznego. Ważne jest, aby zrozumieć, że algorytm gwarantuje, że serwer posiada klucz prywatny sparowany z kluczem publicznym. Sprawdza, czy prezenter certyfikatu nie skopiował go lub ukradł. Jeśli jako przykład użyjemy identyfikatora zdjęcia, twoja twarz pasuje do zdjęcia na identyfikatorze. Jeśli ktoś ukradnie Twój identyfikator, nie może go użyć do identyfikacji, ponieważ twarz jest unikatowa i trudna do odtworzenia. W przypadku kluczy kryptograficznych para kluczy jest powiązana i unikatowa. Zamiast dopasowywać twarz do identyfikatora zdjęcia, algorytm kryptograficzny używa pary kluczy do zweryfikowania tożsamości.

W naszym scenariuszu firma ContosoIotHub przedstawia następujący łańcuch certyfikatów:

Główny urząd certyfikacji (CA) jest certyfikatem głównym Baltimore CyberTrust. Ten certyfikat główny jest podpisany przez firmę DigiCert i jest powszechnie zaufany i przechowywany w wielu systemach operacyjnych. Na przykład zarówno Ubuntu, jak i Windows zawierają go w domyślnym magazynie certyfikatów.

Magazyn certyfikatów systemu Windows:

Magazyn certyfikatów systemu Ubuntu:

Gdy urządzenie sprawdza certyfikat główny Baltimore CyberTrust, jest ono wstępnie zainstalowane w systemie operacyjnym. Z punktu widzenia usługi EdgeGateway , ponieważ łańcuch certyfikatów przedstawiony przez firmę ContosoIotHub jest podpisany przez główny urząd certyfikacji, któremu ufa system operacyjny, certyfikat jest uznawany za zaufany. Certyfikat jest znany jako certyfikat serwera usługi IoT Hub. Aby dowiedzieć się więcej na temat certyfikatu serwera usługi IoT Hub, zobacz Transport Layer Security (TLS) support in IoT Hub (Transport Layer Security) (Obsługa protokołu TLS w usłudze IoT Hub).

Podsumowując, usługa EdgeGateway może zweryfikować tożsamość firmy ContosoIotHub i ufać jej , ponieważ:

• Firma ContosoIotHub prezentuje certyfikat serwera usługi IoT Hub
• Certyfikat serwera jest zaufany w magazynie certyfikatów systemu operacyjnego
• Dane zaszyfrowane przy użyciu klucza publicznego firmy ContosoIotHub mogą być odszyfrowywane przez firmę ContosoIotHub, co potwierdza posiadanie klucza prywatnego

Usługa IoT Hub weryfikuje tożsamość urządzenia usługi IoT Edge

Jak firma ContosoIotHub sprawdza, czy komunikuje się z usługą EdgeGateway? Ponieważ usługa IoT Hub obsługuje wzajemne protokoły TLS (mTLS), sprawdza certyfikat usługi EdgeGateway podczas uzgadniania protokołu TLS uwierzytelnionej przez klienta. Dla uproszczenia pominiemy kilka kroków na poniższym diagramie.

W takim przypadku usługa EdgeGateway udostępnia certyfikat tożsamości urządzenia usługi IoT Edge. Z perspektywy firmy ContosoIotHub sprawdza, czy odcisk palca dostarczonego certyfikatu jest zgodny z jego rekordem, a usługa EdgeGateway ma klucz prywatny sparowany z przedstawionym certyfikatem. Podczas aprowizowania urządzenia usługi IoT Edge w usłudze IoT Hub należy podać odcisk palca. Odcisk palca jest używany przez usługę IoT Hub do weryfikowania certyfikatu.

Napiwek

Usługa IoT Hub wymaga dwóch odcisków palca podczas rejestrowania urządzenia usługi IoT Edge. Najlepszym rozwiązaniem jest przygotowanie dwóch różnych certyfikatów tożsamości urządzeń z różnymi datami wygaśnięcia. W ten sposób, jeśli jeden certyfikat wygaśnie, drugi jest nadal ważny i daje czas na wymianę wygasłego certyfikatu. Jednak do rejestracji można również użyć tylko jednego certyfikatu. Użyj pojedynczego certyfikatu, ustawiając ten sam odcisk palca certyfikatu zarówno dla podstawowych, jak i pomocniczych odcisków palca podczas rejestrowania urządzenia.

Na przykład możemy użyć następującego polecenia, aby uzyskać odcisk palca certyfikatu tożsamości w usłudze EdgeGateway:

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

Polecenie zwraca odcisk palca SHA256 certyfikatu:

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

Jeśli wyświetlimy wartość odcisku palca SHA256 dla urządzenia EdgeGateway zarejestrowanego w usłudze IoT Hub, zobaczymy, że jest on zgodny z odciskiem palca w usłudze EdgeGateway:

Podsumowując, firma ContosoIotHub może ufać usłudze EdgeGateway, ponieważ usługa EdgeGateway przedstawia prawidłowy certyfikat tożsamości urządzenia usługi IoT Edge, którego odcisk palca jest zgodny z tym, który został zarejestrowany w usłudze IoT Hub.

Aby uzyskać więcej informacji na temat procesu tworzenia certyfikatów, zobacz Tworzenie i aprowizowanie urządzenia usługi IoT Edge w systemie Linux przy użyciu certyfikatów X.509.

Uwaga

W tym przykładzie usługa Azure IoT Hub Device Provisioning Service (DPS) nie obsługuje uwierzytelniania urzędu certyfikacji X.509 za pomocą usługi IoT Edge podczas aprowizowania przy użyciu grupy rejestracji. Za pomocą usługi DPS należy przekazać certyfikat urzędu certyfikacji lub certyfikat pośredni, zweryfikować łańcuch certyfikatów, a następnie aprowizować urządzenie. Aby dowiedzieć się więcej, zobacz Zaświadczenie certyfikatu X.509 programu DPS.

W witrynie Azure Portal usługa DPS wyświetla odcisk palca SHA1 dla certyfikatu, a nie odcisk palca SHA256.

Usługa DPS rejestruje lub aktualizuje odcisk palca SHA256 w usłudze IoT Hub. Odcisk palca można sprawdzić przy użyciu polecenia openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256. Po zarejestrowaniu usługa Iot Edge używa uwierzytelniania odciskiem palca w usłudze IoT Hub. Jeśli urządzenie zostanie ponownie aprowidowane i zostanie wystawiony nowy certyfikat, usługa DPS aktualizuje usługę IoT Hub przy użyciu nowego odcisku palca.

Usługa IoT Hub obecnie nie obsługuje uwierzytelniania urzędu certyfikacji X.509 bezpośrednio w usłudze IoT Edge.

Użycie certyfikatu na potrzeby operacji tożsamości modułu

Na diagramach weryfikacji certyfikatu może się wydawać, że usługa IoT Edge używa certyfikatu tylko do komunikacji z usługą IoT Hub. Usługa IoT Edge składa się z kilku modułów. W związku z tym usługa IoT Edge używa certyfikatu do zarządzania tożsamościami modułów dla modułów wysyłających komunikaty. Moduły nie używają certyfikatu do uwierzytelniania w usłudze IoT Hub, ale używają kluczy SAS pochodzących z klucza prywatnego generowanego przez środowisko uruchomieniowe modułu usługi IoT Edge. Te klucze sygnatury dostępu współdzielonego nie zmieniają się nawet wtedy, gdy certyfikat tożsamości urządzenia wygaśnie. Jeśli certyfikat wygaśnie, na przykład usługa edgeHub będzie nadal działać i tylko operacje tożsamości modułu kończą się niepowodzeniem.

Interakcja między modułami a usługą IoT Hub jest bezpieczna, ponieważ klucz SYGNATURy dostępu współdzielonego pochodzi z wpisu tajnego, a usługa IoT Edge zarządza kluczem bez ryzyka interwencji człowieka.

Scenariusz hierarchii urządzeń zagnieżdżonych z usługą IoT Edge jako bramą

Teraz dobrze znasz prostą interakcję usługi IoT Edge między usługą i usługą IoT Hub. Jednak usługa IoT Edge może również działać jako brama dla urządzeń podrzędnych lub innych urządzeń usługi IoT Edge. Te kanały komunikacyjne muszą być również szyfrowane i zaufane. Ze względu na dodatkową złożoność musimy rozszerzyć nasz przykładowy scenariusz, aby uwzględnić urządzenie podrzędne.

Dodamy zwykłe urządzenie IoT o nazwie TempSensor, które łączy się z nadrzędnym urządzeniem usługi IoT EdgeGateway, które łączy się z usługą IoT Hub ContosoIotHub. Podobnie jak wcześniej, wszystkie uwierzytelnianie odbywa się przy użyciu uwierzytelniania certyfikatu X.509. Nasz nowy scenariusz rodzi dwa nowe pytania: "Czy urządzenie TempSensor jest uzasadnione?" i "Czy tożsamość edgeGateway jest poprawna?". Scenariusz można zilustrować w następujący sposób:

Napiwek

TempSensor to urządzenie IoT w scenariuszu. Koncepcja certyfikatu jest taka sama, jeśli element TempSensor jest podrzędnym urządzeniem usługi IoT Edge nadrzędnym urządzeniem EdgeGateway.

Urządzenie weryfikuje tożsamość bramy

Jak narzędzie TempSensor sprawdza, czy komunikuje się z prawdziwą bramą EdgeGateway? Gdy element TempSensor chce komunikować się z usługą EdgeGateway, funkcja TempSensor wymaga elementu EdgeGateway, aby wyświetlić identyfikator. Identyfikator musi być wystawiony przez urząd, któremu ufa tempSensor .

Przepływ jest taki sam, jak w przypadku rozmowy usługi EdgeGateway z firmą ContosoIotHub. Protokoły TempSensor i EdgeGateway używają protokołu uzgadniania TLS, aby zweryfikować tożsamość urządzenia EdgeGateway . Istnieją dwa ważne szczegóły:

• Specyfika nazwy hosta: certyfikat przedstawiony przez usługę EdgeGateway musi być wystawiony na tę samą nazwę hosta (domenę lub adres IP), którego element TempSensor używa do nawiązywania połączenia z usługą EdgeGateway.
• Specyfika głównego urzędu certyfikacji z podpisem własnym: łańcuch certyfikatów przedstawiony przez usługę EdgeGateway prawdopodobnie nie znajduje się w domyślnym magazynie głównym zaufanego systemu operacyjnego.

Aby zrozumieć szczegóły, najpierw przeanalizujmy łańcuch certyfikatów przedstawiony przez usługę EdgeGateway.

Specyfika nazwy hosta

Nazwa pospolita certyfikatu CN = edgegateway.local znajduje się w górnej części łańcucha. edgegateway.local to nazwa pospolita certyfikatu serwera edgeHub. edgegateway.local jest również nazwą hosta EdgeGateway w sieci lokalnej (LAN lub VNet), w której są połączone protokoły TempSensor i EdgeGateway. Może to być prywatny adres IP, taki jak 192.168.1.23 lub w pełni kwalifikowana nazwa domeny (FQDN), taka jak diagram. Certyfikat serwera edgeHub jest generowany przy użyciu parametru nazwa hosta zdefiniowanego w pliku config.toml usługi IoT Edge. Nie należy mylić certyfikatu serwera edgeHub z certyfikatem urzędu certyfikacji edge. Aby uzyskać więcej informacji na temat zarządzania certyfikatem urzędu certyfikacji usługi Edge, zobacz Zarządzanie certyfikatami usługi IoT Edge.

Gdy element TempSensor łączy się z usługą EdgeGateway, funkcja TempSensor używa nazwy hosta edgegateway.local w celu nawiązania połączenia z usługą EdgeGateway. Element TempSensor sprawdza certyfikat przedstawiony przez usługę EdgeGateway i sprawdza, czy nazwa pospolita certyfikatu to edgegateway.local. Jeśli nazwa pospolita certyfikatu jest inna, narzędzie TempSensor odrzuca połączenie.

Uwaga

Dla uproszczenia w przykładzie przedstawiono nazwę pospolitą certyfikatu podmiotu (CN) jako właściwość, która jest weryfikowana. W praktyce, jeśli certyfikat ma alternatywną nazwę podmiotu (SAN), sieć SAN jest weryfikowana zamiast CN. Ogólnie rzecz biorąc, ponieważ sieć SAN może zawierać wiele wartości, ma zarówno główną domenę/nazwę hosta właściciela certyfikatu, jak i wszystkie domeny alternatywne.

Dlaczego edgeGateway musi być poinformowany o własnej nazwie hosta?

Usługa EdgeGateway nie ma niezawodnego sposobu, aby wiedzieć, jak inni klienci w sieci mogą się z nią łączyć. Na przykład w sieci prywatnej mogą istnieć serwery DHCP lub usługi mDNS, które wyświetlają wartość EdgeGateway jako 10.0.0.2 lub example-mdns-hostname.local. Jednak niektóre sieci mogą mieć serwery DNS mapowane edgegateway.local na adres 10.0.0.2IP usługi EdgeGateway.

Aby rozwiązać ten problem, usługa IoT Edge używa skonfigurowanej wartości nazwy hosta w programie config.toml i tworzy dla niego certyfikat serwera. Gdy żądanie przychodzi do modułu edgeHub , przedstawia certyfikat z właściwą nazwą pospolitą certyfikatu (CN).

Dlaczego usługa IoT Edge tworzy certyfikaty?

W tym przykładzie w łańcuchu certyfikatów występuje obciążenie ca edgegateway obciążenia iotedged. Jest to urząd certyfikacji, który istnieje na urządzeniu usługi IoT Edge znanym jako urząd certyfikacji usługi Edge (wcześniej znany jako urząd certyfikacji urządzenia w wersji 1.1). Podobnie jak główny urząd certyfikacji Baltimore CyberTrust w poprzednim przykładzie, urząd certyfikacji usługi Edge może wystawiać inne certyfikaty. Co najważniejsze, a także w tym przykładzie wystawia certyfikat serwera do modułu edgeHub . Może jednak również wystawiać certyfikaty innym modułom uruchomionym na urządzeniu usługi IoT Edge.

Ważne

Domyślnie bez konfiguracji urząd certyfikacji usługi Edge jest automatycznie generowany przez środowisko uruchomieniowe modułu usługi IoT Edge po uruchomieniu po raz pierwszy, znany jako urząd certyfikacji usługi Szybki start Edge, a następnie wystawia certyfikat do modułu edgeHub . Ten proces przyspiesza połączenie urządzenia podrzędnego, umożliwiając usłudze EdgeHub prezentowanie ważnego certyfikatu, który jest podpisany. Bez tej funkcji należy uzyskać urząd certyfikacji w celu wystawienia certyfikatu dla modułu edgeHub . Korzystanie z automatycznie wygenerowanego urzędu certyfikacji przeglądarki Microsoft Edge nie jest obsługiwane w środowisku produkcyjnym. Aby uzyskać więcej informacji na temat urzędu certyfikacji usługi Edge szybkiego startu, zobacz Szybki start Edge URZĘDU certyfikacji.

Czy nie jest niebezpieczne posiadanie certyfikatu wystawcy na urządzeniu?

Urząd certyfikacji edge został zaprojektowany w celu umożliwienia rozwiązań z ograniczoną, zawodną, kosztowną lub nieobecną łącznością, ale jednocześnie mają ścisłe przepisy lub zasady dotyczące odnawiania certyfikatów. Bez urzędu certyfikacji usługi Edge usługa IoT Edge — a w szczególności edgeHub — nie może działać.

Aby zabezpieczyć urząd certyfikacji usługi Edge w środowisku produkcyjnym:

• Umieść klucz prywatny EdgeCA w module zaufanej platformy (TPM), najlepiej w sposób, w którym klucz prywatny jest generowany efemerycznie i nigdy nie opuszcza modułu TPM.
• Użyj infrastruktury kluczy publicznych (PKI), do której jest rzutowy urząd certyfikacji usługi Edge. Dzięki temu można wyłączyć lub odrzucić odnawianie naruszonych certyfikatów. Infrastruktura kluczy publicznych może być zarządzana przez dział IT klienta, jeśli ma wiedzę na temat tego, jak (niższy koszt) lub za pośrednictwem komercyjnego dostawcy infrastruktury kluczy publicznych.

Specyfika głównego urzędu certyfikacji z podpisem własnym

Moduł edgeHub jest ważnym składnikiem tworzącym usługę IoT Edge przez obsługę całego ruchu przychodzącego. W tym przykładzie używa certyfikatu wystawionego przez urząd certyfikacji usługi Edge, który z kolei jest wystawiany przez główny urząd certyfikacji z podpisem własnym. Ponieważ główny urząd certyfikacji nie jest zaufany przez system operacyjny, jedynym sposobem, w jaki tempSensor ufa, jest zainstalowanie certyfikatu urzędu certyfikacji na urządzeniu. Jest to również znany jako scenariusz pakietu zaufania, w którym należy dystrybuować katalog główny do klientów, którzy muszą ufać łańcuchowi. Scenariusz pakietu zaufania może być kłopotliwy, ponieważ potrzebujesz dostępu do urządzenia i zainstalowania certyfikatu. Zainstalowanie certyfikatu wymaga planowania. Można to zrobić za pomocą skryptów, dodanych podczas produkcji lub wstępnie zainstalowanych na obrazie systemu operacyjnego.

Uwaga

Niektórzy klienci i zestawy SDK nie używają zaufanego magazynu głównego systemu operacyjnego i należy przekazać plik głównego urzędu certyfikacji bezpośrednio.

Stosując wszystkie te koncepcje, TempSensor może sprawdzić, czy komunikuje się z prawdziwym elementem EdgeGateway, ponieważ przedstawił certyfikat pasujący do adresu, a certyfikat jest podpisany przez zaufany katalog główny.

Aby sprawdzić łańcuch certyfikatów, możesz użyć openssl go na urządzeniu TempSensor . W tym przykładzie zwróć uwagę, że nazwa hosta dla połączenia jest zgodna z nazwą CN certyfikatu głębokości 0 i że główny urząd certyfikacji jest zgodny.

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

Aby dowiedzieć się więcej o openssl poleceniu, zobacz dokumentację protokołu OpenSSL.

Możesz również sprawdzić certyfikaty, w których są one przechowywane domyślnie w programie /var/lib/aziot/certd/certs. Certyfikaty urzędu certyfikacji usługi Edge, certyfikaty tożsamości urządzeń i certyfikaty modułów można znaleźć w katalogu. Za pomocą openssl x509 poleceń można sprawdzić certyfikaty. Na przykład:

sudo ls -l /var/lib/aziot/certd/certs

total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

Podsumowując, element TempSensor może ufać usłudze EdgeGateway, ponieważ:

• Moduł edgeHub pokazał prawidłowy certyfikat serwera modułu usługi IoT Edge dla edgegateway.local
• Certyfikat jest wystawiany przez urząd certyfikacji usługi Edge wystawiony przez my_private_root_CA
• Ten prywatny główny urząd certyfikacji jest również przechowywany w narzędziu TempSensor jako zaufany główny urząd certyfikacji wcześniej
• Algorytmy kryptograficzne sprawdzają, czy łańcuch własności i wystawiania może być zaufany

Certyfikaty dla innych modułów

Inne moduły mogą pobierać certyfikaty serwera wystawione przez urząd certyfikacji usługi Edge. Na przykład moduł Grafana z interfejsem internetowym. Może również pobrać certyfikat z urzędu certyfikacji usługi Edge. Moduły są traktowane jako urządzenia podrzędne hostowane w kontenerze. Jednak uzyskanie certyfikatu ze środowiska uruchomieniowego modułu usługi IoT Edge jest specjalnymi uprawnieniami. Moduły wywołają interfejs API obciążenia, aby otrzymać certyfikat serwera w łańcuchu do skonfigurowanego urzędu certyfikacji usługi Edge.

Brama weryfikuje tożsamość urządzenia

Jak usługa EdgeGateway sprawdza, czy komunikuje się z aplikacją TempSensor? EdgeGateway używa uwierzytelniania klienta TLS do uwierzytelniania tempSensor.

Sekwencja jest podobna do firmy ContosoIotHub weryfikując urządzenie. Jednak w scenariuszu bramy edgeGateway opiera się na ContosoIotHub jako źródle prawdy dla rekordu certyfikatów. Usługa EdgeGateway przechowuje również kopię w trybie offline lub pamięć podręczną, jeśli nie ma połączenia z chmurą.

Napiwek

W przeciwieństwie do urządzeń usługi IoT Edge urządzenia podrzędne IoT nie są ograniczone do uwierzytelniania X.509 odcisku palca. Uwierzytelnianie urzędu certyfikacji X.509 jest również opcją. Zamiast wyszukiwać dopasowanie na odcisku palca, edgeGateway może również sprawdzić, czy certyfikat TempSensor jest zakorzeniony w urzędzie certyfikacji, który został przekazany do contosoIotHub.

Podsumowując, funkcja EdgeGateway może ufać funkcji TempSensor, ponieważ:

• Element TempSensor przedstawił prawidłowy certyfikat tożsamości urządzenia IoT dla swojej nazwy
• Odcisk palca certyfikatu tożsamości jest zgodny z odciskiem palca przekazanym do usługi ContosoIotHub
• Algorytmy kryptograficzne sprawdzają, czy łańcuch własności i wystawiania może być zaufany

Gdzie uzyskać certyfikaty i zarządzanie

W większości przypadków można podać własne certyfikaty lub użyć ich w przypadku certyfikatów generowanych automatycznie. Na przykład urząd certyfikacji edge i certyfikat edgeHub są generowane automatycznie.

Najlepszym rozwiązaniem jest jednak skonfigurowanie urządzeń do używania serwera rejestracji za pośrednictwem serwera Secure Transport (EST) do zarządzania certyfikatami x509. Za pomocą serwera EST można ręcznie obsługiwać certyfikaty i instalować je na urządzeniach. Aby uzyskać więcej informacji na temat korzystania z serwera EST, zobacz Configure Enrollment over Secure Transport Server for Azure IoT Edge (Konfigurowanie rejestracji za pośrednictwem bezpiecznego serwera transportu dla usługi Azure IoT Edge).

Certyfikaty można również użyć do uwierzytelniania na serwerze EST. Te certyfikaty są używane do uwierzytelniania za pomocą serwerów EST w celu wystawiania innych certyfikatów. Usługa certyfikatów używa certyfikatu bootstrap do uwierzytelniania za pomocą serwera EST. Certyfikat bootstrap jest długotrwały. Po początkowym uwierzytelnieniu usługa certyfikatu wysyła żądanie do serwera EST w celu wystawienia certyfikatu tożsamości. Ten certyfikat tożsamości jest używany w przyszłych żądaniach EST do tego samego serwera.

Jeśli nie możesz użyć serwera EST, należy zażądać certyfikatów od dostawcy infrastruktury kluczy publicznych. Pliki certyfikatów można zarządzać ręcznie w usłudze IoT Hub i urządzeniach usługi IoT Edge. Aby uzyskać więcej informacji, zarządzanie certyfikatami na urządzeniu usługi IoT Edge.

W celu weryfikacji koncepcji można utworzyć certyfikaty testowe. Aby uzyskać więcej informacji, zobacz Tworzenie certyfikatów demonstracyjnych w celu testowania funkcji urządzeń usługi IoT Edge.

Certyfikaty w usłudze IoT

Urząd certyfikacji

Urząd certyfikacji to jednostka, która wystawia certyfikaty cyfrowe. Urząd certyfikacji działa jako zaufana strona trzecia między właścicielem a odbiorcą certyfikatu. Certyfikat cyfrowy potwierdza własność klucza publicznego przez odbiorcę certyfikatu. Łańcuch zaufania certyfikatów działa przez początkowo wystawianie certyfikatu głównego, który jest podstawą zaufania do wszystkich certyfikatów wystawionych przez urząd. Właściciel certyfikatu głównego może następnie wystawiać dodatkowe certyfikaty pośrednie (certyfikaty urządzeń podrzędnych).

Certyfikat głównego urzędu certyfikacji

Certyfikat głównego urzędu certyfikacji jest katalogiem głównym zaufania całego procesu. W scenariuszach produkcyjnych ten certyfikat urzędu certyfikacji jest kupowany z zaufanego komercyjnego urzędu certyfikacji, takiego jak Baltimore, Verisign lub DigiCert. Jeśli masz pełną kontrolę nad urządzeniami łączącymi się z urządzeniami usługi IoT Edge, można użyć urzędu certyfikacji na poziomie firmy. W obu zdarzeniach cały łańcuch certyfikatów z usługi IoT Edge do usługi IoT Hub używa go. Urządzenia podrzędne IoT muszą ufać certyfikatowi głównemu. Certyfikat głównego urzędu certyfikacji można przechowywać w magazynie zaufanych głównych urzędów certyfikacji lub podać szczegóły certyfikatu w kodzie aplikacji.

Certyfikaty pośrednie

W typowym procesie produkcyjnym do tworzenia bezpiecznych urządzeń certyfikaty głównego urzędu certyfikacji są rzadko używane bezpośrednio, głównie ze względu na ryzyko wycieku lub narażenia. Certyfikat głównego urzędu certyfikacji tworzy i podpisuje cyfrowo co najmniej jeden certyfikat pośredniego urzędu certyfikacji. Może istnieć tylko jeden lub istnieje łańcuch tych certyfikatów pośrednich. Scenariusze wymagające łańcucha certyfikatów pośrednich obejmują:

• Hierarchia działów w obrębie producenta
• Wiele firm zaangażowanych szeregowo w produkcję urządzenia
• Klient kupując główny urząd certyfikacji i wyprowadzając certyfikat podpisywania dla producenta w celu podpisania urządzeń, które tworzą w imieniu tego klienta

W każdym razie producent używa pośredniego certyfikatu urzędu certyfikacji na końcu tego łańcucha do podpisania certyfikatu urzędu certyfikacji edge umieszczonego na urządzeniu końcowym. Te certyfikaty pośrednie są ściśle chronione w zakładzie produkcyjnym. Są one poddawane ścisłym procesom, zarówno fizycznym, jak i elektronicznym na potrzeby ich użytkowania.

Następne kroki

• Aby uzyskać więcej informacji na temat sposobu instalowania certyfikatów na urządzeniu usługi IoT Edge i odwoływanie się do nich z pliku konfiguracji, zobacz Zarządzanie certyfikatem na urządzeniu usługi IoT Edge.
• Omówienie modułów usługi Azure IoT Edge
• Konfigurowanie urządzenia usługi IoT Edge, aby działało jako przezroczysta brama
• W tym artykule omówiono certyfikaty używane do zabezpieczania połączeń między różnymi składnikami na urządzeniu usługi IoT Edge lub między urządzeniem usługi IoT Edge i dowolnymi urządzeniami podrzędnymi. Certyfikaty mogą być również używane do uwierzytelniania urządzenia usługi IoT Edge w usłudze IoT Hub. Te certyfikaty uwierzytelniania są różne i nie zostały omówione w tym artykule. Aby uzyskać więcej informacji na temat uwierzytelniania urządzenia przy użyciu certyfikatów, zobacz Tworzenie i aprowizowanie urządzenia usługi IoT Edge przy użyciu certyfikatów X.509.