Compartilhar via

Tutorial: criar e carregar os 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 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 à AC raiz interna, com certificados de cliente para seus dispositivos assinados por suas ACs subordinadas, permite a simulação de 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 o 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. Você precisará usar as melhores práticas para a criação de certificados e o gerenciamento do tempo de vida em um ambiente de produção. Para obter mais informações, veja Como gerenciar certificados de AC de teste para ver amostras e tutoriais no repositório GitHub do 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 ele já esteja 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 você pode baixar o OpenSSL predefinido de um parceiro que não seja da Microsoft. Para saber mais, consulte o wiki do OpenSSL. A Microsoft não garante a validade dos pacotes baixados de terceiros. Se você optar por criar ou baixar o OpenSSL, verifique se o binário OpenSSL está acessível em seu caminho e se a OPENSSL_CNF variável de ambiente está definida como o caminho do arquivo openssl.cnf .

Criar uma autoridade de certificação 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 autoridade de certificação 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 aos certificados de autoridades de certificação raiz, aos certificados de AC subordinada e aos certificados do cliente emitidos pela autoridade de certificação 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

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

    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 rootca.csrCSR está presente no rootca diretório. Em seguida, confirme se o arquivo rootca.keyde chave privada está presente no private subdiretório antes de continuar.

  5. Na janela do Git Bash, execute o comando a seguir 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 autoridade de certificação 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 nos dois prompts para gerar o certificado autoassinado para a 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
Database 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 autoridade de certificação raiz.

Criar uma autoridade de certificação subordinada

Depois de criar sua AC raiz interna, você deve criar uma AC subordinada para usar como uma AC intermediária com a qual assinar certificados de 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 certificados de confiança, consulte Autenticar identidades com certificados 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. Execute as etapas a seguir para:

  • Criar e inicializar as pastas e os arquivos utilizados pela AC 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ório e arquivos de suporte para a AC subordinada que é semelhante à estrutura de pastas e arquivos criados para a AC 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 subca.csr de CSR está presente no diretório da AC subordinada. Em seguida, confirme se o arquivo subca.key de chave privada está presente no private subdiretório antes de continuar.

  5. Na janela do Git Bash, execute o comando a seguir 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ê precisará inserir a frase secreta, conforme mostrado no exemplo a seguir, para o arquivo de chave privada da 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 nos dois prompts para gerar o certificado para a AC 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
Database updated

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

Registre o certificado de AC subordinada no hub IoT

Registre o certificado da AC subordinada no hub IoT, que o utilizará 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. Insira um nome de exibição para o certificado da AC subordinada no campo Nome do certificado.

  4. Selecione o arquivo de certificado PEM (.pem) do 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.

    Captura de tela que mostra como verificar automaticamente o status do certificado no upload.

  6. Clique em Salvar.

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

Criar um certificado do cliente para um dispositivo

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

O certificado do cliente precisa ter o valor do 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.

Execute as etapas a seguir para:

  • Crie uma chave privada e uma solicitação de assinatura de certificado (CSR) para um certificado do cliente
  • Criar um certificado do cliente assinado pelo certificado de AC 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 nos dois prompts para gerar o certificado para a AC 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 Certificadora Subordinada. Em seguida, confirme se o arquivo de chave privada está presente no private subdiretório 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 do 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ê precisará inserir a frase secreta, conforme mostrado no exemplo a seguir, para o arquivo de chave privada da AC 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 nos dois 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
Database updated

    Depois que o OpenSSL atualizar o banco de dados de certificados, confirme se o arquivo do certificado do cliente está presente no diretório da AC subordinada. Em seguida, confirme se o arquivo de certificado PEM (.pem) do certificado do cliente está presente no subdiretório de certificados do diretório de AC subordinado. 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 no 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.

  • Last updated on