APRENDER. PRATICAR. EVOLUIR.Separar distribuição de ativação
O laboratório copia server-old.pem e a chave correspondente para caminhos deployed e carrega um contexto. Substitui depois ambos os ficheiros por material novo. Uma ligação nova ao contexto antigo continua a observar o fingerprint anterior; uma ligação a um contexto fresco observa o novo. O ficheiro foi distribuído, mas o contexto não foi recarregado pela simples cópia. O ensaio cria contextos separados em listeners temporários, não executa um hot reload de produção. Usa a distinção para definir qual mecanismo de ativação a tua aplicação suporta e como o vais provar.
Validar o pacote antes de o servir
Um grupo tenta carregar o certificado novo com a chave privada antiga. KEY_VALUES_MISMATCH ocorre antes de existir listener para esse contexto. Localiza o problema na preparação do par, sem procurar um cliente remoto que ainda não participou. Num rollout fictício, prepara o pacote coerente, verifica cadeia, nome, propósito e correspondência da chave, e só depois ativa. O fingerprint do certificado identifica o artefacto observado; sozinho não prova rotação de chave, porque reemissão pode conservar a chave. Neste ensaio a geração separada das chaves fica registada nos comandos, sem imprimir material privado.
Confirmar confiança efetivamente carregada
O grupo deployed-trust carrega inicialmente a CA antiga e depois substitui o ficheiro pela nova. O contexto antigo ainda aceita clientes antigos; o fresco rejeita-os e aceita clientes novos. Esta observação impede fechar uma retirada de confiança apenas com o hash do ficheiro central. Para várias instâncias, regista versão do pacote, contexto ativo e resultado de probes positivas e negativas. Não confundas retirar uma âncora com distribuir uma CRL ou obter estado OCSP. O script não executa esses mecanismos. As CAs do ensaio são aprovadas para uma migração planeada, sem compromisso simulado.
Tratar ligações que já existiam
O último grupo mantém uma ligação autenticada com o cliente antigo. Uma probe separada usa o contexto novo e é rejeitada, enquanto a ligação antiga continua a responder EXISTING-OK. Não houve reautenticação dessa ligação, revogação global ou retoma de sessão. O ensaio mostra apenas que criar outra política não termina automaticamente o socket anterior. Numa mudança fictícia, define se as ligações devem concluir trabalho, ser drenadas com prazo ou terminar segundo uma política aprovada. Considera o estado das operações antes de interromper tráfego e distingue ligações existentes de novas tentativas.
Preparar reversão com condições
A documentação Python permite partilhar contextos, mas alerta para certas alterações depois de já terem sido usados. O desenho didático prepara contextos novos e evita mutar o que serve ligações. Para a release fictícia, escreve uma condição de paragem: por exemplo, consumidor autorizado rejeitado ou instância a servir material inesperado. Define o pacote aprovado que pode ser reposto e a prova de recuperação. Se a CA antiga deixar de ser confiável, esse rollback já não é automaticamente válido. O plano de resposta ao compromisso exige outra decisão, mesmo que a configuração antiga recupere disponibilidade.
Entregar critérios claros ao RUN
Usa a grelha abaixo para uma simulação proposta de handover em inglês. Identifica material distribuído, estado ativo por instância, populações de clientes, ligações antigas, recusas esperadas e resultado das operações permitidas. Atribui responsáveis e próximo ponto de situação. Não houve workshop humano realizado nesta revisão. Os doze grupos locais não demonstram rollout Kubernetes, comportamento de um balanceador, retoma de sessões, OCSP, carga ou recuperação de produção. A aceitação deve incluir os runtimes e percursos representativos do serviço, mantendo o laboratório como evidência dos mecanismos efetivamente exercitados.
PROPOSED TLS ROLLOVER HANDOVER
Change scope: server identity / client issuer / application identity.
Approved trust: old, overlap, new; approval and retirement conditions.
Artifact: certificate fingerprint, public-key evidence, package version.
Activation: instance, context version, new-connection probe result.
Client matrix: old/new issuer, missing cert, wrong purpose, unmapped identity.
Application: expected ALLOW/DENY, operation owner, functional evidence.
Existing connections: inventory, drain/termination policy, operation state.
Rollback: trigger, approved package, owner, evidence of recovery.
Outstanding: representative runtime/path, session resumption, CRL/OCSP.
Statement: Local mTLS checks passed; production reload and session policies
still need validation. No human workshop has been performed.
Simulação: três instâncias apresentam o certificado novo e uma retém o antigo; clientes novos funcionam, mas o batch antigo falha. Preenche impacto, hipótese, ação autorizada, reversão e critério de fecho.
Armadilhas comuns
Fechar pela cópia de ficheiros, misturar versões do par, alterar contexto em uso sem contrato, esquecer ligações antigas ou chamar revogação à simples retirada de confiança.
Tópicos relacionados: Negociação, mTLS e aplicação · Renovação e certificado servido · Diagnóstico com critérios explícitos
Distribuição, ativação e sessões têm ciclos distintos. O fecho requer evidência por instância e consumidor, com reversão compatível com a confiança aprovada.
Referência: Python ssl: TLS contexts and verification · DR TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics