14.4.6. Operações: chaves, expiração e resolução de problemas

Três aspetos do trabalho com certificados atravessam todos os dispositivos implementados: proteger a chave privada depois de estar na câmara, planear para o dia em que o certificado expira, e a pequena lista de modos de erro que surgem na prática.

14.4.6.1. Proteger a chave privada

Sempre que a câmara apresenta um certificado – como servidor TLS, ou como cliente em mTLS – a sua chave privada tem de residir no dispositivo, em DER simples, no sistema de ficheiros ou no ROMFS. Armazenada desta forma, é legível por qualquer código em execução na câmara e por qualquer pessoa com acesso físico a esta: a unidade de armazenamento em massa USB, um terminal REPL, ou a flash em bruto. O ROMFS e os sinalizadores de apenas leitura impedem a modificação, não a extração. Trate qualquer chave privada instalada num dispositivo como recuperável por um atacante determinado com acesso físico ou ao código.

Isto não torna o TLS inútil – define a forma como o implementa:

  • Use uma chave e um certificado únicos por dispositivo. Nunca instale uma chave partilhada em toda a frota: extraí-la de uma única unidade permitiria a um atacante fazer-se passar por todas as câmaras. As chaves por dispositivo limitam um comprometimento a esse único dispositivo, que pode revogar ou desativar do lado do servidor.

  • Mantenha os certificados de curta duração. Uma chave roubada só é útil enquanto o seu certificado é válido; tempos de vida curtos mais rotação regular limitam os danos (veja Certificate expiry and rotation abaixo).

  • Evite colocar um segredo no dispositivo sempre que possível. Se apenas precisa de verificar o servidor (autenticação de servidor, não mTLS), a câmara como cliente armazena apenas o certificado CA – que é público – e não guarda nenhuma chave privada a roubar.

  • Nunca inclua uma chave numa imagem de firmware pública. Uma chave incorporada no ROMFS numa compilação de firmware que distribui não é secreta; qualquer pessoa que descarregue o firmware tem-na. O aprovisionamento por dispositivo implica programar a chave após o firmware genérico, não dentro dele.

  • Limite o raio de explosão. Restrinja o âmbito do que o certificado autentica (privilégio mínimo) e certifique-se de que uma identidade de dispositivo comprometida pode ser revogada ou desativada sem afetar o resto.

Se o seu modelo de ameaça inclui atacantes com acesso físico, projete com o pressuposto de que a chave do dispositivo acabará por ser comprometida e que isso seja sobrevivível, em vez de assumir que pode ser mantida em segredo em hardware que não possui capacidade para o fazer.

14.4.6.2. Expiração e rotação de certificados

Cada certificado tem uma janela de validade. Quando termina, um par com ssl.CERT_REQUIRED rejeita a ligação – logo a expiração é uma interrupção real e agendada, não um risco teórico. O relógio da câmara também tem de estar correto para que a verificação de validade seja avaliada corretamente.

  • Autoassinado. Escolheu o tempo de vida com -days. Quando expirar, tem de regenerar a chave/certificado e reimplementá-lo: recopiar os ficheiros DER, ou reconstruir e reintalar o flash da imagem ROMFS se o certificado estiver incorporado. Escolha um valor -days que se lembrará de realmente cumprir.

  • CA pública. Estes têm deliberadamente vida curta. A Let’s Encrypt emite certificados de 90 dias e espera renovação automatizada aproximadamente a cada 60 dias; não existe opção «instalar uma vez e esquecer».

A tendência mais ampla é unidirecional: a validade máxima dos certificados TLS de confiança pública continua a diminuir. Era de 825 dias, está atualmente limitada a 398 dias, e o CA/Browser Forum adotou um calendário que a reduz progressivamente para aproximadamente 47 dias até 2029. A conclusão para um projeto de dispositivo é assumir que os certificados têm vida curta e que a rotação tem de ser automatizada ou pelo menos rotineira – não comercialize um produto que dependa de um humano a substituir um certificado de dez anos.

Na prática, na câmara: prefira projetos onde o certificado possa ser substituído sem reinstalar o firmware (um sistema de ficheiros gravável mais um caminho de atualização remoto, ou executar a câmara como cliente que confia numa CA que roda centralmente). Se um certificado tiver de residir no ROMFS, agende atualizações de firmware em torno do seu tempo de vida.

14.4.6.3. Resolução de problemas

  • O relógio tem de estar definido. Uma câmara que não tenha definido o relógio desde o arranque falha a verificação de validade do certificado – chame primeiro ntptime.settime().

  • O nome do anfitrião tem de corresponder. Quando o cliente passa server_hostname, este tem de corresponder ao subjectAltName do certificado (ou CN em pilhas mais antigas), caso contrário a verificação falha.

  • Formato errado. Um ficheiro PEM copiado para a câmara não será carregado – converta primeiro para DER.

  • Certificado expirado. Uma ligação que funcionava antes e que agora falha com OSError pode simplesmente ter um certificado expirado – verifique as datas de validade e regenere/reimplemente conforme necessário.

  • Chaves Ed25519 falham. Use ECDSA P-256/P-384 ou RSA, não Ed25519.

  • Os erros são OSError. O MicroPython não implementa ssl.SSLError; as falhas TLS (certificado inválido, expirado, CA desconhecida, erro de formato, falha no handshake) são lançadas como OSError.