Ciclo de vida e renovação do certificado

Importante

Esta é a documentação do Azure Sphere (herdado). O Azure Sphere (herdado) será desativado em 27 de setembro de 2027 e os usuários devem migrar para o Azure Sphere (integrado) até esse momento. Use o seletor de versão localizado acima do sumário para exibir a documentação do Azure Sphere (Integrado).

Os pares de chaves de certificado do cliente e certificados de Autoridade de Certificação expiram regularmente. A infraestrutura de rede e os dispositivos devem ser capazes de lidar com a expiração do certificado e apresentar um novo certificado sem perder a conectividade. Os certificados de Autoridade de Certificação raiz, usados na autenticação do servidor RADIUS, bem como os certificados do cliente, usados na autenticação do dispositivo, exigem abordagens diferentes para atualizar.

Cuidado

Como as IDs de certificado são de todo o sistema, um comando azsphere ou uma chamada de função que adiciona um novo certificado pode substituir um certificado que foi adicionado por um comando ou chamada de função anterior, potencialmente causando falhas de conexão de rede. Recomendamos que você desenvolva procedimentos de atualização de certificado bem definidos e escolha IDs de certificado com cuidado.

Confira IDs de Certificado para obter mais informações sobre como o Azure Sphere usa IDs de certificado.

Atualizar um Certificado de Autoridade de Certificação raiz

Um Certificado de Autoridade de Certificação é a AC raiz do certificado de autenticação no servidor RADIUS. Se o Certificado de Autoridade de Certificação expirar ou a PKI do servidor for alterada, por exemplo, se o servidor adquirir uma nova AC raiz de uma autoridade de certificado diferente, os dispositivos do Azure Sphere não poderão mais autenticar o servidor de autenticação RADIUS. No entanto, os dispositivos precisam continuar funcionando.

Em uma rede sem fio típica, não é possível executar uma substituição "knife-edge"; ou seja, não é possível atualizar todos os dispositivos Azure Sphere no instante exato em que a AC raiz se torna inválida. Os dispositivos podem estar offline no momento crítico ou a precisão da cronometragem pode variar entre as instalações. Seu aplicativo de alto nível deve ser capaz de obter o novo Certificado de Autoridade de Certificação raiz antes que o atual expire ou seja alterado, para que o novo certificado esteja pronto para uso quando necessário.

A abordagem recomendada é criar e habilitar uma segunda rede que tenha a mesma configuração da rede existente, mas que use o novo Certificado de Autoridade de Certificação raiz. Quando o Certificado de Autoridade de Certificação raiz existente falhar na rede original, o sistema operacional tentará automaticamente se conectar à segunda rede. O aplicativo poderá, então, substituir o certificado na rede original pela nova AC raiz e excluir a segunda rede. O dispositivo poderá se conectar usando a rede original, que agora tem a nova AC raiz. A figura a seguir resume essa abordagem.

Um aplicativo de alto nível deve seguir estas etapas para lidar diretamente com uma atualização do Certificado de Autoridade de Certificação raiz:

1. Como parte da operação normal, o aplicativo configura a Network1 do tipo WifiConfig_Security_Wpa2_EAP_TLS. Essa rede está vinculada ao certificado do cliente do dispositivo e à CA1 raiz, que é a AC raiz original do servidor RADIUS.

2. Cerca de 90 dias antes da expiração do RootCA, o dispositivo recebe uma notificação de nuvem para dispositivo informando que um novo Certificado de Autoridade de Certificação raiz do servidor RADIUS será exigido em breve. A notificação pode ser acionada por um administrador de rede ou outra operadora; os possíveis mecanismos de notificação incluem uma mensagem da nuvem para o dispositivo do Hub IoT do Azure ou do Azure IoT Central.

   O administrador de rede é responsável por atualizar o certificado no servidor RADIUS e verificar se os dispositivos Azure Sphere serão atualizados adequadamente.

3. O aplicativo adquire uma nova AC raiz e chama CertStore_InstallRootCACertificate para salvá-la como CA2 raiz.

4. O aplicativo cria uma rede, Network2, chamando WifiConfig_AddDuplicateNetwork para duplicar a configuração da Network1. Em seguida, ele vincula a CA2 raiz à Network 2 e habilita a Network2. Se a Network2 estiver habilitada no dispositivo e puder se conectar à Internet, o dispositivo a usará se a Network1 não estiver disponível.

5. O aplicativo sonda diariamente chamando WifiConfig_GetConnectedNetworkId para determinar a qual rede o dispositivo está conectado.

   Se a verificação diária da rede conectada falhar, o erro poderá ser decorrente de um problema de certificado no lado do servidor ou do dispositivo ou resultante de algum outro problema. Consulte Solução de problemas de rede para obter ajuda.

   Se o dispositivo estiver conectado à Network1, isso significa que o certificado ainda não expirou e tudo está funcionando corretamente. O aplicativo repete essa etapa até que o dispositivo se conecte à Network2.

   Se o dispositivo estiver conectado à Network2, isso significa que o certificado antigo expirou, a PKI atualizada será configurada no servidor RADIUS e o dispositivo será capaz de autenticar o servidor usando o CA2 raiz.

6. Quando o dispositivo estiver funcionando corretamente com a Network2, o aplicativo concluirá as alterações na configuração de rede:

   • Renomeia a CA2 raiz para a CA1 raiz chamando CertStore_MoveCertificate. Essa função substitui a CA1 raiz expirada pelo conteúdo da CA2 raiz.
   • Recarrega a configuração da Network1 chamando WifiConfig_ReloadConfig. A configuração da Network1 agora corresponde à rede atual.
   • Exclui a configuração da Network2 chamando WifiConfig_ForgetNetworkById.

Atualizar um certificado do cliente

O certificado do cliente é composto pelo par de chaves pública e privada usadas para autenticar o dispositivo Azure Sphere. Assim como o Certificado de Autoridade de Certificação raiz, o certificado do cliente expirará periodicamente e o dispositivo deverá ser capaz de apresentar um novo certificado. Seu aplicativo de alto nível é responsável por obter o novo certificado antes que o certificado existente expire. Um aplicativo pode obter a data e a hora em que um certificado expira chamando CertStore_GetCertificateNotAfter.

A figura a seguir resume esse procedimento. Esse padrão permite que o código de atualização do certificado use IDs de certificado constantes, como ClientCert1 e ClientCert2, em vez de criar um nome exclusivo para cada certificado novo. Além disso, ele não requer trocas de rede nem a limpeza de certificado do cliente.

Um aplicativo de alto nível deve seguir estas etapas para lidar diretamente com uma atualização do certificado do cliente:

1. Como parte da operação normal, o aplicativo configura a Network1 do tipo WifiConfig_Security_Wpa2_EAP_TLS. Essa rede está vinculada ao certificado do cliente do dispositivo (ClientCert1) e à AC raiz do servidor RADIUS. Antes que o aplicativo inicie o procedimento de atualização, ele verifica se o dispositivo está conectado à Network1 chamando WifiConfig_GetNetworkIdByConfigName e WifiConfig_GetConnectedNetworkId. Se as IDs da rede corresponderem, o aplicativo poderá ter certeza de que está conectado à rede pretendida.

2. O aplicativo chama CertStore_GetCertificateNotAfter em intervalos regulares para determinar quando o certificado do cliente expirará. Como alternativa, o aplicativo pode armazenar a data de validade no armazenamento mutável; no entanto, ele ainda deve verificar a data de validade diariamente e depois de cada reinicialização.

   O aplicativo compara a data e a hora da validade com a data e a hora atuais. Se o certificado expirar em um período limite predeterminado, o aplicativo obterá um novo certificado. O comprimento do período limite é sua escolha. Como prática recomendada, recomendamos obter um novo certificado pelo menos quatro semanas antes da expiração, caso o dispositivo fique offline por um longo período de tempo ou encontre problemas repetidos de rede ou servidor. Quanto antes você verificar, mais tempo terá de resolver problemas.

3. O aplicativo obtém um novo certificado do emissor do certificado apropriado. A escolha de um emissor do certificado é de responsabilidade do administrador de rede local.

4. O aplicativo salva o novo certificado como ClientCert2 chamando CertStore_InstallClientCertificatee o adiciona à configuração de Wi-Fi da Network1 chamando WifiConfig_SetClientCertStoreIdentifier.

5. O aplicativo recarrega a configuração Wi-Fi chamando WifiConfig_ReloadConfig. Essa etapa torna o ClientCert2 disponível para o dispositivo para uso em conexões de rede.

6. Verifique se a conexão de rede foi bem-sucedida.

   • Conexão bem-sucedida significa que ClientCert2 agora é válido.

     • Renomeie ClientCert2 como ClientCert1 chamando CertStore_MoveCertificate.

     • Desabilite Network1 chamando WifiConfig_SetNetworkEnabled para definir o estado Habilitado da rede como falso e, em seguida, habilite novamente Network1 chamando WifiConfig_SetNetworkEnabled para definir o estado Habilitado como true. Desabilitar e reabilitar a configuração torna o conteúdo do certificado renomeado disponível para o aplicativo.

   • A falha ao se conectar significa que ClientCert2 ainda não é válida ou que algum outro erro ocorreu.

     • Se o certificado ainda não for válido, passe para a etapa 7 para retornar a configuração de rede ao estado original.
     • Se ocorrer algum outro erro, consulte Solução de problemas de rede para obter ajuda e tentar novamente a conexão.

7. Independentemente de a conexão de rede ter sido bem-sucedida, recarregue a configuração de Wi-Fi chamando WifiConfig_ReloadConfig. Se a conexão tiver sido bem-sucedida, a configuração recarregada usará o novo ClientCert1, que foi substituído por ClientCert2. Se a conexão tiver falhado, a configuração recarregada usará ClientCert1.