Conceito e mecanismo
Validar um certificado exige mais do que confirmar que ainda está dentro da validade. O cliente precisa de confiar na cadeia, reconhecer a identidade pretendida e respeitar restrições de uso. Num cliente que segue RFC 9525, o hostname deve corresponder à identidade adequada em subjectAltName; o commonName não substitui essa condição. Se keyUsage e extendedKeyUsage estiverem presentes, o propósito deve ser compatível com ambas segundo RFC 5280. A gestão de chaves tem outra fronteira: rodar material de uma chave KMS simétrica AWS_KMS preserva a chave lógica e o material anterior necessário para decifrar. Não recifra automaticamente dados nem substitui uma data key exposta.
Aplicação guiada
Num decommission fictício, backups retidos continuam dependentes de uma chave que parece inativa na faturação. Antes de eliminar, mapeia dados e prova o destino de recuperação. Pending deletion já impede operações criptográficas da chave; não é um período de utilização normal até ao último dia. Para evolução pós-quântica, identifica funções em vez de trocar nomes: ML-KEM estabelece segredo partilhado e ML-DSA permite assinaturas. A integração deve considerar implementação, parâmetros, confiança e avisos de errata, sem prometer imunidade absoluta. Finalmente, desempenho pode mudar garantias: early data em TLS 1.3 pode ser repetida. Uma API com efeitos não idempotentes precisa de tratamento de replay e de regras de aplicação, não apenas de cifragem do canal.
Rotação da chave que protege uma data key não elimina uma cópia exposta dessa data key.
Armadilhas comuns
CN como SAN; alias como material; rotação como recifragem; assinatura como cifragem; 0-RTT como execução única.
Tópicos relacionados: Governance, risco e exceções · Fornecedores, dados e ameaças · Resiliência e dependências de recuperação
Valida a propriedade concreta que cada mecanismo fornece.
Referência: PKIX certificate and extension constraints · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17