Dela via

Självstudie: Skapa och ladda upp certifikat för testning

  • Artikel

Du kan använda X.509-certifikat för att autentisera enheter till din IoT-hubb. För produktionsmiljöer rekommenderar vi att du köper ett X.509 CA-certifikat från en leverantör av professionella certifikattjänster. Du kan sedan utfärda certifikat inom din organisation från en intern, självhanterad certifikatutfärdare (CA) som är länkad till det köpta CA-certifikatet som en del av en omfattande PKI-strategi (Public Key Infrastructure). Mer information om hur du hämtar ett X.509 CA-certifikat från en leverantör av professionella certifikattjänster finns i avsnittet Hämta ett X.509 CA-certifikat för autentisera enheter med X.509 CA-certifikat.

Men att skapa en egen självhanterad, privat certifikatutfärdare som använder en intern rotcertifikatutfärdare som förtroendeankare räcker för att testa miljöer. Med en självhanterad privat certifikatutfärdare med minst en underordnad certifikatutfärdare kopplad till din interna rotcertifikatutfärdare, med klientcertifikat för dina enheter som är signerade av dina underordnade certifikatutfärdare, kan du simulera en rekommenderad produktionsmiljö.

Viktigt!

Vi rekommenderar inte att du använder självsignerade certifikat för produktionsmiljöer. Den här självstudien visas endast i demonstrationssyfte.

I följande självstudie används OpenSSL och OpenSSL Cookbook för att beskriva hur du utför följande uppgifter:

  • Skapa en intern rotcertifikatutfärdare (CA) och rotcertifikatutfärdarcertifikat
  • Skapa en intern underordnad certifikatutfärdare och ett underordnat CA-certifikat, signerat av ditt interna rotcertifikatutfärdarcertifikat
  • Ladda upp ditt underordnade CA-certifikat till din IoT-hubb i testsyfte
  • Använd den underordnade certifikatutfärdare för att skapa klientcertifikat för de IoT-enheter som du vill testa med din IoT-hubb

Kommentar

Microsoft tillhandahåller PowerShell- och Bash-skript som hjälper dig att förstå hur du skapar dina egna X.509-certifikat och autentiserar dem till en IoT-hubb. Skripten ingår i Azure IoT Hub Device SDK för C. Skripten tillhandahålls endast i demonstrationssyfte. Certifikat som skapats av dem får inte användas för produktion. Certifikaten innehåller hårdkodade lösenord ("1234") och upphör att gälla efter 30 dagar. Du måste använda dina egna metodtips för skapande av certifikat och livslängdshantering i en produktionsmiljö. Mer information finns i Hantera certifikat för testcertifikatutfärdare för exempel och självstudier på GitHub-lagringsplatsen för Azure IoT Hub Device SDK för C.

Förutsättningar

  • En Azure-prenumeration. Om du inte har någon Azure-prenumeration kan du skapa ett kostnadsfritt konto innan du börjar.

  • En IoT-hubb i din Azure-prenumeration. Om du inte har någon hubb ännu kan du följa stegen i Skapa en IoT-hubb.

  • Den senaste versionen av Git. Kontrollera att Git har lagts till i de miljövariabler som är tillgängliga för kommandofönstret. Se Software Freedom Conservancys Git-klientverktyg för den senaste versionen av git verktyg som ska installeras, vilket inkluderar Git Bash, kommandoradsappen som du kan använda för att interagera med din lokala Git-lagringsplats.

  • En OpenSSL-installation . I Windows innehåller installationen av Git en installation av OpenSSL. Du kan komma åt OpenSSL från Git Bash-prompten. Om du vill kontrollera att OpenSSL är installerat öppnar du en Git Bash-prompt och anger openssl version.

    Kommentar

    Om du inte är bekant med OpenSSL och redan har installerat det på din Windows-dator rekommenderar vi att du använder OpenSSL från Git Bash-prompten. Du kan också välja att ladda ned källkoden och skapa OpenSSL. Mer information finns på sidan OpenSSL-nedladdningar . Eller så kan du ladda ned OpenSSL som är färdigbyggt från en tredje part. Mer information finns i OpenSSL-wikin. Microsoft ger inga garantier om giltigheten för paket som laddats ned från tredje part. Om du väljer att skapa eller ladda ned OpenSSL kontrollerar du att OpenSSL-binärfilen är tillgänglig i sökvägen och att OPENSSL_CNF miljövariabeln är inställd på sökvägen till filen openssl.cnf .

Skapa en rotcertifikatutfärdare

Du måste först skapa en intern rotcertifikatutfärdare (CA) och ett självsignerat rotcertifikatutfärdarcertifikat för att fungera som ett förtroendeankare där du kan skapa andra certifikat för testning. De filer som används för att skapa och underhålla din interna rotcertifikatutfärdare lagras i en mappstruktur och initieras som en del av den här processen. Utför följande steg:

  • Skapa och initiera de mappar och filer som används av rotcertifikatutfärdarcertifikatutfärdarna
  • Skapa en konfigurationsfil som används av OpenSSL för att konfigurera rotcertifikatutfärdare och certifikat som skapats med rotcertifikatutfärdare
  • Begära och skapa ett självsignerat CA-certifikat som fungerar som rotcertifikatutfärdarcertifikat

  1. Starta ett Git Bash-fönster och kör följande kommando och ersätt {base_dir} med den önskade katalogen där du kan skapa certifikaten i den här självstudien.

    cd {base_dir}

  2. I Git Bash-fönstret kör du följande kommandon, ett i taget. Det här steget skapar följande katalogstruktur och stödfiler för rotcertifikatutfärdarorganisationen.

    Katalog eller fil beskrivning
    rootca Rotkatalogen för rotcertifikatutfärdarorganisationen.
    rootca/certs Katalogen där CA-certifikat för rotcertifikatutfärdare skapas och lagras.
    rootca/db Katalogen där certifikatdatabasen och stödfilerna för rotcertifikatutfärdare lagras.
    rootca/db/index Certifikatdatabasen för rotcertifikatutfärdare. Kommandot touch skapar en fil utan innehåll för senare användning. Certifikatdatabasen är en oformaterad textfil som hanteras av OpenSSL och som innehåller information om utfärdade certifikat. Mer information om certifikatdatabasen finns på sidan opensl-ca manuell.
    rootca/db/serial En fil som används för att lagra serienumret för nästa certifikat som ska skapas för rotcertifikatutfärdare. Kommandot openssl skapar ett slumpmässigt tal på 16 byte i hexadecimalt format och lagrar det sedan i den här filen för att initiera filen för att skapa rotcertifikatutfärdarcertifikatet.
    rootca/db/crlnumber En fil som används för att lagra serienummer för återkallade certifikat som utfärdats av rotcertifikatutfärdare. Kommandot echo skickar ett exempelserienummer, 1001, till filen.
    rootca/private Katalogen där privata filer för rotcertifikatutfärdarorganisationen, inklusive den privata nyckeln, lagras.
    Filerna i den här katalogen måste skyddas och skyddas.    		 
    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. Skapa en textfil med namnet rootca.conf i katalogen rootca som skapades i föregående steg. Öppna filen i en textredigerare och kopiera och spara sedan följande OpenSSL-konfigurationsinställningar i filen.

    Filen tillhandahåller OpenSSL med de värden som behövs för att konfigurera testrotcertifikatutfärdare. I det här exemplet konfigurerar filen en rotcertifikatutfärdare med namnet rootca med hjälp av kataloger och filer som skapades i föregående steg. Filen innehåller även konfigurationsinställningar för:

    • Ca-principen som används av rotcertifikatutfärdarcertifikatutfärdare för DN-fält (Distinguished Name)
    • Certifikatbegäranden som skapats av rotcertifikatutfärdare
    • X.509-tillägg som tillämpas på rotcertifikatutfärdarcertifikat, underordnade CA-certifikat och klientcertifikat som utfärdats av rotcertifikatutfärdare

    Kommentar

    Attributet home i avsnittet ca_default är inställt ../rootca på eftersom den här konfigurationsfilen också används när du skapar certifikatet för den underordnade certifikatutfärdare. Med den angivna relativa sökvägen kan OpenSSL navigera från den underordnade CA-mappen till rot-CA-mappen under den processen.

    Mer information om syntaxen för OpenSSL-konfigurationsfiler finns på sidan config manual i OpenSSL-dokumentationen.

    [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. I Git Bash-fönstret kör du följande kommando för att generera en begäran om certifikatsignering (CSR) i rootca katalogen och en privat nyckel i rootca/private katalogen. Mer information om OpenSSL-kommandot req finns på sidan openssl-req manual i OpenSSL-dokumentationen.

    Kommentar

    Även om rotcertifikatutfärdare används för testning och inte exponeras som en del av en offentlig nyckelinfrastruktur (PKI), rekommenderar vi att du inte kopierar eller delar den privata nyckeln.

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

    Du uppmanas att ange en PEM-passfras, som du ser i följande exempel, för den privata nyckelfilen. Ange och bekräfta en lösenfras för att generera din privata nyckel och CSR.

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

    Bekräfta att CSR-filen, rootca.csr, finns i rootca katalogen och att den privata nyckelfilen, rootca.key, finns i underkatalogen private innan du fortsätter.

  5. I Git Bash-fönstret kör du följande kommando för att skapa ett självsignerat rotcertifikatutfärdarcertifikat. Kommandot tillämpar konfigurationsfilnamnstilläggen ca_ext på certifikatet. Dessa tillägg anger att certifikatet är för en rotcertifikatutfärdare och kan användas för att signera certifikat och listor över återkallade certifikat (CRL). Mer information om OpenSSL-kommandot ca finns på sidan openssl-ca manual i OpenSSL-dokumentationen.

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

    Du uppmanas att ange PEM-passfrasen, som du ser i följande exempel, för den privata nyckelfilen. När du har angett passfrasen genererar OpenSSL ett certifikat och uppmanar dig sedan att signera och checka in certifikatet för rotcertifikatutfärdare. Ange y för båda prompterna för att generera det självsignerade certifikatet för rotcertifikatutfärdare.

    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

    När OpenSSL har uppdaterat certifikatdatabasen kontrollerar du att både certifikatfilen , rootca.crtfinns i rootca katalogen och att PEM-certifikatfilen (.pem) för certifikatet finns i rootca/certs katalogen. Filnamnet för .pem-filen matchar serienumret för rotcertifikatutfärdarcertifikatet.

Skapa en underordnad ca

När du har skapat din interna rotcertifikatutfärdare bör du skapa en underordnad certifikatutfärdare som ska användas som mellanliggande certifikatutfärdare för att signera klientcertifikat för dina enheter. I teorin behöver du inte skapa en underordnad certifikatfärdare. du kan ladda upp rotcertifikatutfärdarcertifikatet till din IoT-hubb och signera klientcertifikat direkt från rotcertifikatutfärdare. Om du använder en underordnad certifikatutfärdare som mellanliggande certifikatutfärdare för att signera klientcertifikat simuleras dock en rekommenderad produktionsmiljö, där rotcertifikatutfärdare hålls offline. Du kan också använda en underordnad ca för att signera en annan underordnad certifikatfärdare, som i sin tur kan signera en annan underordnad certifikatfärdare och så vidare. Om du använder underordnade certifikatutfärdare för att signera andra underordnade certifikatutfärdare skapas en hierarki med mellanliggande certifikatutfärdare som en del av en certifikatkedja med förtroende. I en produktionsmiljö tillåter certifikatkedjan förtroende en delegering av förtroende till signeringsenheter. Mer information om hur du loggar in enheter i en förtroendekedja finns i Autentisera enheter med X.509 CA-certifikat.

Precis som din rotcertifikatutfärdare lagras de filer som används för att skapa och underhålla din underordnade certifikatutfärdare i en mappstruktur och initieras som en del av den här processen. Utför följande steg:

  • Skapa och initiera de mappar och filer som används av din underordnade CERTIFIKAT
  • Skapa en konfigurationsfil som används av OpenSSL för att konfigurera din underordnade certifikatutfärdare och certifikat som skapats med din underordnade certifikatutfärdare
  • Begära och skapa ett CA-certifikat signerat av rotcertifikatutfärdare som fungerar som ditt underordnade CA-certifikat

  1. Gå tillbaka till den baskatalog som innehåller rootca katalogen. I det här exemplet finns både rotcertifikatutfärdarorganisationen och den underordnade CA:en i samma baskatalog.

    cd ..

  2. I Git Bash-fönstret kör du följande kommandon, ett i taget.

    Det här steget skapar en katalogstruktur och stödfiler för den underordnade certifikatutfärdare som liknar mappstrukturen och filerna som skapades för rotcertifikatutfärdare i föregående avsnitt.

    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. Skapa en textfil med namnet subca.conf i katalogen subca som skapades i föregående steg. Öppna filen i en textredigerare och kopiera och spara sedan följande OpenSSL-konfigurationsinställningar i filen.

    Precis som med konfigurationsfilen för testrotcertifikatutfärdare tillhandahåller den här filen OpenSSL med de värden som behövs för att konfigurera din underordnad certifikatutfärdare för test. Du kan skapa flera underordnade certifikatutfärdare för att hantera testscenarier eller miljöer.

    Mer information om syntaxen för OpenSSL-konfigurationsfiler finns på den manuella sidan för konfigurationshanteraren i OpenSSL-dokumentationen.

    [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. I Git Bash-fönstret kör du följande kommandon för att generera en privat nyckel och en certifikatsigneringsbegäran (CSR) i den underordnade CA-katalogen.

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

    Du uppmanas att ange en PEM-passfras, som du ser i följande exempel, för den privata nyckelfilen. Ange och verifiera en lösenfras för att generera din privata nyckel och CSR.

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

    Bekräfta att CSR-filen subca.csr finns i den underordnade CA-katalogen och att den privata nyckelfilen subca.key finns i underkatalogen private innan du fortsätter.

  5. I Git Bash-fönstret kör du följande kommando för att skapa ett underordnat CA-certifikat i den underordnade CA-katalogen. Kommandot tillämpar konfigurationsfilnamnstilläggen sub_ca_ext på certifikatet. Dessa tillägg anger att certifikatet är för en underordnad certifikatutfärdare och kan även användas för att signera certifikat och listor över återkallade certifikat (CRL). Till skillnad från rotcertifikatutfärdarcertifikatet är det här certifikatet inte självsignerat. I stället signeras det underordnade CA-certifikatet med rotcertifikatutfärdarcertifikatet och upprättar en certifikatkedja som liknar den du skulle använda för en offentlig nyckelinfrastruktur (PKI). Det underordnade CA-certifikatet används sedan för att signera klientcertifikat för att testa dina enheter.

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

    Du uppmanas att ange frasen pass, som du ser i följande exempel, för den privata nyckelfilen för rotcertifikatutfärdarcertifikatutfärdarna. När du har angett lösenfrasen genererar OpenSSL och visar information om certifikatet och uppmanar dig sedan att signera och checka in certifikatet för den underordnade certifikatutfärdare. Ange y för båda uppmaningarna att generera certifikatet för den underordnade certifikatutfärdare.

    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

    När OpenSSL har uppdaterat certifikatdatabasen kontrollerar du att certifikatfilen subca.crt finns i den underordnade CA-katalogen och att PEM-certifikatfilen (.pem) för certifikatet finns i rootca/certs katalogen. Filnamnet för .pem-filen matchar serienumret för det underordnade CA-certifikatet.

Registrera ditt underordnade CA-certifikat till din IoT-hubb

Registrera det underordnade CA-certifikatet till din IoT-hubb, som använder det för att autentisera dina enheter under registreringen och anslutningen. Följande steg beskriver hur du laddar upp och automatiskt verifierar ditt underordnade CA-certifikat till din IoT-hubb.

  1. I Azure Portal går du till din IoT-hubb och väljer Certifikat på resursmenyn under Säkerhetsinställningar.

  2. Välj Lägg till i kommandofältet för att lägga till ett nytt CA-certifikat.

  3. Ange ett visningsnamn för ditt underordnade CA-certifikat i fältet Certifikatnamn .

  4. Välj PEM-certifikatfilen (.pem) för ditt underordnade CA-certifikat från rootca/certs katalogen för att lägga till i fältet Certifikat .pem eller .cer fil .

  5. Markera kryssrutan bredvid Ange certifikatstatus som verifierad vid uppladdning.

    Skärmbild som visar hur du automatiskt verifierar certifikatstatusen vid uppladdning.

  6. Välj Spara.

Det uppladdade underordnade CA-certifikatet visas med statusen Verifierad på fliken Certifikat i arbetsfönstret.

Skapa ett klientcertifikat för en enhet

När du har skapat din underordnade certifikatutfärdare kan du skapa klientcertifikat för dina enheter. De filer och mappar som skapats för den underordnade certifikatutfärdaren används för att lagra CSR- och privata nyckel- och certifikatfiler för dina klientcertifikat.

Klientcertifikatet måste ha värdet för sitt cn-fält (Subject Common Name) inställt på värdet för det enhets-ID som används när motsvarande enhet registreras i Azure IoT Hub.

Utför följande steg:

  • Skapa en privat nyckel och certifikatsigneringsbegäran (CSR) för ett klientcertifikat
  • Skapa ett klientcertifikat signerat av ditt underordnade CA-certifikat

  1. Kontrollera att du fortfarande är i katalogen i subca Git Bash-fönstret.

  2. I Git Bash-fönstret kör du följande kommandon en i taget. Ersätt platshållaren med ett namn på din IoT-enhet, till exempel testdevice. Det här steget skapar den privata nyckeln och CSR för klientcertifikatet.

    Det här steget skapar en 2048-bitars RSA privat nyckel för klientcertifikatet och genererar sedan en certifikatsigneringsbegäran (CSR) med den privata nyckeln.

    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. När du uppmanas till det anger du certifikatinformation som visas i följande exempel.

    Den enda uppmaning som du behöver ange ett specifikt värde för är Det gemensamma namnet, som måste vara samma enhetsnamn som angavs i föregående steg. Du kan hoppa över eller ange godtyckliga värden för resten av anvisningarna.

    När du har angett certifikatinformationen genererar och visar OpenSSL information om certifikatet och uppmanar dig sedan att signera och checka in certifikatet för den underordnade certifikatutfärdare. Ange y för båda anvisningarna för att generera certifikatet för den underordnade certifikatutfärdare.

    -----
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 []:

    Bekräfta att CSR-filen finns i den underordnade CA-katalogen och att den privata nyckelfilen finns i underkatalogen private innan du fortsätter. Mer information om formaten för CSR- och privata nyckelfiler finns i X.509-certifikat.

  4. I Git Bash-fönstret kör du följande kommando och ersätter platshållarna för enhetsnamn med samma namn som du använde i föregående steg.

    Det här steget skapar ett klientcertifikat i den underordnade CA-katalogen. Kommandot tillämpar konfigurationsfilnamnstilläggen client_ext på certifikatet. Dessa tillägg anger att certifikatet är för ett klientcertifikat, som inte kan användas som certifikatutfärdare. Klientcertifikatet är signerat med det underordnade CA-certifikatet.

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

    Du uppmanas att ange frasen pass, som du ser i följande exempel, för den privata nyckelfilen för din underordnade CERTIFIKATEXempel. När du har angett lösenfrasen genererar OpenSSL och visar information om certifikatet och uppmanar dig sedan att signera och checka in klientcertifikatet för enheten. Ange y för båda anvisningarna för att generera klientcertifikatet.

    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

    När OpenSSL har uppdaterat certifikatdatabasen kontrollerar du att certifikatfilen för klientcertifikatet finns i den underordnade CA-katalogen och att PEM-certifikatfilen (.pem) för klientcertifikatet finns i certifikatunderkatalogen för den underordnade CA-katalogen. Filnamnet för .pem-filen matchar serienumret för klientcertifikatet.

Nästa steg

Du kan registrera din enhet med din IoT-hubb för att testa det klientcertifikat som du har skapat för den enheten. Mer information om hur du registrerar en enhet finns i Skapa och hantera enhetsidentiteter.

Om du har flera relaterade enheter att testa kan du använda Azure IoT Hub Device Provisioning Service för att etablera flera enheter i en registreringsgrupp. Mer information om hur du använder registreringsgrupper i enhetsetableringstjänsten finns i Självstudie: Etablera flera X.509-enheter med hjälp av registreringsgrupper.