Partilhar via

Tutorial: Criar e carregar certificados para teste

  • Artigo

Você pode usar certificados X.509 para autenticar dispositivos em seu hub IoT. Para ambientes de produção, recomendamos que você adquira um certificado de autoridade de certificação X.509 de um fornecedor de serviços de certificado profissional. Em seguida, você pode emitir certificados em sua organização a partir de uma autoridade de certificação (CA) interna autogerenciada encadeada ao certificado de autoridade de certificação comprado como parte de uma estratégia abrangente de PKI (infraestrutura de chave pública). Para obter mais informações sobre como obter um certificado de autoridade de certificação X.509 de um fornecedor de serviços de certificado profissional, consulte a seção Obter um certificado de autoridade de certificação X.509 de Autenticar dispositivos usando certificados de autoridade de certificação X.509.

No entanto, criar sua própria autoridade de certificação privada autogerenciada que usa uma autoridade de certificação raiz interna como âncora de confiança é adequada para ambientes de teste. Uma autoridade de certificação privada autogerenciada com pelo menos uma autoridade de certificação subordinada encadeada à sua autoridade de certificação raiz interna, com certificados de cliente para seus dispositivos assinados por suas autoridades de certificação subordinadas, permite simular um ambiente de produção recomendado.

Importante

Não recomendamos o uso de certificados autoassinados para ambientes de produção. Este tutorial é apresentado apenas para fins de demonstração.

O tutorial a seguir usa o OpenSSL e o OpenSSL Cookbook para descrever como realizar as seguintes tarefas:

  • Criar uma autoridade de certificação (CA) raiz interna e um certificado de autoridade de certificação raiz
  • Crie uma autoridade de certificação subordinada interna e um certificado de autoridade de certificação subordinada, assinado pelo certificado de autoridade de certificação raiz interna
  • Carregue seu certificado de CA subordinada para seu hub IoT para fins de teste
  • Use a autoridade de certificação subordinada para criar certificados de cliente para os dispositivos IoT que você deseja testar com seu hub IoT

Nota

A Microsoft fornece scripts PowerShell e Bash para ajudá-lo a entender como criar seus próprios certificados X.509 e autenticá-los em um hub IoT. Os scripts estão incluídos no SDK de Dispositivo do Hub IoT do Azure para C. Os scripts são fornecidos apenas para fins de demonstração. Os certificados criados por eles não devem ser usados para produção. Os certificados contêm senhas codificadas ("1234") e expiram após 30 dias. Você deve usar suas próprias práticas recomendadas para a criação de certificados e o gerenciamento do tempo de vida em um ambiente de produção. Para obter mais informações, consulte Gerenciando certificados de CA de teste para exemplos e tutoriais no repositório GitHub para o SDK de Dispositivo do Hub IoT do Azure para C.

Pré-requisitos

  • Uma subscrição do Azure. Se não tiver uma subscrição do Azure, crie uma conta gratuita antes de começar.

  • Um hub IoT em sua assinatura do Azure. Se você ainda não tiver um hub, siga as etapas em Criar um hub IoT.

  • A última versão do Git. Certifique-se de que o Git é adicionado às variáveis de ambiente acessíveis à janela de comando. Consulte as ferramentas de cliente Git da Software Freedom Conservancy para obter a versão mais recente das ferramentas a serem instaladas, que inclui o Git Bash, o aplicativo de linha de git comando que você pode usar para interagir com seu repositório Git local.

  • Uma instalação OpenSSL . No Windows, sua instalação do Git inclui uma instalação do OpenSSL. Você pode acessar o OpenSSL a partir do prompt do Git Bash. Para verificar se o OpenSSL está instalado, abra um prompt do Git Bash e digite openssl version.

    Nota

    A menos que você esteja familiarizado com o OpenSSL e já o tenha instalado em sua máquina Windows, recomendamos usar o OpenSSL no prompt do Git Bash. Como alternativa, você pode optar por baixar o código-fonte e construir OpenSSL. Para saber mais, consulte a página Downloads do OpenSSL. Ou, você pode baixar OpenSSL pré-construído de terceiros. Para saber mais, consulte o wiki do OpenSSL. A Microsoft não garante a validade de pacotes baixados de terceiros. Se você optar por construir ou baixar o OpenSSL, certifique-se de que o binário OpenSSL esteja acessível em seu caminho e que a OPENSSL_CNF variável de ambiente esteja definida como o caminho do arquivo openssl.cnf .

Criar uma autoridade de certificação raiz

Primeiro, você deve criar uma autoridade de certificação (CA) raiz interna e um certificado de autoridade de certificação raiz autoassinado para servir como uma âncora de confiança a partir da qual você pode criar outros certificados para teste. Os arquivos usados para criar e manter sua autoridade de certificação raiz interna são armazenados em uma estrutura de pastas e inicializados como parte desse processo. Efetue os seguintes passos:

  • Crie e inicialize as pastas e arquivos usados pela autoridade de certificação raiz
  • Crie um arquivo de configuração usado pelo OpenSSL para configurar sua autoridade de certificação raiz e certificados criados com sua autoridade de certificação raiz
  • Solicite e crie um certificado de autoridade de certificação autoassinado que sirva como seu certificado de autoridade de certificação raiz

  1. Inicie uma janela do Git Bash e execute o seguinte comando, substituindo {base_dir} pelo diretório desejado no qual criar os certificados neste tutorial.

    cd {base_dir}

  2. Na janela do Git Bash, execute os seguintes comandos, um de cada vez. Esta etapa cria a seguinte estrutura de diretórios e arquivos de suporte para a autoridade de certificação raiz.

    Diretório ou arquivo Description
    Rootca O diretório raiz da autoridade de certificação raiz.
    ROOTCA/CERTS O diretório no qual os certificados de autoridade de certificação para a autoridade de certificação raiz são criados e armazenados.
    ROOTCA/DB O diretório no qual o banco de dados de certificados e os arquivos de suporte para a autoridade de certificação raiz são armazenados.
    rootca/db/índice O banco de dados de certificados para a autoridade de certificação raiz. O touch comando cria um arquivo sem qualquer conteúdo, para uso posterior. O banco de dados de certificados é um arquivo de texto simples gerenciado pelo OpenSSL que contém informações sobre certificados emitidos. Para obter mais informações sobre o banco de dados de certificados, consulte a página de manual do openssl-ca .
    rootca/db/série Um arquivo usado para armazenar o número de série do próximo certificado a ser criado para a autoridade de certificação raiz. O openssl comando cria um número aleatório de 16 bytes em formato hexadecimal e, em seguida, armazena-o neste arquivo para inicializar o arquivo para criar o certificado de autoridade de certificação raiz.
    rootca/db/crlnumber Um arquivo usado para armazenar números de série para certificados revogados emitidos pela autoridade de certificação raiz. O echo comando canaliza um número de série de exemplo, 1001, para o arquivo.
    rootca/privado O diretório no qual os arquivos privados para a autoridade de certificação raiz, incluindo a chave privada, são armazenados.
    Os arquivos neste diretório devem ser protegidos e protegidos.    		 
    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. Crie um arquivo de texto nomeado rootca.conf no rootca diretório que foi criado na etapa anterior. Abra esse arquivo em um editor de texto e, em seguida, copie e salve as seguintes definições de configuração do OpenSSL nesse arquivo.

    O arquivo fornece ao OpenSSL os valores necessários para configurar sua CA raiz de teste. Neste exemplo, o arquivo configura uma autoridade de certificação raiz chamada rootca usando os diretórios e arquivos criados nas etapas anteriores. O arquivo também fornece definições de configuração para:

    • A política de autoridade de certificação usada pela autoridade de certificação raiz para campos DN (Nome Distinto) do certificado
    • Solicitações de certificado criadas pela autoridade de certificação raiz
    • Extensões X.509 aplicadas a certificados de autoridade de certificação raiz, certificados de autoridade de certificação subordinada e certificados de cliente emitidos pela autoridade de certificação raiz

    Nota

    O home atributo, na ca_default seção , é definido como ../rootca porque esse arquivo de configuração também é usado ao criar o certificado para sua CA subordinada. O caminho relativo especificado permite que o OpenSSL navegue da pasta da autoridade de certificação subordinada para a pasta da autoridade de certificação raiz durante esse processo.

    Para obter mais informações sobre a sintaxe dos arquivos de configuração do OpenSSL, consulte a página de manual de configuração na documentação do 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. Na janela Git Bash, execute o seguinte comando para gerar uma solicitação de assinatura de certificado (CSR) no rootca diretório e uma chave privada no rootca/private diretório. Para obter mais informações sobre o comando OpenSSLreq, consulte a página de manual do openssl-req na documentação do OpenSSL.

    Nota

    Embora essa autoridade de certificação raiz seja para fins de teste e não seja exposta como parte de uma PKI (infraestrutura de chave pública), recomendamos que você não copie ou compartilhe a chave privada.

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

    Você será solicitado a inserir uma senha PEM, conforme mostrado no exemplo a seguir, para o arquivo de chave privada. Introduza e confirme uma frase secreta para gerar a sua chave privada e CSR.

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

    Confirme se o arquivo CSR, rootca.csr, está presente no rootca diretório e o arquivo de chave privada, rootca.key, está presente no private subdiretório antes de continuar.

  5. Na janela Git Bash, execute o seguinte comando para criar um certificado de autoridade de certificação raiz autoassinado. O comando aplica as extensões do ca_ext arquivo de configuração ao certificado. Essas extensões indicam que o certificado é para uma autoridade de certificação raiz e pode ser usado para assinar certificados e listas de revogação de certificados (CRLs). Para obter mais informações sobre o comando OpenSSLca, consulte a página de manual do openssl-ca na documentação do OpenSSL.

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

    Você será solicitado a fornecer a senha PEM, conforme mostrado no exemplo a seguir, para o arquivo de chave privada. Depois de fornecer a frase secreta, o OpenSSL gera um certificado e, em seguida, solicita que você assine e confirme o certificado para sua autoridade de certificação raiz. Especifique y para ambos os prompts para gerar o certificado autoassinado para sua autoridade de certificação raiz.

    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

    Depois que o OpenSSL atualizar o banco de dados de certificados, confirme se o arquivo de certificado, rootca.crt, está presente no diretório e se o rootca arquivo de certificado PEM (.pem) do certificado está presente no rootca/certs diretório. O nome do arquivo .pem corresponde ao número de série do certificado da autoridade de certificação raiz.

Criar uma autoridade de certificação subordinada

Depois de criar sua CA raiz interna, você deve criar uma CA subordinada para usar como uma CA intermediária com a qual assinar certificados de cliente para seus dispositivos. Em teoria, você não precisa criar uma autoridade de certificação subordinada; você pode carregar seu certificado de CA raiz para seu hub IoT e assinar certificados de cliente diretamente de sua CA raiz. No entanto, usar uma autoridade de certificação subordinada como uma autoridade de certificação intermediária para assinar certificados de cliente simula mais de perto um ambiente de produção recomendado, no qual sua autoridade de certificação raiz é mantida offline. Você também pode usar uma autoridade de certificação subordinada para assinar outra autoridade de certificação subordinada, que, por sua vez, pode assinar outra autoridade de certificação subordinada e assim por diante. O uso de autoridades de certificação subordinadas para assinar outras autoridades de certificação subordinadas cria uma hierarquia de autoridades de certificação intermediárias como parte de uma cadeia de confiança de certificados. Em um ambiente de produção, a cadeia de confiança de certificados permite uma delegação de confiança para dispositivos de assinatura. Para obter mais informações sobre como conectar dispositivos em uma cadeia de confiança de certificados, consulte Autenticar dispositivos usando certificados de autoridade de certificação X.509.

Semelhante à sua autoridade de certificação raiz, os arquivos usados para criar e manter sua autoridade de certificação subordinada são armazenados em uma estrutura de pastas e inicializados como parte desse processo. Efetue os seguintes passos:

  • Criar e inicializar as pastas e arquivos usados pela autoridade de certificação subordinada
  • Crie um arquivo de configuração usado pelo OpenSSL para configurar sua CA subordinada e certificados criados com sua CA subordinada
  • Solicite e crie um certificado de autoridade de certificação assinado pela autoridade de certificação raiz que sirva como certificado de autoridade de certificação subordinada

  1. Retorne ao diretório base que contém o rootca diretório. Neste exemplo, tanto a autoridade de certificação raiz quanto a autoridade de certificação subordinada residem no mesmo diretório base.

    cd ..

  2. Na janela do Git Bash, execute os seguintes comandos, um de cada vez.

    Esta etapa cria uma estrutura de diretórios e arquivos de suporte para a autoridade de certificação subordinada semelhante à estrutura de pastas e arquivos criados para a autoridade de certificação raiz na seção anterior.

    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. Crie um arquivo de texto nomeado subca.conf no subca diretório que foi criado na etapa anterior. Abra esse arquivo em um editor de texto e, em seguida, copie e salve as seguintes definições de configuração do OpenSSL nesse arquivo.

    Assim como o arquivo de configuração para sua CA raiz de teste, esse arquivo fornece ao OpenSSL os valores necessários para configurar sua CA subordinada de teste. Você pode criar várias autoridades de certificação subordinadas para gerenciar cenários ou ambientes de teste.

    Para obter mais informações sobre a sintaxe dos arquivos de configuração do OpenSSL, consulte a página do manual mestre de configuração na documentação do 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. Na janela Git Bash, execute os seguintes comandos para gerar uma chave privada e uma solicitação de assinatura de certificado (CSR) no diretório da autoridade de certificação subordinada.

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

    Você será solicitado a inserir uma senha PEM, conforme mostrado no exemplo a seguir, para o arquivo de chave privada. Insira e verifique uma frase secreta para gerar sua chave privada e CSR.

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

    Confirme se o arquivo subca.csr CSR está presente no diretório da autoridade de certificação subordinada e se o arquivo subca.key de chave privada está presente no private subdiretório antes de continuar.

  5. Na janela Git Bash, execute o seguinte comando para criar um certificado de autoridade de certificação subordinada no diretório da autoridade de certificação subordinada. O comando aplica as extensões do sub_ca_ext arquivo de configuração ao certificado. Essas extensões indicam que o certificado é para uma CA subordinada e também podem ser usadas para assinar certificados e listas de revogação de certificados (CRLs). Ao contrário do certificado de autoridade de certificação raiz, esse certificado não é autoassinado. Em vez disso, o certificado de autoridade de certificação subordinada é assinado com o certificado de autoridade de certificação raiz, estabelecendo uma cadeia de certificados semelhante à que você usaria para uma infraestrutura de chave pública (PKI). O certificado de autoridade de certificação subordinada é usado para assinar certificados de cliente para testar seus dispositivos.

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

    Você será solicitado a inserir a frase secreta, conforme mostrado no exemplo a seguir, para o arquivo de chave privada da sua autoridade de certificação raiz. Depois de inserir a frase secreta, o OpenSSL gera e exibe os detalhes do certificado e, em seguida, solicita que você assine e confirme o certificado para sua autoridade de certificação subordinada. Especifique y para ambos os prompts para gerar o certificado para sua CA subordinada.

    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

    Depois que o OpenSSL atualizar o banco de dados de certificados, confirme se o arquivo de subca.crt certificado está presente no diretório da autoridade de certificação subordinada e se o arquivo de certificado PEM (.pem) do certificado está presente no rootca/certs diretório. O nome do arquivo .pem corresponde ao número de série do certificado da autoridade de certificação subordinada.

Registrar seu certificado de CA subordinado em seu hub IoT

Registre o certificado de CA subordinado em seu hub IoT, que o usa para autenticar seus dispositivos durante o registro e a conexão. As etapas a seguir descrevem como carregar e verificar automaticamente seu certificado de CA subordinado para seu hub IoT.

  1. No portal do Azure, navegue até seu hub IoT e selecione Certificados no menu de recursos, em Configurações de segurança.

  2. Selecione Adicionar na barra de comandos para adicionar um novo certificado de autoridade de certificação.

  3. Insira um nome para exibição para seu certificado de autoridade de certificação subordinada no campo Nome do certificado .

  4. Selecione o arquivo de certificado PEM (.pem) do seu certificado de autoridade de certificação subordinada no rootca/certs diretório para adicionar no campo Arquivo de certificado .pem ou .cer .

  5. Marque a caixa ao lado de Definir status do certificado como verificado ao carregar.

    Captura de ecrã a mostrar como verificar automaticamente o estado do certificado durante o carregamento.

  6. Selecione Guardar.

O certificado de autoridade de certificação subordinada carregado é mostrado com seu status definido como Verificado na guia Certificados do painel de trabalho.

Criar um certificado de cliente para um dispositivo

Depois de criar sua CA subordinada, você pode criar certificados de cliente para seus dispositivos. Os arquivos e pastas criados para sua CA subordinada são usados para armazenar os arquivos CSR, chave privada e certificado para seus certificados de cliente.

O certificado de cliente deve ter o valor de seu campo CN (Nome Comum da Entidade) definido como o valor da ID do dispositivo usada ao registrar o dispositivo correspondente no Hub IoT do Azure.

Efetue os seguintes passos:

  • Criar uma chave privada e uma solicitação de assinatura de certificado (CSR) para um certificado de cliente
  • Criar um certificado de cliente assinado pelo certificado da autoridade de certificação subordinada

  1. Na janela do Git Bash, verifique se você ainda está no subca diretório.

  2. Na janela do Git Bash, execute os seguintes comandos, um de cada vez. Substitua o espaço reservado por um nome para seu dispositivo IoT, por exemplo testdevice. Esta etapa cria a chave privada e o CSR para o certificado do cliente.

    Esta etapa cria uma chave privada RSA de 2048 bits para o certificado do cliente e, em seguida, gera uma solicitação de assinatura de certificado (CSR) usando essa chave privada.

    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. Quando solicitado, forneça detalhes do certificado conforme mostrado no exemplo a seguir.

    O único prompt para o qual você precisa fornecer um valor específico é o Common Name, que deve ser o mesmo nome de dispositivo fornecido na etapa anterior. Você pode ignorar ou fornecer valores arbitrários para o restante dos prompts.

    Depois de fornecer os detalhes do certificado, o OpenSSL gera e exibe os detalhes do certificado e, em seguida, solicita que você assine e confirme o certificado para sua CA subordinada. Especifique y para ambos os prompts para gerar o certificado para sua CA subordinada.

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

    Confirme se o arquivo CSR está presente no diretório da autoridade de certificação subordinada e se o arquivo de chave privada está presente no private subdiretório antes de continuar. Para obter mais informações sobre os formatos do CSR e arquivos de chave privada, consulte Certificados X.509.

  4. Na janela do Git Bash, execute o seguinte comando, substituindo os espaços reservados do nome do dispositivo pelo mesmo nome usado nas etapas anteriores.

    Esta etapa cria um certificado de cliente no diretório da autoridade de certificação subordinada. O comando aplica as extensões do client_ext arquivo de configuração ao certificado. Essas extensões indicam que o certificado é para um certificado de cliente, que não pode ser usado como um certificado de autoridade de certificação. O certificado do cliente é assinado com o certificado da autoridade de certificação subordinada.

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

    Você será solicitado a inserir a frase secreta, conforme mostrado no exemplo a seguir, para o arquivo de chave privada da autoridade de certificação subordinada. Depois de inserir a frase secreta, o OpenSSL gera e exibe os detalhes do certificado e, em seguida, solicita que você assine e confirme o certificado do cliente para o seu dispositivo. Especifique y para ambos os prompts para gerar o certificado do cliente.

    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

    Depois que o OpenSSL atualizar o banco de dados de certificados, confirme se o arquivo de certificado do cliente está presente no diretório da autoridade de certificação subordinada e se o arquivo de certificado PEM (.pem) do certificado do cliente está presente no subdiretório certs do diretório da autoridade de certificação subordinada. O nome do arquivo .pem corresponde ao número de série do certificado do cliente.

Próximos passos

Você pode registrar seu dispositivo com seu hub IoT para testar o certificado de cliente que você criou para esse dispositivo. Para obter mais informações sobre como registrar um dispositivo, consulte Criar e gerenciar identidades de dispositivo.

Se você tiver vários dispositivos relacionados para testar, poderá usar o Serviço de Provisionamento de Dispositivo do Hub IoT do Azure para provisionar vários dispositivos em um grupo de registro. Para obter mais informações sobre como usar grupos de registro no Serviço de Provisionamento de Dispositivo, consulte Tutorial: Provisionar vários dispositivos X.509 usando grupos de registro.