APRENDER. PRATICAR. EVOLUIR.Testar outro instante sem mudar o sistema
O runner emite um leaf com um dia de validade, um intermédio com sete e raízes com catorze. A opção -attime permite testar um instante anterior à emissão e outro dois dias depois. O primeiro falha por material ainda não válido; o segundo deteta expiração do leaf. O relógio do sistema não é alterado. Esta técnica ajuda a formular testes de fronteira antes de uma janela, mas a validade real continua a depender das datas emitidas e do relógio efetivo do cliente que executa a ligação.
Interpretar uma janela de expiração
No certificado final do ensaio, -checkend 0 devolve zero e -checkend 172800 devolve não zero. A primeira pergunta é se já expirou; a segunda é se expira dentro de dois dias. Não são verificações da cadeia, do nome ou do propósito. Define a margem operacional com emissão, distribuição, ativação e recuperação em mente, em vez de escolher um número sem contexto. As durações curtas do laboratório aceleram a interpretação e não são uma recomendação de validade para certificados reais.
Confirmar o par através da parte pública
O laboratório extrai a chave pública do certificado e deriva a componente pública da chave privada. Converte ambas para DER e compara os bytes. O par esperado coincide; uma chave independente não. O runner nunca imprime a chave privada e conserva apenas evidência pública e metadados. Evita comparar hashes do ficheiro privado inteiro com hashes do certificado: esses objetos são diferentes mesmo quando formam um par correto. Em operação, identifica os artefactos e o método de comparação para que outra pessoa consiga interpretar o resultado.
Reemitir não demonstra rotação
O mesmo pedido é usado para emitir dois certificados com números de série diferentes. Os certificados DER diferem, mas a chave pública DER é igual. Este ensaio demonstra uma reemissão com reutilização da chave, não uma rotação. Isso pode ser permitido numa renovação normal segundo a política, mas não elimina uma exposição confirmada do segredo. Nesse caso, a recuperação precisa de substituir o par comprometido e tratar revogação, dependências e material antigo conforme a decisão autorizada. Um fingerprint novo do certificado não basta para fechar essa recuperação.
Confirmar ativação e capacidade durante a mudança
Um processo pode continuar a apresentar o certificado antigo depois de o ficheiro novo passar todas as verificações offline. Identifica como cada instância carrega o material, prepara reload suportado ou reinício controlado e preserva capacidade durante a intervenção. Valida o material apresentado nas instâncias que recebem tráfego e depois a operação do consumidor. Uma ligação ao endereço virtual pode atingir só um nó atualizado. O laboratório não executa esta ativação: fornece critérios para a checklist de mudança e para reconhecer evidência insuficiente num relatório de fecho.
Reproduzir e delimitar o relatório
As oito observações foram executadas com OpenSSL 3.6.1 e documentação da série 3.6 consultada nesta revisão. O percurso anterior mantém a referência histórica 3.5; não assume uma atualização dos ambientes do utilizador. Todos os certificados e chaves do runner são descartáveis e a diretoria temporária é eliminada mesmo quando ocorre uma exceção. Guarda comandos, códigos de saída e hashes públicos úteis. Não declares TLS, SNI, OCSP, CRL ou produção validados: nenhum desses percursos foi executado por esta verificação offline de ficheiros.
# No production keys or trust stores are used
python3 content/labs/tls-paths/run.py
# evidence.json: time, keyPair, reissuance, expiryWindow
# -attime changes the verification reference, not the system clock
# Same public DER + different certificate DER = reissuance, not key rotationCaso fictício: a série do certificado mudou após uma exposição, mas a chave pública é igual. O gestor mantém a recuperação aberta até existir substituição do par e validação dos consumidores relevantes.
Armadilhas comuns
Não confundas fingerprint do certificado com identidade da chave, -checkend com validação completa ou material correto no disco com material ativo em todos os processos.
Tópicos relacionados: Chaves, certificados e confiança · Identidade, nome e tempo · Diagnóstico com critérios explícitos
A renovação é concluída com material correto, ativação comprovada e consumidores recuperados; a evidência offline cobre apenas parte desse percurso.
Referência: OpenSSL x509 · DR TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics