Gerenciar certificados do IoT Edge

Aplica-se a:marca de seleção do IoT Edge 1.4 IoT Edge 1.4

Importante

A versão com suporte é a IoT Edge 1.4. Se você estiver em uma versão anterior, confira Atualizar o IoT Edge.

Todos os dispositivos IoT Edge usam certificados para criar conexões seguras entre o tempo de execução e os módulos em execução no dispositivo. Dispositivos do IoT Edge funcionando como gateways usam esses mesmos certificados para se conectar também aos dispositivos downstream.

Observação

O termo raiz de autoridade de certificação usado, em todo este artigo, refere-se ao certificado de autoridade superior na cadeia de certificados para sua solução de IoT. Você não precisa usar a raiz do certificado de uma autoridade de certificação sindicalizada, ou a raiz da autoridade de certificação da sua organização. Na verdade, ele costuma ser um Certificado de Autoridade de Certificação intermediária.

Pré-requisitos

  • Você deve estar familiarizado com os conceitos descritos em Noções básicas de como o Azure IoT Edge usa certificados, em particular, como o IoT Edge usa certificados.

  • Um dispositivo do IoT Edge.

    Se você não tiver um dispositivo IoT Edge configurado, poderá criar um em uma máquina virtual do Azure. Siga as etapas descritas em um destes artigos de início rápido para Criar um dispositivo virtual do Linux ou Criar um dispositivo virtual do Windows.

  • Capacidade de editar o arquivo config.toml de configuração IoT Edge seguindo o modelo de configuração.

  • Se o seu config.toml não for baseado no modelo, abra o modelo e use as diretrizes comentadas para adicionar seções de configuração seguindo a estrutura do modelo.

  • Se você tiver uma nova instalação do IoT Edge que não foi configurada, copie o modelo para inicializar a configuração. Não use esse comando se você tiver uma configuração existente. Ele substitui o arquivo.

    sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
    

Requisitos de formato

Dica

  • Um certificado pode ser codificado em uma representação binária chamada DER (Distinguished Encoding Rules) ou uma representação textual chamada PEM (Privacy Enhanced Mail). O formato PEM tem um cabeçalho -----BEGIN CERTIFICATE----- seguido pelo DER codificado em Base64 seguido por um rodapé -----END CERTIFICATE-----.
  • Semelhante ao certificado, a chave privada pode ser codificada em DER binário ou PEM de representação textual.
  • Como o PEM está delineado, também é possível construir um PEM que combine CERTIFICATE e PRIVATE KEY sequencialmente no mesmo arquivo.
  • Por fim, o certificado e a chave privada podem ser codificados juntos em uma representação binária chamada PKCS nº 12, criptografada com uma senha opcional.

As extensões de arquivo são arbitrárias e você precisa executar o comando file ou exibir o arquivo para verificar o tipo. Em geral, os arquivos usam as seguintes convenções de extensão:

  • .cer é um certificado no formulário DER ou PEM.
  • .pem é um certificado, uma chave privada ou ambos no formulário PEM.
  • .pfx é um arquivo PKCS#12.

O IoT Edge requer que o certificado e a chave privada sejam:

  • Formato PEM
  • Arquivos separados
  • Na maioria dos casos, com a cadeia completa

Se você receber um arquivo .pfx do provedor PKI, provavelmente o certificado e a chave privada serão codificados juntos em um arquivo. Verifique se é um tipo de arquivo PKCS#12 usando o comando file. Você pode converter um arquivo PKCS#12 .pfx em arquivos PEM usando o comando openssl pkcs12.

Se o provedor PKI fornecer um arquivo .cer, ele poderá conter o mesmo certificado que o .pfx, ou poderá ser o certificado de emissão (raiz) do provedor PKI. Para verificar isso, inspecione o arquivo com o comando openssl x509. Se for o certificado emissor:

  • Se estiver no formato DER (binário), converta-o em PEM com openssl x509 -in cert.cer -out cert.pem.
  • Use o arquivo PEM como o pacote de confiança. Para saber mais sobre o pacote de confiança, confira a próxima seção.

Importante

Sua infraestrutura de PKI deve dar suporte a chaves RSA de 2048 bits e a chaves EC P-256. Por exemplo, seus servidores EST devem dar suporte a esses tipos de chaves. Você pode usar outros tipos de chaves, mas testamos apenas as chaves RSA de 2048 bits e as chaves EC P-256.

Requisitos de permissão

A tabela a seguir lista as permissões de arquivo e diretório necessárias para os certificados IoT Edge. O diretório preferencial para os certificados é /var/aziot/certs/ e /var/aziot/secrets/ para chaves.

Arquivo ou diretório Permissões Proprietário
/var/aziot/certs/ diretório de certificados drwxr-xr-x (755) aziotcs
Arquivos de certificado em /var/aziot/certs/ -wr-r--r-- (644) aziotcs
/var/aziot/secrets/ diretório de chaves drwx------ (700) aziotks
Arquivos de chave em /var/aziot/secrets/ -wr------- (600) aziotks

Para criar os diretórios, defina as permissões e defina o proprietário, execute os seguintes comandos:

# If the certificate and keys directories don't exist, create, set ownership, and set permissions
sudo mkdir -p /var/aziot/certs
sudo chown aziotcs:aziotcs /var/aziot/certs
sudo chmod 755 /var/aziot/certs

sudo mkdir -p /var/aziot/secrets
sudo chown aziotks:aziotks /var/aziot/secrets
sudo chmod 700 /var/aziot/secrets

# Give aziotcs ownership to certificates
# Read and write for aziotcs, read-only for others
sudo chown -R aziotcs:aziotcs /var/aziot/certs
sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \;

# Give aziotks ownership to private keys
# Read and write for aziotks, no permission for others
sudo chown -R aziotks:aziotks /var/aziot/secrets
sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \;

# Verify permissions of directories and files
sudo ls -Rla /var/aziot

A saída da lista com a propriedade e a permissão corretas é semelhante à seguinte:

azureUser@vm:/var/aziot$ sudo ls -Rla /var/aziot
/var/aziot:
total 16
drwxr-xr-x  4 root    root    4096 Dec 14 00:16 .
drwxr-xr-x 15 root    root    4096 Dec 14 00:15 ..
drwxr-xr-x  2 aziotcs aziotcs 4096 Jan 14 00:31 certs
drwx------  2 aziotks aziotks 4096 Jan 23 17:23 secrets

/var/aziot/certs:
total 20
drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 14 00:31 .
drwxr-xr-x 4 root    root    4096 Dec 14 00:16 ..
-rw-r--r-- 1 aziotcs aziotcs 1984 Jan 14 00:24 azure-iot-test-only.root.ca.cert.pem
-rw-r--r-- 1 aziotcs aziotcs 5887 Jan 14 00:27 iot-edge-device-ca-devicename-full-chain.cert.pem

/var/aziot/secrets:
total 16
drwx------ 2 aziotks aziotks 4096 Jan 23 17:23 .
drwxr-xr-x 4 root    root    4096 Dec 14 00:16 ..
-rw------- 1 aziotks aziotks 3243 Jan 14 00:28 iot-edge-device-ca-devicename.key.pem

Gerenciar a AC raiz confiável (pacote de confiança)

O uso de um certificado de AC (autoridade de certificação) autoassinado como uma raiz de confiança com IoT Edge e módulos é conhecido como pacote de confiança. O pacote de confiança está disponível para que o IoT Edge e os módulos se comuniquem com servidores. Para configurar o pacote de confiança, especifique seu caminho de arquivo no arquivo de configuração do IoT Edge.

  1. Obtenha o Certificado de Autoridade de Certificação raiz de um provedor de PKI.

  2. Verifique se o certificado atende aos requisitos de formato.

  3. Copie o arquivo PEM e dê acesso ao certificado do IoT Edge. Por exemplo, com o diretório /var/aziot/certs:

    # Make the directory if doesn't exist
    sudo mkdir /var/aziot/certs -p
    
    # Change cert directory user and group ownership to aziotcs and set permissions
    sudo chown aziotcs:aziotcs /var/aziot/certs
    sudo chmod 755 /var/aziot/certs
    
    # Copy certificate into certs directory
    sudo cp root-ca.pem /var/aziot/certs
    
    # Give aziotcs ownership to certificate and set read and write permission for aziotcs, read-only for others
    sudo chown aziotcs:aziotcs /var/aziot/certs/root-ca.pem
    sudo chmod 644 /var/aziot/certs/root-ca.pem
    
  4. No arquivo de configuração config.toml do IoT Edge, localize a seção Certificado do pacote de relação de confiança. Se a seção estiver ausente, você poderá copiá-la do arquivo de modelo da configuração.

    Dica

    Se o arquivo de configuração ainda não existir no seu dispositivo, use /etc/aziot/config.toml.edge.template como modelo para criar um.

  5. Defina a chave trust_bundle_cert como o local do arquivo de certificado.

    trust_bundle_cert = "file:///var/aziot/certs/root-ca.pem"
    
  6. Aplicar a configuração.

    sudo iotedge config apply
    

Instale a CA raiz no armazenamento de certificados do sistema operacional

A instalação do certificado no arquivo de pacote de confiança o disponibiliza para módulos de contêiner, mas não para hospedar módulos como Atualização de Dispositivo do Azure ou Defender. Se você usar componentes de nível de host ou encontrar outros problemas de TLS, instale também o certificado de autoridade de certificação raiz no repositório de certificados do sistema operacional:

sudo cp /var/aziot/certs/my-root-ca.pem /usr/local/share/ca-certificates/my-root-ca.pem.crt

sudo update-ca-certificates

Importar certificado e arquivos de chave privada

O IoT Edge pode usar arquivos de chave privada e certificados existentes para autenticar ou atestar o Azure, emitir novos certificados de servidor de módulo e autenticar-se em servidores EST. Para instalar:

  1. Verifique se os arquivos de certificado e de chave privada atendem aos requisitos de formato.

  2. Copie o arquivo PEM para o dispositivo IoT Edge ao qual os módulos IoT Edge podem ter acesso. Por exemplo, o diretório /var/aziot/.

    # If the certificate and keys directories don't exist, create, set ownership, and set permissions
    sudo mkdir -p /var/aziot/certs
    sudo chown aziotcs:aziotcs /var/aziot/certs
    sudo chmod 755 /var/aziot/certs
    
    sudo mkdir -p /var/aziot/secrets
    sudo chown aziotks:aziotks /var/aziot/secrets
    sudo chmod 700 /var/aziot/secrets
    
    # Copy certificate and private key into the correct directory
    sudo cp my-cert.pem /var/aziot/certs
    sudo cp my-private-key.pem /var/aziot/secrets
    
  3. Conceda a propriedade do serviço de certificado aziotcs e do serviço de chave aziotks do IoT Edge ao certificado e à chave privada, respectivamente.

    # Give aziotcs ownership to certificate
    # Read and write for aziotcs, read-only for others
    sudo chown aziotcs:aziotcs /var/aziot/certs/my-cert.pem
    sudo chmod 644 /var/aziot/certs/my-cert.pem
    
    # Give aziotks ownership to private key
    # Read and write for aziotks, no permission for others
    sudo chown aziotks:aziotks /var/aziot/secrets/my-private-key.pem
    sudo chmod 600 /var/aziot/secrets/my-private-key.pem
    
  4. Em config.toml, localize a seção relevante para o tipo do certificado a ser configurado. Por exemplo, você pode pesquisar a palavra-chave cert.

  5. Usando o exemplo do modelo de configuração, configure o certificado de identidade do dispositivo ou os arquivos de AC do Edge. O padrão de exemplo é:

    cert = "file:///var/aziot/certs/my-cert.pem"
    pk = "file:///var/aziot/secrets/my-private-key.pem"
    
  6. Aplicar a configuração

    sudo iotedge config apply
    

Para evitar erros quando os certificados expirarem, lembre-se de atualizar manualmente os arquivos e a configuração antes do vencimento do certificado.

Exemplo: usar arquivos de certificado de identidade do dispositivo do provedor PKI

Solicite um certificado de cliente TLS e uma chave privada do provedor PKI.

Requisitos do certificado de identidade do dispositivo:

  • Extensões do certificado do cliente padrão: extendedKeyUsage = clientAuth keyUsage = critical, digitalSignature
  • Identificadores de chave para ajudar a distinguir entre as ACs emissoras com o mesmo CN para a rotação do Certificado de Autoridade de Certificação.
    • subjectKeyIdentifier = hash
    • authorityKeyIdentifier = keyid:always,issuer:always

Verifique se o CN (nome comum) corresponde à ID do dispositivo IoT Edge registrada no Hub IoT ou à ID de registro no DPS. Por exemplo, no certificado de identidade do dispositivo a seguir, Subject: CN = my-device é o campo importante que precisa ter uma correspondência.

Exemplo de certificado de identidade do dispositivo:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 48 (0x30)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = myPkiCA
        Validity
            Not Before: Jun 28 21:27:30 2022 GMT
            Not After : Jul 28 21:27:30 2022 GMT
        Subject: CN = my-device
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:ad:b0:63:1f:48:19:9e:c4:9d:91:d1:b0:b0:e5:
                    ...
                    80:58:63:6d:ab:56:9f:90:4e:3f:dd:df:74:cf:86:
                    04:af
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Subject Key Identifier:
                C7:C2:DC:3C:53:71:B8:42:15:D5:6C:4B:5C:03:C2:2A:C5:98:82:7E
            X509v3 Authority Key Identifier:
                keyid:6E:57:C7:FC:FE:50:09:75:FA:D9:89:13:CB:D2:CA:F2:28:EF:9B:F6

    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:20:3c:d2:db:06:3c:d7:65:b7:22:fe:df:9e:11:5b:
         ...
         eb:da:fc:f1:6a:bf:31:63:db:5a:16:02:70:0f:cf:c8:e2
-----BEGIN CERTIFICATE-----
MIICdTCCAhugAwIBAgIBMDAKBggqhkjOPQQDAjAXMRUwEwYDVQQDDAxlc3RFeGFt
...
354RWw+eLOpQSkTqXxzjmfw/kVOOAQIhANvRmyCQVb8zLPtqdOVRkuva/PFqvzFj
21oWAnAPz8ji
-----END CERTIFICATE-----

Dica

Para testar sem acesso a arquivos de certificado fornecidos por uma PKI, confira Criar certificados de demonstração para testar recursos do dispositivo a fim de gerar um certificado de identidade de dispositivo de curta duração e uma chave privada que não sejam de produção.

Exemplo de configuração ao provisionar com o Hub IoT:

[provisioning]
source = "manual"
# ...
[provisioning.authentication]
method = "x509"

identity_cert = "file:///var/aziot/device-id.pem"
identity_pk = "file:///var/aziot/device-id.key.pem"

Exemplo de configuração ao provisionar com o DPS:

[provisioning]
source = "dps"
# ...
[provisioning.attestation]
method = "x509"
registration_id = "my-device"

identity_cert = "file:///var/aziot/device-id.pem"
identity_pk = "file:///var/aziot/device-id.key.pem"

A sobrecarga com o gerenciamento manual de certificados pode ser arriscada e propensa a erros. Na produção, é recomendável usar o IoT Edge com o gerenciamento automático de certificados.

Gerenciar AC do Edge

A AC do Edge tem dois modos diferentes:

  • Início Rápido é o comportamento padrão. O início rápido é para teste e não é adequado à produção.
  • O modo de Produção exige que você forneça sua própria origem para o certificado de AC do Edge e a chave privada.

AC do Edge de Início Rápido

Para ajudar a começar, o IoT Edge gera automaticamente um certificado de AC do Edge quando iniciado pela primeira vez por padrão. Esse certificado autoassinado destina-se apenas a cenários de desenvolvimento e teste, não à produção. Por padrão, o certificado expira após 90 dias. O vencimento pode ser configurado. Esse comportamento é chamado de AC do Edge de Início Rápido.

A AC do Edge de Início Rápido permite que o edgeHub e outros módulos do IoT Edge tenham um certificado de servidor válido quando o IoT Edge é instalado pela primeira vez sem configuração. O certificado é necessário ao edgeHub porque os módulos ou dispositivos downstream precisam estabelecer canais de comunicação seguros. Sem a AC do Edge de Início Rápido, começar seria significativamente mais difícil porque você precisaria fornecer um certificado de servidor válido de um provedor PKI ou com ferramentas como openssl.

Importante

Nunca use a AC do Edge de início rápido na produção porque o certificado gerado localmente nele não está conectado a uma PKI.

A segurança de uma identidade baseada em certificados deriva de uma PKI bem operada (a infraestrutura) na qual o certificado (um documento) é apenas um componente. Uma PKI bem operada permite que a definição, o a aplicação, o gerenciamento e as imposição de políticas de segurança incluam, dentre outras, a emissão, a revogação e o gerenciamento do ciclo de vida de certificados.

Personalizar o tempo de vida da AC do Edge de início rápido

Para configurar a expiração do certificado para algo diferente do padrão de 90 dias, adicione o valor em dias à seção certificado CA do Edge (Início Rápido) do arquivo de configuração.

[edge_ca]
auto_generated_edge_ca_expiry_days = 180

Exclua o conteúdo das pastas /var/lib/aziot/certd/certs e /var/lib/aziot/keyd/keys para remover todos os certificados gerados anteriormente e aplique a configuração.

Renovar a AC do Edge de início rápido

Por padrão, o IoT Edge renova automaticamente o Certificado de Autoridade de Certificação do Edge de início rápido em 80% do tempo de vida do certificado. Por exemplo, se o certificado tem tempo de vida de 90 dias, o IoT Edge regenera automaticamente o Certificado de Autoridade de Certificação do Edge após 72 dias da emissão.

Para alterar a lógica de renovação automática, adicione as configurações a seguir à seção Certificado de autoridade de certificação do Edge em config.toml. Por exemplo:

[edge_ca.auto_renew]
rotate_key = true
threshold = "70%"
retry = "2%"

AC do Edge em produção

Depois de migrar para um cenário de produção, ou se quiser criar um dispositivo de gateway, você não poderá mais usar a AC do Edge de início rápido.

Uma opção é fornecer seus próprios certificados e gerenciá-los manualmente. No entanto, para evitar o processo de gerenciamento manual de certificados arriscado e propenso a erros, use um servidor EST sempre que possível.

Cuidado

O CN (nome comum) do Certificado de Autoridade de Certificação do Edge não pode corresponder ao parâmetro de nome do host do dispositivo definido no arquivo de configuração do dispositivo config.toml ou na identidade do dispositivo registrada no Hub IoT.

Planejar a renovação da AC do Edge

Quando o certificado de Autoridade de Certificação do Edge é renovado, todos os certificados emitidos como certificados de servidor de módulo são regenerados. Para fornecer aos módulos novos certificados de servidor, o IoT Edge reinicia todos os módulos quando o certificado de AC do Edge é renovado.

Para minimizar possíveis efeitos negativos das reinicializações de módulo, planeje renovar o certificado de AC do Edge em um momento específico (por exemplo, threshold = "10d") e notifique os dependentes da solução sobre o tempo de inatividade.

Exemplo: usar arquivos de certificado de AC do Edge de um provedor PKI

Solicite os seguintes arquivos ao provedor PKI:

  • O certificado de AC raiz do PKI
  • Um certificado de emissão/AC e uma chave privada associada

Para que o certificado de AC emissor se torne a AC do Edge, ele deve ter estas extensões:

subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, digitalSignature, keyCertSign

Exemplo do certificado de AC do Edge resultante:

openssl x509 -in my-edge-ca-cert.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4098 (0x1002)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = myPkiCA
        Validity
            Not Before: Aug 27 00:00:50 2022 GMT
            Not After : Sep 26 00:00:50 2022 GMT
        Subject: CN = my-edge-ca.ca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:e1:cb:9c:c0:41:d2:ee:5d:8b:92:f9:4e:0d:3e:
                    ...
                    25:f5:58:1e:8c:66:ab:d1:56:78:a5:9c:96:eb:01:
                    e4:e3:49
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                FD:64:48:BB:41:CE:C1:8A:8A:50:9B:2B:2D:6E:1D:E5:3F:86:7D:3E
            X509v3 Authority Key Identifier:
                keyid:9F:E6:D3:26:EE:2F:D7:84:09:63:84:C8:93:72:D5:13:06:8E:7F:D1
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign
    Signature Algorithm: sha256WithRSAEncryption
         20:c9:34:41:a3:a4:8e:7c:9c:6e:17:f5:a6:6f:e5:fc:6e:59:
         ...
         7c:20:5d:e5:51:85:4c:4d:f7:f8:01:84:87:27:e3:76:65:47:
         9e:6a:c3:2e:1a:f0:dc:9d
-----BEGIN CERTIFICATE-----
MIICdTCCAhugAwIBAgIBMDAKBggqhkjOPQQDAjAXMRUwEwYDVQQDDAxlc3RFeGFt
...
354RWw+eLOpQSkTqXxzjmfw/kVOOAQIhANvRmyCQVb8zLPtqdOVRkuva/PFqvzFj
21oWAnAPz8ji
-----END CERTIFICATE-----

Depois de receber os arquivos mais recentes, atualize o pacote de confiança:

trust_bundle_cert = "file:///var/aziot/root-ca.pem"

Em seguida, configure o IoT Edge para usar o certificado e os arquivos de chave privada:

[edge_ca]
cert = "file:///var/aziot/my-edge-ca-cert.pem"
pk = "file:///var/aziot/my-edge-ca-private-key.key.pem"

Se você já usou outros certificados para o IoT Edge no dispositivo antes, exclua os arquivos em /var/lib/aziot/certd/certs e as chaves privadas associadas a certificados (nem todas as chaves) em /var/lib/aziot/keyd/keys. O IoT Edge os recria com o novo certificado de autoridade de certificação fornecido.

Essa abordagem exige que você atualize manualmente os arquivos à medida que o certificado vence. Para evitar esse problema, considere usar o EST para gerenciamento automático.

Gerenciamento automático de certificados com o servidor EST

O IoT Edge pode fazer a interface com um servidor EST (Enrollment over Secure Transport) para emissão e renovação automáticas de certificado. O uso do EST é recomendado para produção, pois substitui a necessidade de gerenciamento manual de certificados, o que pode ser arriscado e propenso a erros. Ele pode ser configurado globalmente e substituído para cada tipo de certificado.

Nesse cenário, espera-se que o certificado de inicialização e a chave privada sejam de longa duração e estejam potencialmente instalados no dispositivo durante a fabricação. O IoT Edge usa as credenciais de inicialização para se autenticar no servidor EST para que a solicitação inicial emita um certificado de identidade nas solicitações seguintes e para autenticação no DPS ou no Hub IoT.

  1. Obtenha acesso a um servidor EST. Se você não tiver um servidor EST, use uma das seguintes opções para iniciar o teste:

  2. No arquivo de configuração do dispositivo IoT Edge config.toml, configure o caminho para um certificado raiz confiável que o IoT Edge usa a fim de validar o certificado TLS do servidor EST. Essa etapa será opcional se o servidor EST tiver um certificado TLS raiz confiável publicamente.

    [cert_issuance.est]
    trusted_certs = [
       "file:///var/aziot/root-ca.pem",
    ]
    
  3. Forneça uma URL padrão para o servidor EST. Em config.toml, adicione a seguinte seção com a URL do servidor EST:

    [cert_issuance.est.urls]
    default = "https://example.org/.well-known/est"
    
  4. Para configurar o certificado EST para autenticação, adicione a seguinte seção com o caminho para o certificado e a chave privada:

    [cert_issuance.est.auth]
    bootstrap_identity_cert = "file:///var/aziot/my-est-id-bootstrap-cert.pem"
    bootstrap_identity_pk = "file:///var/aziot/my-est-id-bootstrap-pk.key.pem"
    
    [cert_issuance.est.identity_auto_renew]
    rotate_key = true
    threshold = "80%"
    retry = "4%"
    
  5. Aplique as alterações de configuração.

    sudo iotedge config apply
    

As configurações em [cert_issuance.est.identity_auto_renew] serão abordadas na próxima seção.

Nome de usuário e autenticação de senha

Se a autenticação para o servidor EST usando o certificado não for possível, você poderá usar um segredo compartilhado ou um nome de usuário e uma senha.

[cert_issuance.est.auth]
username = "username"
password = "password"

Configurar parâmetros de renovação automática

Em vez de gerenciar manualmente os arquivos de certificado, o IoT Edge tem a capacidade interna de obter e renovar certificados antes do vencimento. A renovação de certificado requer um método de emissão que IoT Edge pode gerenciar. O registro no servidor EST (Enrollment over Secure Transport) é um método de emissão, mas o IoT Edge também pode renovar automaticamente a AC de início rápido por padrão. A renovação de certificado é configurada por tipo de certificado.

  1. Em config.toml, localize a seção relevante para o tipo do certificado a ser configurado. Por exemplo, você pode pesquisar a palavra-chave auto_renew.

  2. Usando o exemplo do modelo de configuração, configure o certificado de identidade do dispositivo, a AC do Edge ou os certificados de identidade EST. O padrão de exemplo é:

    [REPLACE_WITH_CERT_TYPE]
    # ...
    method = "est"
    # ...
    
    [REPLACE_WITH_CERT_TYPE.auto_renew]
    rotate_key = true
    threshold = "80%" 
    retry = "4%"
    
  3. Aplicar a configuração

    sudo iotege config apply
    

A tabela abaixo lista o que cada opção em auto_renew faz:

Parâmetro Descrição
rotate_key Controla se a chave privada deve ser girada quando o IoT Edge renova o certificado.
threshold Define quando o IoT Edge deve começar a renovar o certificado. Ele pode ser especificado como:
– Percentual: inteiro entre 0 e 100, seguido por %. A renovação começa em relação ao tempo de vida do certificado. Por exemplo, quando definido como 80%, um certificado válido por 100 dias inicia a renovação 20 dias antes da expiração.
– Tempo absoluto: inteiro seguido por min (minutos) ou day (dias). A renovação é iniciada em relação à hora de expiração do certificado. Por exemplo, quando definido como 4day por quatro dias ou como 10min por 10 minutos, o certificado começa a ser renovado nesse momento antes de expirar. Para evitar uma configuração incorreta não intencional em que o threshold é maior do que o tempo de vida do certificado, recomendamos usar o percentual sempre que possível.
retry controla a frequência com que a renovação deve ser repetida em caso de falha. Assim como threshold, ele pode ser especificado como percentual ou tempo absoluto usando o mesmo formato.

Exemplo: renovar o certificado de identidade do dispositivo automaticamente com o EST

Para usar o EST e o IoT Edge a fim de emitir e renovar automaticamente certificado de identidade do dispositivo, o que é recomendado para produção, o IoT Edge precisará provisionar como parte de um grupo de registro baseado em AC do DPS. Por exemplo:

## DPS provisioning with X.509 certificate
[provisioning]
source = "dps"
# ...
[provisioning.attestation]
method = "x509"
registration_id = "my-device"

[provisioning.attestation.identity_cert]
method = "est"
common_name = "my-device"

[provisioning.attestation.identity_cert.auto_renew]
rotate_key = true
threshold = "80%"
retry = "4%"

A renovação automática para a AC do Edge deve ser habilitada quando o método de emissão está configurado para EST. A expiração da CA do Edge deve ser evitada, pois quebra muitas funcionalidades do IoT Edge. Se uma situação exigir controle total sobre o ciclo de vida do certificado de AC do Edge, use o método manual de gerenciamento da AC do Edge.

Não use EST ou auto_renew com outros métodos de provisionamento, incluindo o provisionamento manual do X.509 com o Hub IoT e o DPS com registro individual. O IoT Edge não pode atualizar as impressões digitais do certificado no Azure quando um certificado é renovado, o que impede que o IoT Edge se reconecte.

Exemplo: gerenciamento automático da AC do Edge com EST

Use a emissão automática de AC do EST no Edge e a renovação para produção. Depois que o servidor EST estiver configurado, você poderá usar a configuração global ou substituí-la de forma semelhante a este exemplo:

[edge_ca]
method = "est"

common_name = "my-edge-CA"
url = "https://ca.example.org/.well-known/est"

bootstrap_identity_cert = "file:///var/aziot/my-est-id-bootstrap-cert.pem"
bootstrap_identity_pk = "file:///var/aziot/my-est-id-bootstrap-pk.key.pem"

[edge_ca.auto_renew]
rotate_key = true
threshold = "90%"
retry = "2%"

Certificados do servidor de módulo

O Daemon do Edge emite certificados de identidade e servidor de módulo para uso por módulos do Edge. Continua a ser responsabilidade dos módulos do Edge renovar seus certificados de identidade e servidor, conforme a necessidade.

Renovação

Os certificados do servidor podem ser emitidos fora do Certificado de Autoridade de Certificação do Edge. Independentemente do método de emissão, esses certificados devem ser renovados pelo módulo. Se você desenvolver um módulo personalizado, precisará implementar a lógica de renovação no módulo.

O módulo edgeHub dá suporte a um recurso de renovação de certificado. Você pode configurar a renovação do certificado do servidor do módulo edgeHub usando as seguintes variáveis de ambiente:

  • ServerCertificateRenewAfterInMs: define a duração em milissegundos quando o certificado do servidor edgeHub é renovado, independentemente do tempo de expiração do certificado.
  • MaxCheckCertExpiryInMs: define a duração em milissegundos quando o serviço edgeHub verifica a expiração do certificado do servidor edgeHub. Se a variável estiver definida, a verificação ocorrerá, independentemente do tempo de expiração do certificado.

Para obter mais informações sobre as variáveis de ambiente, confira Variáveis de ambiente EdgeHub e EdgeAgent.

Alterações em 1.2 e posteriores

  • O Certificado de autoridade de certificação do dispositivo foi renomeado como Certificado de AC do Edge.
  • O certificado da AC de carga de trabalho foi preterido. Agora, o IoT Edge Security Manager gera o certificado de servidor edgeHub de Hub de IoT Edge diretamente do certificado de AC de borda, sem o certificado de AC de carga de trabalho intermediário entre eles.
  • O arquivo de configuração padrão tem um novo nome e local, de /etc/iotedge/config.yaml para /etc/aziot/config.toml por padrão. O comando iotedge config import pode ser usado para ajudar a migrar informações de configuração do local e da sintaxe antigos para a nova.

Próximas etapas

A instalação de certificados em um dispositivo IoT Edge é uma etapa necessária antes de implantar sua solução em produção. Saiba mais sobre como Preparar-se para implantar sua solução de IoT Edge em produção.