Tutorial: Criar e carregar certificados para teste

Artigo
04/13/2024

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

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}
```

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

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

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.
- Windows
- Linux
```
winpty openssl req -new -config rootca.conf -out rootca.csr -keyout private/rootca.key
```
```
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.
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.
- Windows
- Linux
```
winpty openssl ca -selfsign -config rootca.conf -in rootca.csr -out rootca.crt -extensions ca_ext
```
```
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

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 ..
```
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
```

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

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.
- Windows
- Linux
```
winpty openssl req -new -config subca.conf -out subca.csr -keyout private/subca.key
```
```
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.
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.
- Windows
- Linux
```
winpty openssl ca -config ../rootca/rootca.conf -in subca.csr -out subca.crt -extensions sub_ca_ext
```
```
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.

No portal do Azure, navegue até o hub IoT e selecione Certificados no menu de recursos, em Configurações de segurança.
Selecione Adicionar na barra de comandos para adicionar um novo certificado de AC.
Digite um nome de exibição para seu certificado de AC subordinada no campo Nome do certificado.
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.
Marque a caixa ao lado de Definir status do certificado para verificado no upload.
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

Na janela do Git Bash, verifique se você ainda está no diretório subca.
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.
- Windows
- Linux
```
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
```
```
openssl genpkey -out private/<DEVICE_NAME>.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048
openssl req -new -key private/<DEVICE_NAME>.key -out <DEVICE_NAME>.csr
```
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.
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.
- Windows
- Linux
```
winpty openssl ca -config subca.conf -in <DEVICE_NAME>.csr -out <DEVICE_NAME>.crt -extensions client_ext
```
```
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.

Compartilhar via