Compartilhar via


Tutorial: Criar e carregar certificados para teste

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

No entanto, criar sua própria AC privada autogerenciada que usa uma autoridade de certificação raiz interna como âncora de confiança é adequado para ambientes de teste. Uma AC privada autogerenciada com pelo menos uma AC subordinada encadeada à sua AC raiz interna, com certificados do 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 Guia do OpenSSL para descrever como realizar as seguintes tarefas:

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

Observação

A Microsoft fornece scripts do PowerShell e do Bash para ajudar você 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 do dispositivo 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. Eles contêm senhas embutidas em código (“1234”) e expiram após 30 dias. Para um ambiente de produção, você precisará usar suas melhores práticas para a criação de certificados e o gerenciamento do tempo de vida. Para obter mais informações, consulte Gerenciando certificados de AC de teste para amostras e tutoriais no repositório GitHub para o SDK do dispositivo Hub IoT do Azure para C.

Pré-requisitos

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

  • Um Hub IoT na assinatura do Azure. Caso você ainda não tenha um hub, poderá seguir as etapas em Criar um hub IoT.

  • A versão mais recente do Git. Verifique se o Git foi adicionado às variáveis de ambiente que podem ser acessadas pela janela de comando. Confira Ferramentas de cliente Git do Software Freedom Conservancy para obter a versão mais recente das ferramentas git a serem instaladas, que inclui o Git Bash, o aplicativo de linha de comando que você pode usar para interagir com seu repositório Git local.

  • Uma instalação do OpenSSL. No Windows, a instalação do Git inclui uma instalação do OpenSSL. É possível acessar o OpenSSL no prompt do Git Bash. Para verificar se o OpenSSL está instalado, abra um prompt do Git Bash e insira openssl version.

    Observação

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

Criar uma AC raiz

Você deve primeiro criar uma autoridade de certificação raiz interna (CA) e um certificado de AC raiz autoassinado para servir como uma âncora de confiança a partir da qual você pode criar outros certificados para teste. Os arquivos utilizados para criar e manter sua AC raiz interna são armazenados em uma estrutura de pastas e inicializados como parte desse processo. Execute as etapas a seguir para:

  • Criar e inicializar as pastas e os arquivos usados pela AC raiz
  • Crie um arquivo de configuração usado pelo OpenSSL para configurar sua AC raiz e os certificados criados com sua AC raiz
  • Solicite e crie um certificado de AC autoassinado que sirva como seu certificado de AC raiz
  1. Inicie uma janela do Git Bash e execute o seguinte comando, substituindo {base_dir} pelo diretório desejado para 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 AC raiz.

    Diretório ou arquivo Descrição
    rootca O diretório raiz da autoridade de certificação raiz.
    rootca/certs O diretório no qual os certificados da AC para a AC 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 AC raiz são armazenados.
    rootca/db/index O banco de dados de certificados da autoridade de certificação raiz. O comando touch cria um arquivo sem conteúdo, para uso futuro. O banco de dados de certificados é um arquivo de texto simples gerenciado pelo OpenSSL que contém informações sobre os certificados emitidos. Para obter mais informações sobre o banco de dados de certificados, confira a página do manual openssl-ca.
    rootca/db/serial Um arquivo utilizado para armazenar o número de série do próximo certificado a ser criado para a AC raiz. O comando openssl cria um número aleatório de 16 bytes em formato hexadecimal e, em seguida, o armazena nesse arquivo para inicializar o arquivo para criar o certificado AC raiz.
    rootca/db/crlnumber Um arquivo usado para armazenar números de série de certificados revogados emitidos pela autoridade de certificação raiz. O comando echo envia um exemplo de número de série, 1001, para o arquivo.
    rootca/private O diretório no qual os arquivos privados da AC raiz, incluindo a chave privada, são armazenados.
    Os arquivos desse diretório devem estar seguros 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 chamado rootca.conf no diretório rootca 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 a AC raiz de teste. Para este exemplo, o arquivo configura uma AC raiz chamada rootca utilizando os diretórios e arquivos criados nas etapas anteriores. O arquivo também fornece definições de configuração para:

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

    Observação

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

    Para obter mais informações sobre a sintaxe dos arquivos de configuração do OpenSSL, confira a página do manual config 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 diretório rootca e uma chave privada no diretório rootca/private. Para obter mais informações sobre o comando OpenSSL req, consulte a página do manual openssl-req na documentação do OpenSSL.

    Observação

    Embora essa autoridade de certificação raiz seja para fins de teste e não seja exposta como parte de uma infraestrutura de chave pública (PKI), 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 frase secreta PEM, como mostrado no exemplo a seguir, para o arquivo da chave privada. Insira e confirme uma frase secreta para gerar sua chave privada e a CSR.

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

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

  5. Na janela do Git Bash, execute o seguinte comando para criar um certificado de autoridade de certificação raiz autoassinado. O comando aplica as extensões do arquivo de configuração ca_ext do certificado. Essas extensões indicam que o certificado se destina a uma AC raiz e que ele pode ser usado para assinar certificados e CRLs (listas de certificados revogados). Para obter mais informações sobre o comando OpenSSL ca, confira a página do manual 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 frase secreta do 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 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 AC 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
    

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

Criar uma autoridade de certificação subordinada

Depois de criar sua autoridade de certificação raiz interna, você deve criar uma autoridade de certificação subordinada para usar como uma autoridade de certificação intermediária com a qual assinar os certificados do cliente para seus dispositivos. Em teoria, você não precisa criar uma AC subordinada; você pode carregar seu certificado de AC raiz no seu hub de IoT e assinar os certificados do cliente diretamente da sua AC raiz. No entanto, o uso de uma autoridade de certificação subordinada como uma autoridade de certificação intermediária para assinar os certificados do 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 assinar dispositivos em uma cadeia de certificação de confiança, confira Autenticar dispositivos usando certificados X.509 da AC.

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. Execute as etapas a seguir para:

  • Criar e inicializar as pastas e os arquivos utilizados pela autoridade de certificação subordinada
  • Crie um arquivo de configuração usado pelo OpenSSL para configurar a AC subordinada e os certificados criados com sua AC subordinada
  • Solicitar e criar um certificado de AC assinado pela sua autoridade de certificação raiz que sirva como seu certificado de AC subordinada
  1. Retorne ao diretório base que contém o diretório rootca. Neste exemplo, a AC raiz e a AC 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 aos 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 chamado subca.conf no diretório subca 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.

    Tal como acontece com o arquivo de configuração para sua AC raiz de teste, esse arquivo fornece ao OpenSSL os valores necessários para configurar sua AC subordinada de teste. É possível 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, confira a página do manual mestre config 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 do 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 frase secreta PEM, como mostrado no exemplo a seguir, para o arquivo da chave privada. Insira e verifique uma frase secreta para gerar sua chave privada e a CSR.

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

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

  5. Na janela do Git Bash, execute o seguinte comando para criar um certificado de AC subordinada no diretório da AC subordinada. O comando aplica as extensões do arquivo de configuração sub_ca_ext do certificado. Essas extensões indicam que o certificado é para uma autoridade de certificação subordinada e também pode ser usado para assinar certificados e listas de certificados revogados (CRLs). Ao contrário do certificado da AC raiz, esse certificado não é autoassinado. Em vez disso, o certificado da autoridade de certificação subordinada é assinado com o certificado da AC raiz, estabelecendo uma cadeia de certificados semelhante à que você usaria para uma infraestrutura de chave pública (PKI). O certificado da AC subordinada é usado para assinar os certificados do 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 autoridade de certificação 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
    

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

Registre seu certificado de AC subordinada no seu hub IoT

Registre o certificado da AC subordinada no hub IoT, que o utiliza para autenticar dispositivos durante o registro e a conexão. As etapas a seguir descrevem como carregar e verificar automaticamente o certificado da AC subordinada para seu hub IoT.

  1. No portal do Azure, navegue até o 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 AC.

  3. Digite um nome de exibição para seu certificado de AC subordinada no campo Nome do certificado.

  4. Selecione o arquivo de certificado PEM (.pem) do seu certificado da AC subordinada no diretório rootca/certs para adicionar no campo Certificado .pem ou arquivo .cer.

  5. Marque a caixa ao lado de Definir status do certificado para verificado no upload.

    mostrando como verificar automaticamente o status do certificado no upload.

  6. Clique em Salvar.

Seu certificado da AC subordinada carregado é mostrado com seu status definido como Verificado na guia Certificados do painel de trabalho.

Criar um certificado do cliente para um dispositivo

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

O certificado do 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 em Hub IoT do Azure.

Execute as etapas a seguir para:

  • Crie uma chave privada e uma solicitação de assinatura de certificado (CSR) para um certificado do cliente
  • Crie um certificado do cliente assinado pelo seu certificado de autoridade de certificação subordinada
  1. Na janela do Git Bash, verifique se você ainda está no diretório subca.

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

    Esta etapa cria uma chave privada RSA de 2048 bits para seu 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 os detalhes do certificado, conforme mostrado no exemplo a seguir.

    O único prompt para o qual você precisa fornecer um valor específico é o Nome Comum, 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 autoridade de certificação subordinada. Especifique y para ambos os prompts para gerar o certificado para sua autoridade de certificação 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 subdiretório private antes de continuar. Para obter mais informações sobre os formatos dos arquivos CSR e de chave privada, confira Certificados X.509.

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

    Esta etapa cria um certificado do cliente no diretório da autoridade de certificação subordinada. O comando aplica as extensões do arquivo de configuração client_ext do certificado. Essas extensões indicam que o certificado é para um certificado do cliente, que não pode ser usado como um certificado de autoridade de certificação. O certificado do cliente é assinado com o certificado da AC 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 de sua autoridade de certificação subordinada. Depois de inserir a senha, o OpenSSL gera e exibe os detalhes do certificado e, em seguida, solicita que você assine e confirme o certificado do cliente para 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 certificado do cliente está no diretório da AC subordinada e se o arquivo de certificado PEM (.pem) do certificado do cliente está no subdiretório certs do diretório da AC subordinada. O nome de arquivo do arquivo .pem corresponde ao número de série do certificado do cliente.

Próximas etapas

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

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