Delen via

Zelfstudie: Certificaten maken en uploaden voor testen

U kunt X.509-certificaten gebruiken om apparaten te verifiëren bij uw IoT-hub. Voor productieomgevingen raden we u aan een X.509-CA-certificaat aan te schaffen bij een professionele leverancier van certificaatservices. Vervolgens kunt u certificaten binnen uw organisatie uitgeven vanuit een interne, zelfbeheerde certificeringsinstantie (CA) die is gekoppeld aan het aangeschafte CA-certificaat als onderdeel van een uitgebreide PKI-strategie (Public Key Infrastructure). Zie de sectie Een X.509-CA-certificaat verkrijgen in Apparaten authenticeren met X.509-CA-certificaten voor meer informatie over het verkrijgen van een X.509-CA-certificaat van een professionele leverancier van certificaatservices.

Het maken van uw eigen zelfbeheerde privé-CA die een interne basis-CA als vertrouwensanker gebruikt, is voldoende voor testomgevingen. Met een zelfbeheerde privé-CA met ten minste één onderliggende CA die is gekoppeld aan uw interne basis-CA, met clientcertificaten voor uw apparaten die zijn ondertekend door uw onderliggende CA's, kunt u een aanbevolen productieomgeving simuleren.

Important

Het gebruik van zelfondertekende certificaten voor productieomgevingen wordt niet aanbevolen. Deze handleiding wordt alleen voor demonstratie gepresenteerd.

In de volgende zelfstudie worden OpenSSL en het OpenSSL Cookbook gebruikt om te beschrijven hoe u de volgende taken uitvoert:

  • Een interne basiscertificeringsinstantie (CA) en een basis-CA-certificaat maken
  • Maak een interne onderliggende CA en een onderliggend CA-certificaat, ondertekend door uw interne basis-CA-certificaat
  • Upload uw onderliggende CA-certificaat naar uw IoT-hub voor testdoeleinden
  • Gebruik de onderliggende CA om clientcertificaten te maken voor de IoT-apparaten die u wilt testen met uw IoT-hub

Note

Microsoft biedt PowerShell- en Bash-scripts om u te helpen begrijpen hoe u uw eigen X.509-certificaten maakt en verifieert bij een IoT-hub. De scripts zijn opgenomen in de Azure IoT Hub Device SDK voor C. De scripts zijn alleen beschikbaar voor demonstratiedoeleinden. Certificaten die door hen zijn gemaakt, mogen niet in productie worden gebruikt. De certificaten bevatten in code vastgelegde wachtwoorden ('1234') en verlopen na 30 dagen. U moet uw eigen best practices gebruiken voor het maken van certificaten en levensduurbeheer in een productieomgeving. Zie Test-CA-certificaten beheren voor voorbeelden en zelfstudies in de GitHub-opslagplaats voor de Azure IoT Hub Device SDK voor C voor meer informatie.

Prerequisites

  • Een Azure-abonnement. Als je geen Azure-abonnement hebt, maak dan een gratis account aan voordat je begint.

  • Een IoT-hub in uw Azure-abonnement. Als u nog geen hub hebt, kunt u de stappen volgen in Een IoT-hub maken.

  • De nieuwste versie van Git. Zorg ervoor dat Git is toegevoegd aan de omgevingsvariabelen die toegankelijk zijn voor het opdrachtvenster. Zie de Git-clienthulpprogramma's van Software Freedom Conservancy voor de nieuwste versie van git hulpprogramma's die u kunt installeren, waaronder Git Bash, de opdrachtregel-app die u kunt gebruiken om te communiceren met uw lokale Git-opslagplaats.

  • Een OpenSSL-installatie . In Windows bevat uw installatie van Git een installatie van OpenSSL. U kunt OpenSSL openen via de Git Bash-prompt. Als u wilt controleren of OpenSSL is geïnstalleerd, opent u een Git Bash-prompt en voert u deze in openssl version.

    Note

    Tenzij u bekend bent met OpenSSL en deze al op uw Windows-computer is geïnstalleerd, raden we u aan OpenSSL te gebruiken via de Git Bash-prompt. U kunt er ook voor kiezen om de broncode te downloaden en OpenSSL te bouwen. Zie de pagina OpenSSL Downloads voor meer informatie. U kunt ook OpenSSL vooraf downloaden van een niet-Microsoft-partner. Zie de OpenSSL-wiki voor meer informatie. Microsoft biedt geen garanties over de geldigheid van pakketten die van derden zijn gedownload. Als u ervoor kiest om OpenSSL te bouwen of te downloaden, moet u ervoor zorgen dat het binaire bestand OpenSSL toegankelijk is in uw pad en dat de OPENSSL_CNF omgevingsvariabele is ingesteld op het pad van het bestand openssl.cnf .

Een basis-CA maken

U moet eerst een interne basiscertificeringsinstantie (CA) en een zelfondertekend basis-CA-certificaat maken om te fungeren als een vertrouwensanker van waaruit u andere certificaten kunt maken voor testen. De bestanden die worden gebruikt om uw interne basis-CA te maken en te onderhouden, worden opgeslagen in een mapstructuur en geïnitialiseerd als onderdeel van dit proces. Voer de volgende stappen uit om:

  • De mappen en bestanden maken en initialiseren die worden gebruikt door uw basis-CA
  • Een configuratiebestand maken dat wordt gebruikt door OpenSSL om uw basis-CA en certificaten te configureren die zijn gemaakt met uw basis-CA
  • Een zelfondertekend CA-certificaat aanvragen en maken dat als basis-CA-certificaat fungeert

  1. Start een Git Bash-venster en voer de volgende opdracht uit, waarbij u {base_dir} vervangt door de gewenste map waarin de certificaten in deze zelfstudie moeten worden gemaakt.

    cd {base_dir}

  2. Voer in het Git Bash-venster de volgende opdrachten één voor één uit. Met deze stap maakt u de volgende mapstructuur en ondersteuningsbestanden voor de basis-CA.

    Map of bestand Description
    rootca De hoofddirectory van de root-CA.
    rootca/certs De map waarin CA-certificaten voor de basis-CA worden gemaakt en opgeslagen.
    rootca/db De map waarin de certificaatdatabase en ondersteuningsbestanden voor de basis-CA worden opgeslagen.
    rootca/db/index De certificaatdatabase voor de basis-CA. Met de touch opdracht maakt u een bestand zonder inhoud, voor later gebruik. De certificaatdatabase is een tekstbestand zonder opmaak dat wordt beheerd door OpenSSL met informatie over uitgegeven certificaten. Zie de handmatige pagina openssl-ca voor meer informatie over de certificaatdatabase.
    rootca/db/serial Een bestand dat wordt gebruikt voor het opslaan van het serienummer van het volgende certificaat dat moet worden gemaakt voor de basis-CA. Met de openssl opdracht wordt een willekeurig getal van 16 bytes gemaakt in hexadecimale indeling en vervolgens opgeslagen in dit bestand om het bestand te initialiseren voor het maken van het basis-CA-certificaat.
    rootca/db/crlnumber Een bestand dat wordt gebruikt voor het opslaan van serienummers voor ingetrokken certificaten die zijn uitgegeven door de basis-CA. Met de echo opdracht wordt een voorbeeldserienummer, 1001, naar het bestand gepiped.
    rootca/private De map waarin persoonlijke bestanden voor de basis-CA, inclusief de persoonlijke sleutel, worden opgeslagen.
    De bestanden in deze map moeten worden beveiligd en beschermd.    		 
    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. Maak een tekstbestand met de naam rootca.conf in de rootca map die in de vorige stap is gemaakt. Open dat bestand in een teksteditor en kopieer en sla de volgende OpenSSL-configuratie-instellingen op in dat bestand.

    Het bestand biedt OpenSSL de waarden die nodig zijn om uw testhoofd-CA te configureren. In dit voorbeeld configureert het bestand een basis-CA met de naam rootca met behulp van de mappen en bestanden die in de vorige stappen zijn gemaakt. Het bestand biedt ook configuratie-instellingen voor:

    • Het CA-beleid dat wordt gebruikt door de basis-CA voor DN-velden (Distinguished Name) van het certificaat
    • Certificaataanvragen die zijn gemaakt door de basis-CA
    • X.509-extensies die zijn toegepast op basis-CA-certificaten, onderliggende CA-certificaten en clientcertificaten die zijn uitgegeven door de basis-CA

    Note

    Het home kenmerk in de ca_default sectie is ingesteld op ../rootca omdat dit configuratiebestand ook wordt gebruikt bij het maken van het certificaat voor uw onderliggende CA. Met het opgegeven relatieve pad kan OpenSSL tijdens dat proces vanuit uw onderliggende CA-map naar de hoofd-CA-map navigeren.

    Zie de pagina met configuratiehandleidingen in de OpenSSL-documentatie voor meer informatie over de syntaxis van OpenSSL-configuratiebestanden.

    [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. Voer in het Git Bash-venster de volgende opdracht uit om een aanvraag voor certificaatondertekening (CSR) te genereren in de rootca map en een persoonlijke sleutel in de rootca/private map. Zie de handmatige pagina req in de OpenSSL-documentatie voor meer informatie over de OpenSSL-opdracht.

    Note

    U wordt aangeraden de persoonlijke sleutel niet te kopiëren of te delen, ook al is deze basis-CA bedoeld voor testdoeleinden en wordt deze niet weergegeven als onderdeel van een openbare-sleutelinfrastructuur (PKI).

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

    U wordt gevraagd een PEM-wachtwoordzin in te voeren, zoals wordt weergegeven in het volgende voorbeeld voor het bestand met de persoonlijke sleutel. Voer een wachtwoordzin in en bevestig deze om uw persoonlijke sleutel en CSR te genereren.

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

    Controleer of het CSR-bestand rootca.csr aanwezig is in de rootca map. Controleer vervolgens of het bestand met de persoonlijke sleutel aanwezig rootca.keyis in de private submap voordat u doorgaat.

  5. Voer in het Git Bash-venster de volgende opdracht uit om een zelfondertekend basis-CA-certificaat te maken. Met de opdracht worden de ca_ext configuratiebestandsextensies toegepast op het certificaat. Deze extensies geven aan dat het certificaat voor een basis-CA is en kan worden gebruikt om certificaten en certificaatintrekkingslijsten (CRL's) te ondertekenen. Zie de handleidingpagina ca in de OpenSSL-documentatie voor meer informatie over de OpenSSL-opdracht.

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

    U wordt gevraagd om de PEM-wachtwoordzin op te geven, zoals wordt weergegeven in het volgende voorbeeld voor het bestand met de persoonlijke sleutel. Nadat u de wachtwoordzin hebt opgegeven, genereert OpenSSL een certificaat en wordt u gevraagd het certificaat voor uw basis-CA te ondertekenen en door te voeren. Geef y op voor beide prompts om het zelfondertekende certificaat voor uw basis-CA te genereren.

    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
Database updated

    Nadat OpenSSL de certificaatdatabase heeft bijgewerkt, controleert u of zowel het certificaatbestand, rootca.crtaanwezig is in de rootca map als het PEM-certificaatbestand (.pem) voor het certificaat aanwezig is in de rootca/certs map. De bestandsnaam van het PEM-bestand komt overeen met het serienummer van het basis-CA-certificaat.

Een onderliggende CA maken

Nadat u uw interne basis-CA hebt gemaakt, moet u een onderliggende CA maken die moet worden gebruikt als een tussenliggende CA waarmee clientcertificaten voor uw apparaten moeten worden ondertekend. In theorie hoeft u geen onderliggende CA te maken; u kunt uw basis-CA-certificaat uploaden naar uw IoT-hub en clientcertificaten rechtstreeks vanuit uw basis-CA ondertekenen. Als u echter een onderliggende CA als tussenliggende CA gebruikt om clientcertificaten beter te ondertekenen, wordt een aanbevolen productieomgeving gesimuleerd, waarin uw basis-CA offline wordt gehouden. U kunt ook een onderliggende CA gebruiken om een andere onderliggende CA te ondertekenen, die op zijn beurt een andere onderliggende CA kan ondertekenen, enzovoort. Als u onderliggende CA's gebruikt om andere onderliggende CA's te ondertekenen, wordt een hiërarchie van tussenliggende CA's gemaakt als onderdeel van een certificaatketen van vertrouwen. In een productieomgeving staat de certificaatketen van vertrouwen een overdracht van vertrouwen toe voor het ondertekenen van apparaten. Zie Identiteiten verifiëren met X.509-certificaten voor meer informatie over het aanmelden bij een certificaatketen van vertrouwen.

Net als bij uw basis-CA worden de bestanden die worden gebruikt voor het maken en onderhouden van uw onderliggende CA opgeslagen in een mapstructuur en geïnitialiseerd als onderdeel van dit proces. Voer de volgende stappen uit om:

  • De mappen en bestanden maken en initialiseren die worden gebruikt door uw onderliggende CA
  • Een configuratiebestand maken dat wordt gebruikt door OpenSSL om uw onderliggende CA en certificaten te configureren die zijn gemaakt met uw onderliggende CA
  • Een CA-certificaat aanvragen en maken dat is ondertekend door uw basis-CA die fungeert als uw onderliggende CA-certificaat

  1. Ga terug naar de basismap die de rootca map bevat. In dit voorbeeld bevinden zowel de basis-CA als de onderliggende CA zich in dezelfde basismap.

    cd ..

  2. Voer in het Git Bash-venster de volgende opdrachten één voor één uit.

    Met deze stap maakt u een mapstructuur en ondersteuningsbestanden voor de onderliggende CA die vergelijkbaar is met de mapstructuur en bestanden die zijn gemaakt voor de basis-CA in de vorige sectie.

    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. Maak een tekstbestand met de naam subca.conf in de subca map die in de vorige stap is gemaakt. Open dat bestand in een teksteditor en kopieer en sla de volgende OpenSSL-configuratie-instellingen op in dat bestand.

    Net als bij het configuratiebestand voor uw testhoofd-CA biedt dit bestand OpenSSL de waarden die nodig zijn om uw onderliggende test-CA te configureren. U kunt meerdere onderliggende CA's maken voor het beheren van testscenario's of omgevingen.

    Zie de hoofdpagina van de config handleiding in de OpenSSL-documentatie voor meer informatie over de syntaxis van OpenSSL-configuratiebestanden.

    [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. Voer in het Git Bash-venster de volgende opdrachten uit om een persoonlijke sleutel en een aanvraag voor certificaatondertekening (CSR) te genereren in de onderliggende CA-map.

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

    U wordt gevraagd een PEM-wachtwoordzin in te voeren, zoals wordt weergegeven in het volgende voorbeeld voor het bestand met de persoonlijke sleutel. Voer een wachtwoordzin in en controleer deze om uw persoonlijke sleutel en CSR te genereren.

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

    Controleer of het CSR-bestand subca.csr aanwezig is in de onderliggende CA-map. Controleer vervolgens of het bestand subca.key met de persoonlijke sleutel aanwezig is in de private submap voordat u doorgaat.

  5. Voer in het Git Bash-venster de volgende opdracht uit om een ondergeschikt CA-certificaat te maken in de onderliggende CA-map. Met de opdracht worden de sub_ca_ext configuratiebestandsextensies toegepast op het certificaat. Deze extensies geven aan dat het certificaat voor een onderliggende CA is en kan ook worden gebruikt om certificaten en certificaatintrekkingslijsten (CRL's) te ondertekenen. In tegenstelling tot het basis-CA-certificaat is dit certificaat niet zelfondertekend. In plaats daarvan wordt het onderliggende CA-certificaat ondertekend met het basis-CA-certificaat, waarbij een certificaatketen tot stand wordt gebracht die vergelijkbaar is met wat u zou gebruiken voor een openbare-sleutelinfrastructuur (PKI). Het onderliggende CA-certificaat wordt vervolgens gebruikt om clientcertificaten te ondertekenen voor het testen van uw apparaten.

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

    U wordt gevraagd om de wachtwoordzin in te voeren, zoals wordt weergegeven in het volgende voorbeeld voor het persoonlijke-sleutelbestand van uw basis-CA. Nadat u de wachtwoordzin hebt ingevoerd, genereert En geeft OpenSSL de details van het certificaat weer. Vervolgens wordt u gevraagd het certificaat voor uw onderliggende CA te ondertekenen en door te voeren. Geef y op voor beide prompts om het certificaat voor uw onderliggende CA te genereren.

    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
Database updated

    Nadat OpenSSL de certificaatdatabase heeft bijgewerkt, controleert u of het certificaatbestand subca.crt aanwezig is in de onderliggende CA-map. Controleer vervolgens of het PEM-certificaatbestand (.pem) voor het certificaat aanwezig is in de rootca/certs map. De bestandsnaam van het PEM-bestand komt overeen met het serienummer van het onderliggende CA-certificaat.

Uw onderliggende CA-certificaat registreren bij uw IoT-hub

Registreer het onderliggende CA-certificaat bij uw IoT-hub, die het gebruikt om uw apparaten te verifiëren tijdens de registratie en verbinding. In de volgende stappen wordt beschreven hoe u uw onderliggende CA-certificaat uploadt en automatisch verifieert naar uw IoT-hub.

  1. Navigeer in Azure Portal naar uw IoT-hub en selecteer Certificaten in het resourcemenu onder Beveiligingsinstellingen.

  2. Selecteer Toevoegen op de opdrachtbalk om een nieuw CA-certificaat toe te voegen.

  3. Voer een weergavenaam in voor uw onderliggende CA-certificaat in het veld Certificaatnaam .

  4. Selecteer het PEM-certificaat (.pem) bestand van uw onderliggende CA-certificaat uit de rootca/certs map om toe te voegen aan het veld Certificaat .pem of .cer bestand.

  5. Schakel het selectievakje in naast De certificaatstatus instellen op geverifieerd bij uploaden.

    Schermopname van het automatisch verifiëren van de certificaatstatus bij uploaden.

  6. Selecteer Opslaan.

Het geüploade onderliggende CA-certificaat wordt weergegeven met de status ingesteld op Geverifieerd op het tabblad Certificaten van het werkvenster.

Een clientcertificaat voor een apparaat maken

Nadat u uw onderliggende CA hebt gemaakt, kunt u clientcertificaten voor uw apparaten maken. De bestanden en mappen die voor uw onderliggende CA zijn gemaakt, worden gebruikt om de CSR-, persoonlijke sleutel- en certificaatbestanden voor uw clientcertificaten op te slaan.

Het clientcertificaat moet de waarde van het veld Algemene naam onderwerp (CN) hebben ingesteld op de waarde van de apparaat-id die wordt gebruikt bij het registreren van het bijbehorende apparaat in Azure IoT Hub.

Voer de volgende stappen uit om:

  • Een persoonlijke sleutel en aanvraag voor certificaatondertekening (CSR) maken voor een clientcertificaat
  • Een clientcertificaat maken dat is ondertekend door uw onderliggende CA-certificaat

  1. Controleer in het Git Bash-venster of u zich nog in de subca map bevindt.

  2. Voer in het Git Bash-venster de volgende opdrachten één voor één uit. Vervang bijvoorbeeld de tijdelijke aanduiding door een naam voor uw IoT-apparaat testdevice. Met deze stap maakt u de persoonlijke sleutel en CSR voor uw clientcertificaat.

    Met deze stap maakt u een 2048-bits RSA-persoonlijke sleutel voor uw clientcertificaat en genereert u vervolgens een aanvraag voor certificaatondertekening (CSR) met die persoonlijke sleutel.

    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. Geef desgevraagd certificaatgegevens op, zoals wordt weergegeven in het volgende voorbeeld.

    De enige vraag waarvoor u een specifieke waarde moet opgeven, is de algemene naam, die dezelfde apparaatnaam moet hebben als in de vorige stap. U kunt voor de rest van de prompts willekeurige waarden opgeven of overslaan.

    Nadat u de certificaatgegevens hebt opgegeven, genereert En geeft OpenSSL de details van het certificaat weer. Vervolgens wordt u gevraagd het certificaat voor uw onderliggende CA te ondertekenen en door te voeren. Geef y op voor beide prompts om het certificaat voor uw onderliggende CA te genereren.

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

    Controleer of het CSR-bestand aanwezig is in de onderliggende CA-directory. Controleer vervolgens of het bestand met de persoonlijke sleutel aanwezig is in de private submap voordat u doorgaat. Zie X.509-certificaten voor meer informatie over de indelingen van de CSR- en persoonlijke-sleutelbestanden.

  4. Voer in het Git Bash-venster de volgende opdracht uit, waarbij u de tijdelijke aanduidingen voor de apparaatnaam vervangt door dezelfde naam die u in de vorige stappen hebt gebruikt.

    Met deze stap maakt u een clientcertificaat in de onderliggende CA-map. Met de opdracht worden de client_ext configuratiebestandsextensies toegepast op het certificaat. Deze extensies geven aan dat het certificaat voor een clientcertificaat is, dat niet kan worden gebruikt als een CA-certificaat. Het clientcertificaat is ondertekend met het onderliggende CA-certificaat.

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

    U wordt gevraagd om de wachtwoordzin in te voeren, zoals wordt weergegeven in het volgende voorbeeld, voor het bestand met de persoonlijke sleutel van uw onderliggende CA. Nadat u de wachtwoordzin hebt ingevoerd, genereert OpenSSL de details van het certificaat en wordt u gevraagd om het clientcertificaat voor uw apparaat te ondertekenen en door te voeren. Geef y op voor beide prompts om het clientcertificaat te genereren.

    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
Database updated

    Nadat OpenSSL de certificaatdatabase heeft bijgewerkt, controleert u of het certificaatbestand voor het clientcertificaat aanwezig is in de onderliggende CA-map. Controleer vervolgens of het PEM-certificaatbestand (.pem) voor het clientcertificaat aanwezig is in de submap certificaten van de onderliggende CA-map. De bestandsnaam van het PEM-bestand komt overeen met het serienummer van het clientcertificaat.

Volgende stappen

U kunt uw apparaat registreren bij uw IoT-hub voor het testen van het clientcertificaat dat u voor dat apparaat hebt gemaakt. Zie Apparaatidentiteiten maken en beheren voor meer informatie over het registreren van een apparaat.

Als u meerdere gerelateerde apparaten hebt om te testen, kunt u azure IoT Hub Device Provisioning Service gebruiken om meerdere apparaten in te richten in een inschrijvingsgroep. Zie zelfstudie: Meerdere X.509-apparaten inrichten met behulp van inschrijvingsgroepen voor meer informatie over het gebruik van inschrijvingsgroepen in Device Provisioning Service.