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

Três aspectos do trabalho com certificados afetam todo dispositivo implantado: proteger a chave privada uma vez que ela esteja na câmera, planejar para o dia em que o certificado expirar e a curta lista de modos de erro que aparecem na prática.

14.4.6.1. Protegendo a chave privada

Sempre que a câmera apresenta um certificado – como servidor TLS, ou como cliente em mTLS – sua chave privada precisa residir no dispositivo, em DER puro, no sistema de arquivos ou no ROMFS. Armazenada dessa forma, ela é legível por qualquer código em execução na câmera e por qualquer pessoa com acesso físico a ela: a unidade de armazenamento em massa USB, um prompt REPL ou a flash bruta. O ROMFS e os sinalizadores de somente leitura impedem a modificação, não a extração. Trate qualquer chave privada embarcada em um dispositivo como recuperável por um invasor determinado com acesso físico ou ao código.

Isso não torna o TLS inútil – ele molda a forma como você o implanta:

  • Use uma chave e um certificado exclusivos por dispositivo. Nunca grave uma única chave compartilhada em toda a frota: extraí-la de uma única unidade permitiria então que um invasor se passasse por todas as câmeras. Chaves por dispositivo limitam um comprometimento a esse único dispositivo, que você pode revogar ou desabilitar no lado do servidor.

  • Mantenha os certificados com vida curta. Uma chave roubada só é útil enquanto seu certificado for válido; tempos de vida curtos somados à rotação rotineira limitam o dano (veja Expiração e rotação de certificados abaixo).

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

  • Nunca distribua uma chave em uma imagem de firmware pública. Uma chave embutida no ROMFS em uma build de firmware que você distribui não é secreta; qualquer pessoa que baixar o firmware a possui. Provisionamento por dispositivo significa programar a chave depois do firmware genérico, não dentro dele.

  • Limite o raio de impacto. Restrinja o escopo daquilo que o certificado autentica (privilégio mínimo) e garanta que uma única identidade de dispositivo vazada possa ser revogada ou desabilitada sem afetar o restante.

Se o seu modelo de ameaça inclui invasores com acesso físico, projete partindo do pressuposto de que a chave do dispositivo acabará vazando e torne isso sustentável, em vez de presumir que ela pode ser mantida secreta em um hardware que não dispõe de meios para tal.

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

Todo certificado carrega uma janela de validade. Uma vez que ela passa, um par ssl.CERT_REQUIRED rejeita a conexão – de modo que a expiração é uma interrupção real e agendada, não um risco teórico. O relógio da câmera também precisa estar correto para que a verificação de validade seja avaliada de forma honesta.

  • Autoassinado. Você escolheu o tempo de vida com -days. Quando ele expira, você deve regenerar a chave/certificado e reimplantá-lo: recopiar os arquivos DER, ou reconstruir e regravar a imagem do ROMFS se o certificado estiver embutido nela. Escolha um valor de -days sobre o qual você realmente se lembrará de agir.

  • CA pública. Esses são deliberadamente de vida curta. A Let’s Encrypt emite certificados de 90 dias e espera renovação automatizada a cada 60 dias, aproximadamente; não existe a opção de “instalar uma vez e esquecer”.

A tendência mais ampla é unidirecional: a validade máxima de certificados TLS de confiança pública continua diminuindo. Era de 825 dias, atualmente está limitada a 398 dias, e o CA/Browser Forum adotou um cronograma que a reduz gradualmente para cerca de 47 dias até 2029. A conclusão para o projeto de um dispositivo é presumir que os certificados são de vida curta e que a rotação deve ser automatizada ou ao menos rotineira – não distribua um produto que dependa de um humano trocando um certificado de dez anos.

Na prática, na câmera: prefira projetos em que o certificado possa ser substituído sem regravar (um sistema de arquivos gravável somado a um caminho de atualização remota, ou executar a câmera como cliente que confia em uma CA cuja rotação você gerencia centralmente). Se um certificado precisar residir no ROMFS, agende atualizações de firmware em torno do seu tempo de vida.

14.4.6.3. Solução de problemas

  • O relógio precisa estar ajustado. Uma câmera que não ajustou seu relógio desde a inicialização falha na verificação de validade do certificado – chame ntptime.settime() primeiro.

  • O nome de host precisa coincidir. Quando o cliente passa server_hostname, ele precisa coincidir com o subjectAltName do certificado (ou CN em pilhas mais antigas), ou a verificação falha.

  • Formato incorreto. Um arquivo PEM copiado para a câmera não será carregado – converta para DER primeiro.

  • Certificado expirado. Uma conexão que funcionava antes e agora falha com OSError pode simplesmente ter um certificado expirado – verifique as datas de validade e regenere/reimplante 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; falhas de TLS (certificado inválido, expirado, CA desconhecida, erro de formato, falha de handshake) são lançadas como OSError.