Udostępnij za pośrednictwem

Samouczek: tworzenie i przekazywanie certyfikatów na potrzeby testowania

  • Artykuł

Certyfikaty X.509 umożliwiają uwierzytelnianie urządzeń w centrum IoT. W środowiskach produkcyjnych zalecamy zakup certyfikatu X.509 urzędu certyfikacji od dostawcy profesjonalnych usług certyfikatów. Następnie można wystawiać certyfikaty w organizacji z wewnętrznego, samoobsługowego urzędu certyfikacji powiązanego z zakupionym certyfikatem urzędu certyfikacji w ramach kompleksowej strategii infrastruktury kluczy publicznych (PKI). Aby uzyskać więcej informacji na temat uzyskiwania certyfikatu X.509 urzędu certyfikacji od dostawcy profesjonalnych usług certyfikatów, zobacz sekcję Pobieranie certyfikatu X.509 urzędu certyfikacji w temacie Uwierzytelnianie urządzeń przy użyciu certyfikatów X.509 urzędu certyfikacji.

Jednak utworzenie własnego, prywatnego urzędu certyfikacji, który używa wewnętrznego głównego urzędu certyfikacji, ponieważ kotwica zaufania jest odpowiedni dla środowisk testowych. Zarządzany przez siebie prywatny urząd certyfikacji z co najmniej jednym podrzędnym urzędem certyfikacji w łańcuchu do wewnętrznego głównego urzędu certyfikacji z certyfikatami klienta dla urządzeń podpisanych przez podrzędne urzędy certyfikacji umożliwia symulowanie zalecanego środowiska produkcyjnego.

Ważne

Nie zalecamy używania certyfikatów z podpisem własnym dla środowisk produkcyjnych. Ten samouczek jest przedstawiany tylko w celach demonstracyjnych.

W poniższym samouczku użyto biblioteki OpenSSL i podręcznika openSSL do opisania sposobu wykonywania następujących zadań:

  • Tworzenie wewnętrznego głównego urzędu certyfikacji i certyfikatu głównego urzędu certyfikacji
  • Tworzenie wewnętrznego podrzędnego urzędu certyfikacji i certyfikatu podrzędnego urzędu certyfikacji podpisanego przez wewnętrzny certyfikat głównego urzędu certyfikacji
  • Przekazywanie podrzędnego certyfikatu urzędu certyfikacji do centrum IoT na potrzeby testowania
  • Użyj podrzędnego urzędu certyfikacji, aby utworzyć certyfikaty klienta dla urządzeń IoT, które chcesz przetestować za pomocą centrum IoT

Uwaga

Firma Microsoft udostępnia skrypty programu PowerShell i powłoki Bash, aby ułatwić zrozumienie sposobu tworzenia własnych certyfikatów X.509 i uwierzytelniania ich w centrum IoT. Skrypty są dołączone do zestawu SDK urządzeń usługi Azure IoT Hub dla języka C. Skrypty są udostępniane tylko do celów demonstracyjnych. Certyfikaty utworzone przez nie mogą być używane w środowisku produkcyjnym. Certyfikaty zawierają zakodowane na twardo hasła ("1234") i wygasają po upływie 30 dni. Musisz użyć własnych najlepszych rozwiązań dotyczących tworzenia certyfikatów i zarządzania okresem istnienia w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Zarządzanie certyfikatami testowego urzędu certyfikacji dla przykładów i samouczków w repozytorium GitHub dla zestawu SDK urządzenia usługi Azure IoT Hub dla języka C.

Wymagania wstępne

  • Subskrypcja platformy Azure. Jeśli nie masz subskrypcji platformy Azure, przed rozpoczęciem utwórz bezpłatne konto.

  • Centrum IoT w ramach subskrypcji platformy Azure. Jeśli nie masz jeszcze centrum, możesz wykonać kroki opisane w temacie Tworzenie centrum IoT Hub.

  • Najnowsza wersja usługi Git. Upewnij się, że usługa Git jest dodawana do zmiennych środowiskowych dostępnych w oknie polecenia. Zobacz Narzędzia klienckie Git firmy Software Freedom Conservancy, aby zapoznać się z najnowszą wersją git narzędzi do zainstalowania, która obejmuje powłokę Git Bash, aplikację wiersza polecenia, której można użyć do interakcji z lokalnym repozytorium Git.

  • Instalacja protokołu OpenSSL. W systemie Windows instalacja narzędzia Git obejmuje instalację programu OpenSSL. Dostęp do protokołu OpenSSL można uzyskać z poziomu wiersza polecenia powłoki Git Bash. Aby sprawdzić, czy program OpenSSL jest zainstalowany, otwórz wiersz polecenia powłoki Git Bash i wprowadź polecenie openssl version.

    Uwaga

    Jeśli nie znasz programu OpenSSL i nie masz go już zainstalowanego na maszynie z systemem Windows, zalecamy używanie biblioteki OpenSSL z poziomu wiersza polecenia powłoki Git Bash. Alternatywnie możesz pobrać kod źródłowy i skompilować bibliotekę OpenSSL. Aby dowiedzieć się więcej, zobacz stronę Pliki do pobrania openSSL. Możesz też pobrać wstępnie skompilowany program OpenSSL z poziomu innej firmy. Aby dowiedzieć się więcej, zobacz witrynę typu wiki openSSL. Firma Microsoft nie gwarantuje ważności pakietów pobranych od innych firm. Jeśli zdecydujesz się skompilować lub pobrać plik OpenSSL, upewnij się, że plik binarny OpenSSL jest dostępny w ścieżce i że OPENSSL_CNF zmienna środowiskowa jest ustawiona na ścieżkę pliku openssl.cnf .

Tworzenie głównego urzędu certyfikacji

Najpierw należy utworzyć wewnętrzny główny urząd certyfikacji i certyfikat głównego urzędu certyfikacji z podpisem własnym, aby służyć jako kotwica zaufania, z której można utworzyć inne certyfikaty do testowania. Pliki używane do tworzenia i obsługi wewnętrznego głównego urzędu certyfikacji są przechowywane w strukturze folderów i inicjowane w ramach tego procesu. Wykonaj następujące kroki:

  • Tworzenie i inicjowanie folderów i plików używanych przez główny urząd certyfikacji
  • Tworzenie pliku konfiguracji używanego przez program OpenSSL do konfigurowania głównego urzędu certyfikacji i certyfikatów utworzonych przy użyciu głównego urzędu certyfikacji
  • Żądanie i utworzenie certyfikatu urzędu certyfikacji z podpisem własnym, który służy jako certyfikat głównego urzędu certyfikacji

  1. Uruchom okno powłoki Git Bash i uruchom następujące polecenie, zastępując {base_dir} element żądanym katalogiem, w którym chcesz utworzyć certyfikaty w tym samouczku.

    cd {base_dir}

  2. W oknie powłoki Git Bash uruchom następujące polecenia pojedynczo. Ten krok tworzy następującą strukturę katalogu i pliki obsługi głównego urzędu certyfikacji.

    Katalog lub plik opis
    rootca Katalog główny głównego urzędu certyfikacji.
    rootca/certyfikaty Katalog, w którym są tworzone i przechowywane certyfikaty urzędu certyfikacji głównego.
    rootca/db Katalog, w którym jest przechowywana baza danych certyfikatów i pliki obsługi głównego urzędu certyfikacji.
    rootca/db/index Baza danych certyfikatów dla głównego urzędu certyfikacji. Polecenie touch tworzy plik bez zawartości do późniejszego użycia. Baza danych certyfikatów to plik w postaci zwykłego tekstu zarządzany przez program OpenSSL zawierający informacje o wystawionych certyfikatach. Aby uzyskać więcej informacji na temat bazy danych certyfikatów, zobacz stronę ręczną openssl-ca .
    rootca/db/serial Plik używany do przechowywania numeru seryjnego następnego certyfikatu, który ma zostać utworzony dla głównego urzędu certyfikacji. Polecenie openssl tworzy 16-bajtową liczbę losową w formacie szesnastkowym, a następnie zapisuje go w tym pliku w celu zainicjowania pliku do utworzenia certyfikatu głównego urzędu certyfikacji.
    rootca/db/crlnumber Plik używany do przechowywania numerów seryjnych dla odwołanych certyfikatów wystawionych przez główny urząd certyfikacji. Polecenie echo potokuje do pliku przykładowy numer seryjny 1001.
    rootca/private Katalog, w którym są przechowywane pliki prywatne głównego urzędu certyfikacji, w tym klucz prywatny.
    Pliki w tym katalogu muszą być zabezpieczone i chronione.    		 
    mkdir rootca
cd rootca
mkdir certs db private
chmod 700 private
touch db/index
openssl rand -hex 16 > db/serial
echo 1001 > db/crlnumber

  3. Utwórz plik tekstowy o nazwie rootca.conf w rootca katalogu utworzonym w poprzednim kroku. Otwórz ten plik w edytorze tekstów, a następnie skopiuj i zapisz następujące ustawienia konfiguracji protokołu OpenSSL w tym pliku.

    Plik zawiera bibliotekę OpenSSL z wartościami wymaganymi do skonfigurowania testowego głównego urzędu certyfikacji. W tym przykładzie plik konfiguruje główny urząd certyfikacji o nazwie rootca przy użyciu katalogów i plików utworzonych w poprzednich krokach. Plik zawiera również ustawienia konfiguracji dla:

    • Zasady urzędu certyfikacji używane przez główny urząd certyfikacji dla pól nazwa wyróżniająca certyfikatu (DN)
    • Żądania certyfikatów utworzone przez główny urząd certyfikacji
    • Rozszerzenia X.509 stosowane do certyfikatów głównego urzędu certyfikacji, podrzędnych certyfikatów urzędu certyfikacji i certyfikatów klienta wystawionych przez główny urząd certyfikacji

    Uwaga

    Atrybut home w ca_default sekcji jest ustawiony na ../rootca , ponieważ ten plik konfiguracji jest również używany podczas tworzenia certyfikatu dla podrzędnego urzędu certyfikacji. Określona ścieżka względna umożliwia programowi OpenSSL przechodzenie z folderu podrzędnego urzędu certyfikacji do głównego folderu urzędu certyfikacji podczas tego procesu.

    Aby uzyskać więcej informacji na temat składni plików konfiguracji openSSL, zobacz stronę ręczną konfiguracji w dokumentacji protokołu OpenSSL.

    [default]
name                     = rootca
domain_suffix            = exampledomain.com
aia_url                  = http://$name.$domain_suffix/$name.crt
crl_url                  = http://$name.$domain_suffix/$name.crl
default_ca               = ca_default
name_opt                 = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
commonName               = "rootca_common_name"

[ca_default]
home                     = ../rootca
database                 = $home/db/index
serial                   = $home/db/serial
crlnumber                = $home/db/crlnumber
certificate              = $home/$name.crt
private_key              = $home/private/$name.key
RANDFILE                 = $home/private/random
new_certs_dir            = $home/certs
unique_subject           = no
copy_extensions          = none
default_days             = 3650
default_crl_days         = 365
default_md               = sha256
policy                   = policy_c_o_match

[policy_c_o_match]
countryName              = optional
stateOrProvinceName      = optional
organizationName         = optional
organizationalUnitName   = optional
commonName               = supplied
emailAddress             = optional

[req]
default_bits             = 2048
encrypt_key              = yes
default_md               = sha256
utf8                     = yes
string_mask              = utf8only
prompt                   = no
distinguished_name       = ca_dn
req_extensions           = ca_ext

[ca_ext]
basicConstraints         = critical,CA:true
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[sub_ca_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:true,pathlen:0
extendedKeyUsage         = clientAuth,serverAuth
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[client_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:false
extendedKeyUsage         = clientAuth
keyUsage                 = critical,digitalSignature
subjectKeyIdentifier     = hash

  4. W oknie powłoki Git Bash uruchom następujące polecenie, aby wygenerować żądanie podpisania certyfikatu (CSR) w rootca katalogu i klucz prywatny w rootca/private katalogu. Aby uzyskać więcej informacji na temat polecenia OpenSSL req , zobacz stronę ręczną opensl-req w dokumentacji protokołu OpenSSL.

    Uwaga

    Mimo że ten główny urząd certyfikacji jest przeznaczony do celów testowych i nie zostanie uwidoczniony w ramach infrastruktury kluczy publicznych (PKI), zalecamy, aby nie kopiować ani udostępniać klucza prywatnego.

    winpty openssl req -new -config rootca.conf -out rootca.csr -keyout private/rootca.key

    Zostanie wyświetlony monit o wprowadzenie frazy przekazywania PEM, jak pokazano w poniższym przykładzie dla pliku klucza prywatnego. Wprowadź i potwierdź frazę dostępu, aby wygenerować klucz prywatny i csr.

    Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

    Upewnij się, rootca.csrże plik CSR, , znajduje się w rootca katalogu i pliku klucza prywatnego, rootca.key, znajduje się w podkatalogu private przed kontynuowaniem.

  5. W oknie Git Bash uruchom następujące polecenie, aby utworzyć certyfikat głównego urzędu certyfikacji z podpisem własnym. Polecenie stosuje ca_ext rozszerzenia plików konfiguracji do certyfikatu. Te rozszerzenia wskazują, że certyfikat jest przeznaczony dla głównego urzędu certyfikacji i może służyć do podpisywania certyfikatów i list odwołania certyfikatów (CRL). Aby uzyskać więcej informacji na temat polecenia OpenSSL ca , zobacz stronę ręczną opensl-ca w dokumentacji protokołu OpenSSL.

    winpty openssl ca -selfsign -config rootca.conf -in rootca.csr -out rootca.crt -extensions ca_ext

    Zostanie wyświetlony monit o podanie frazy przekazywania PEM, jak pokazano w poniższym przykładzie dla pliku klucza prywatnego. Po podaniu frazy pass program OpenSSL generuje certyfikat, a następnie monituje o podpisanie i zatwierdzenie certyfikatu dla głównego urzędu certyfikacji. Określ wartość y dla obu monitów o wygenerowanie certyfikatu z podpisem własnym dla głównego urzędu certyfikacji.

    Using configuration from rootca.conf
Enter pass phrase for ../rootca/private/rootca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
    {Details omitted from output for clarity}
Certificate is to be certified until Mar 24 18:51:41 2033 GMT (3650 days)
Sign the certificate? [y/n]:


1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated

    Gdy program OpenSSL zaktualizuje bazę danych certyfikatów, upewnij się, rootca.crtże zarówno plik certyfikatu , znajduje się w rootca katalogu, jak i plik certyfikatu PEM (pem) dla certyfikatu znajduje się w rootca/certs katalogu. Nazwa pliku pem jest zgodna z numerem seryjnym certyfikatu głównego urzędu certyfikacji.

Tworzenie podrzędnego urzędu certyfikacji

Po utworzeniu wewnętrznego głównego urzędu certyfikacji należy utworzyć podrzędny urząd certyfikacji do użycia jako pośredni urząd certyfikacji , z którym należy podpisać certyfikaty klienta dla urządzeń. Teoretycznie nie trzeba tworzyć podrzędnego urzędu certyfikacji; Certyfikat głównego urzędu certyfikacji można przekazać do centrum IoT i podpisać certyfikaty klienta bezpośrednio z głównego urzędu certyfikacji. Jednak używanie podrzędnego urzędu certyfikacji jako pośredniego urzędu certyfikacji do podpisywania certyfikatów klienta ściślej symuluje zalecane środowisko produkcyjne, w którym główny urząd certyfikacji jest przechowywany w trybie offline. Możesz również użyć podrzędnego urzędu certyfikacji do podpisania innego podrzędnego urzędu certyfikacji, który z kolei może podpisać inny podrzędny urząd certyfikacji itd. Używanie podrzędnych urzędów certyfikacji do podpisywania innych podrzędnych urzędów certyfikacji tworzy hierarchię pośrednich urzędów certyfikacji w ramach łańcucha zaufania certyfikatów. W środowisku produkcyjnym łańcuch zaufania certyfikatów umożliwia delegowanie zaufania do urządzeń podpisywania. Aby uzyskać więcej informacji na temat logowania urządzeń do łańcucha zaufania certyfikatów, zobacz Uwierzytelnianie urządzeń przy użyciu certyfikatów X.509 urzędu certyfikacji.

Podobnie jak w przypadku głównego urzędu certyfikacji pliki używane do tworzenia i obsługi podrzędnego urzędu certyfikacji są przechowywane w strukturze folderów i inicjowane w ramach tego procesu. Wykonaj następujące kroki:

  • Tworzenie i inicjowanie folderów i plików używanych przez podrzędny urząd certyfikacji
  • Tworzenie pliku konfiguracji używanego przez program OpenSSL do konfigurowania podrzędnego urzędu certyfikacji i certyfikatów utworzonych przy użyciu podrzędnego urzędu certyfikacji
  • Żądanie i utworzenie certyfikatu urzędu certyfikacji podpisanego przez główny urząd certyfikacji, który służy jako certyfikat podrzędnego urzędu certyfikacji

  1. Wróć do katalogu podstawowego zawierającego rootca katalog. W tym przykładzie zarówno główny urząd certyfikacji, jak i podrzędny urząd certyfikacji znajdują się w tym samym katalogu podstawowym.

    cd ..

  2. W oknie powłoki Git Bash uruchom następujące polecenia pojedynczo.

    Ten krok tworzy strukturę katalogów i pliki obsługi podrzędnego urzędu certyfikacji podobne do struktury folderów i plików utworzonych dla głównego urzędu certyfikacji w poprzedniej sekcji.

    mkdir subca
cd subca
mkdir certs db private
chmod 700 private
touch db/index
openssl rand -hex 16 > db/serial
echo 1001 > db/crlnumber

  3. Utwórz plik tekstowy o nazwie subca.conf w subca katalogu utworzonym w poprzednim kroku. Otwórz ten plik w edytorze tekstów, a następnie skopiuj i zapisz następujące ustawienia konfiguracji protokołu OpenSSL w tym pliku.

    Podobnie jak w przypadku pliku konfiguracji dla testowego głównego urzędu certyfikacji, ten plik udostępnia plik OpenSSL z wartościami wymaganymi do skonfigurowania podrzędnego urzędu certyfikacji testowego. Można utworzyć wiele podrzędnych urzędów certyfikacji na potrzeby zarządzania scenariuszami testowania lub środowiskami.

    Aby uzyskać więcej informacji na temat składni plików konfiguracji OpenSSL, zobacz stronę podręcznika konfiguracji w dokumentacji protokołu OpenSSL.

    [default]
name                     = subca
domain_suffix            = exampledomain.com
aia_url                  = http://$name.$domain_suffix/$name.crt
crl_url                  = http://$name.$domain_suffix/$name.crl
default_ca               = ca_default
name_opt                 = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
commonName               = "subca_common_name"

[ca_default]
home                     = ../subca
database                 = $home/db/index
serial                   = $home/db/serial
crlnumber                = $home/db/crlnumber
certificate              = $home/$name.crt
private_key              = $home/private/$name.key
RANDFILE                 = $home/private/random
new_certs_dir            = $home/certs
unique_subject           = no
copy_extensions          = copy
default_days             = 365
default_crl_days         = 90
default_md               = sha256
policy                   = policy_c_o_match

[policy_c_o_match]
countryName              = optional
stateOrProvinceName      = optional
organizationName         = optional
organizationalUnitName   = optional
commonName               = supplied
emailAddress             = optional

[req]
default_bits             = 2048
encrypt_key              = yes
default_md               = sha256
utf8                     = yes
string_mask              = utf8only
prompt                   = no
distinguished_name       = ca_dn
req_extensions           = ca_ext

[ca_ext]
basicConstraints         = critical,CA:true
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[sub_ca_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:true,pathlen:0
extendedKeyUsage         = clientAuth,serverAuth
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[client_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:false
extendedKeyUsage         = clientAuth
keyUsage                 = critical,digitalSignature
subjectKeyIdentifier     = hash

  4. W oknie powłoki Git Bash uruchom następujące polecenia, aby wygenerować klucz prywatny i żądanie podpisania certyfikatu (CSR) w katalogu podrzędnego urzędu certyfikacji.

    winpty openssl req -new -config subca.conf -out subca.csr -keyout private/subca.key

    Zostanie wyświetlony monit o wprowadzenie frazy przekazywania PEM, jak pokazano w poniższym przykładzie dla pliku klucza prywatnego. Wprowadź i zweryfikuj frazę z przekazywaniem, aby wygenerować klucz prywatny i csr.

    Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

    Przed kontynuowaniem upewnij się, że plik subca.csr CSR znajduje się w katalogu podrzędnego urzędu certyfikacji, a plik subca.key klucza prywatnego znajduje się w podkatalogu private .

  5. W oknie Git Bash uruchom następujące polecenie, aby utworzyć podrzędny certyfikat urzędu certyfikacji w katalogu podrzędnego urzędu certyfikacji. Polecenie stosuje sub_ca_ext rozszerzenia plików konfiguracji do certyfikatu. Te rozszerzenia wskazują, że certyfikat jest przeznaczony dla podrzędnego urzędu certyfikacji, a także może służyć do podpisywania certyfikatów i list odwołania certyfikatów (CRL). W przeciwieństwie do certyfikatu głównego urzędu certyfikacji ten certyfikat nie jest podpisany samodzielnie. Zamiast tego certyfikat podrzędnego urzędu certyfikacji jest podpisany przy użyciu certyfikatu głównego urzędu certyfikacji, ustanawiając łańcuch certyfikatów podobny do tego, co można użyć do infrastruktury kluczy publicznych (PKI). Certyfikat podrzędnego urzędu certyfikacji jest następnie używany do podpisywania certyfikatów klienta na potrzeby testowania urządzeń.

    winpty openssl ca -config ../rootca/rootca.conf -in subca.csr -out subca.crt -extensions sub_ca_ext

    Zostanie wyświetlony monit o wprowadzenie frazy dostępu, jak pokazano w poniższym przykładzie dla pliku klucza prywatnego głównego urzędu certyfikacji. Po wprowadzeniu frazy pass program OpenSSL generuje i wyświetla szczegóły certyfikatu, a następnie monituje o podpisanie i zatwierdzenie certyfikatu dla podrzędnego urzędu certyfikacji. Określ y dla obu monitów o wygenerowanie certyfikatu dla podrzędnego urzędu certyfikacji.

    Using configuration from rootca.conf
Enter pass phrase for ../rootca/private/rootca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
    {Details omitted from output for clarity}
Certificate is to be certified until Mar 24 18:55:00 2024 GMT (365 days)
Sign the certificate? [y/n]:


1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated

    Po zaktualizowaniu bazy danych certyfikatów openSSL upewnij się, że plik subca.crt certyfikatu znajduje się w katalogu podrzędnego urzędu certyfikacji i że plik certyfikatu PEM (pem) dla certyfikatu znajduje się w rootca/certs katalogu. Nazwa pliku pem jest zgodna z numerem seryjnym podrzędnego certyfikatu urzędu certyfikacji.

Rejestrowanie podrzędnego certyfikatu urzędu certyfikacji w centrum IoT

Zarejestruj podrzędny certyfikat urzędu certyfikacji w centrum IoT, który używa go do uwierzytelniania urządzeń podczas rejestracji i połączenia. W poniższych krokach opisano sposób przekazywania i automatycznego weryfikowania certyfikatu podrzędnego urzędu certyfikacji do centrum IoT.

  1. W witrynie Azure Portal przejdź do centrum IoT Hub i wybierz pozycję Certyfikaty z menu zasobów w obszarze Ustawienia zabezpieczeń.

  2. Wybierz pozycję Dodaj na pasku poleceń, aby dodać nowy certyfikat urzędu certyfikacji.

  3. Wprowadź nazwę wyświetlaną certyfikatu podrzędnego urzędu certyfikacji w polu Nazwa certyfikatu.

  4. Wybierz plik certyfikatu PEM (pem) podrzędnego certyfikatu urzędu certyfikacji z rootca/certs katalogu, aby dodać do pola Plik pem certyfikatu lub .cer.

  5. Zaznacz pole wyboru obok pozycji Ustaw stan certyfikatu na zweryfikowane podczas przekazywania.

    Zrzut ekranu przedstawiający sposób automatycznego weryfikowania stanu certyfikatu podczas przekazywania.

  6. Wybierz pozycję Zapisz.

Przekazany podrzędny certyfikat urzędu certyfikacji jest wyświetlany ze stanem ustawionym na zweryfikowane na karcie Certyfikaty w okienku roboczym.

Tworzenie certyfikatu klienta dla urządzenia

Po utworzeniu podrzędnego urzędu certyfikacji można utworzyć certyfikaty klienta dla urządzeń. Pliki i foldery utworzone dla podrzędnego urzędu certyfikacji są używane do przechowywania plików CSR, klucza prywatnego i certyfikatu dla certyfikatów klienta.

Certyfikat klienta musi mieć wartość pola Nazwa pospolita podmiotu (CN) ustawioną na wartość identyfikatora urządzenia używanego podczas rejestrowania odpowiedniego urządzenia w usłudze Azure IoT Hub.

Wykonaj następujące kroki:

  • Tworzenie klucza prywatnego i żądania podpisania certyfikatu (CSR) dla certyfikatu klienta
  • Tworzenie certyfikatu klienta podpisanego przez podrzędny certyfikat urzędu certyfikacji

  1. W oknie powłoki Git Bash upewnij się, że nadal jesteś w subca katalogu.

  2. W oknie powłoki Git Bash uruchom następujące polecenia pojedynczo. Zastąp symbol zastępczy nazwą urządzenia IoT, na przykład testdevice. Ten krok tworzy klucz prywatny i csr dla certyfikatu klienta.

    Ten krok tworzy 2048-bitowy klucz prywatny RSA dla certyfikatu klienta, a następnie generuje żądanie podpisania certyfikatu (CSR) przy użyciu tego klucza prywatnego.

    winpty openssl genpkey -out private/<DEVICE_NAME>.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048
winpty openssl req -new -key private/<DEVICE_NAME>.key -out <DEVICE_NAME>.csr

  3. Po wyświetleniu monitu podaj szczegóły certyfikatu, jak pokazano w poniższym przykładzie.

    Jedynym monitem o podanie określonej wartości jest nazwa pospolita, która musi być tą samą nazwą urządzenia podaną w poprzednim kroku. Możesz pominąć lub podać dowolne wartości dla pozostałych monitów.

    Po podaniu szczegółów certyfikatu program OpenSSL generuje i wyświetla szczegóły certyfikatu, a następnie monituje o podpisanie i zatwierdzenie certyfikatu dla podrzędnego urzędu certyfikacji. Określ wartość y dla obu monitów o wygenerowanie certyfikatu dla podrzędnego urzędu certyfikacji.

    -----
Country Name (2 letter code) [XX]:.
State or Province Name (full name) []:.
Locality Name (eg, city) [Default City]:.
Organization Name (eg, company) [Default Company Ltd]:.
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server hostname) []:'<DEVICE_NAME>'
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

    Przed kontynuowaniem upewnij się, że plik CSR znajduje się w katalogu podrzędnego urzędu certyfikacji, a plik klucza prywatnego znajduje się w podkatalogu private . Aby uzyskać więcej informacji na temat formatów plików CSR i kluczy prywatnych, zobacz X.509 certificates (Certyfikaty X.509).

  4. W oknie powłoki Git Bash uruchom następujące polecenie, zastępując symbole zastępcze nazwy urządzenia tą samą nazwą, która została użyta w poprzednich krokach.

    Ten krok powoduje utworzenie certyfikatu klienta w katalogu podrzędnego urzędu certyfikacji. Polecenie stosuje client_ext rozszerzenia plików konfiguracji do certyfikatu. Rozszerzenia te wskazują, że certyfikat jest przeznaczony dla certyfikatu klienta, który nie może być używany jako certyfikat urzędu certyfikacji. Certyfikat klienta jest podpisany przy użyciu certyfikatu podrzędnego urzędu certyfikacji.

    winpty openssl ca -config subca.conf -in <DEVICE_NAME>.csr -out <DEVICE_NAME>.crt -extensions client_ext

    Zostanie wyświetlony monit o wprowadzenie frazy dostępu, jak pokazano w poniższym przykładzie dla pliku klucza prywatnego podrzędnego urzędu certyfikacji. Po wprowadzeniu frazy pass program OpenSSL generuje i wyświetla szczegóły certyfikatu, a następnie monituje o podpisanie i zatwierdzenie certyfikatu klienta dla urządzenia. Określ wartość y dla obu monitów o wygenerowanie certyfikatu klienta.

    Using configuration from subca.conf
Enter pass phrase for ../subca/private/subca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
    {Details omitted from output for clarity}
Certificate is to be certified until Mar 24 18:51:41 2024 GMT (365 days)
Sign the certificate? [y/n]:


1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated

    Po zaktualizowaniu bazy danych certyfikatów openSSL upewnij się, że plik certyfikatu dla certyfikatu klienta znajduje się w katalogu podrzędnego urzędu certyfikacji i że plik certyfikatu PEM (pem) dla certyfikatu klienta znajduje się w podkatalogu certyfikatów podrzędnego urzędu certyfikacji. Nazwa pliku pem jest zgodna z numerem seryjnym certyfikatu klienta.

Następne kroki

Możesz zarejestrować urządzenie w centrum IoT na potrzeby testowania certyfikatu klienta utworzonego dla tego urządzenia. Aby uzyskać więcej informacji na temat rejestrowania urządzenia, zobacz Tworzenie tożsamości urządzeń i zarządzanie nimi.

Jeśli masz wiele powiązanych urządzeń do testowania, możesz użyć usługi Azure IoT Hub Device Provisioning, aby aprowizować wiele urządzeń w grupie rejestracji. Aby uzyskać więcej informacji na temat korzystania z grup rejestracji w usłudze Device Provisioning Service, zobacz Samouczek: aprowizowanie wielu urządzeń X.509 przy użyciu grup rejestracji.