APRENDER. PRATICAR. EVOLUIR.Identificar o consumidor e a etapa da falha
Quando uma integração WebSphere falha após rotação de certificados, começa por localizar o consumidor, o endpoint e a etapa que produziu o erro. O browser, o frontend, a JVM e uma ferramenta de linha de comandos podem usar material de confiança diferente. Um teste local bem-sucedido é evidência sobre esse teste, não sobre todos os percursos. Regista nome de referência, porta, cadeia observada, versão da ferramenta e configuração selecionada. Distingue carregamento da identidade local, handshake e resposta da aplicação. Esta separação evita pedir permissões administrativas para resolver uma falha de cadeia ou reemitir certificados quando o controlo de autorização está simplesmente a recusar uma ação não permitida.
Laboratório de handshakes em memória
O laboratório cria autoridades e identidades temporárias com OpenSSL e usa SSLContext e MemoryBIO do Python para trocar mensagens TLS. São handshakes reais e, quando passam, o cliente envia um pequeno payload que o servidor recebe. Não se abrem sockets TCP nem se alteram stores pessoais. O protocolo está fixado em TLS 1.2 para tornar o âmbito explícito, sem o apresentar como recomendação universal. A execução registada usa CPython 3.13.1 e OpenSSL 3.6.1. Estes resultados não reproduzem IBM JSSE, GSKit, IHS ou WebSphere. As chaves ficam num diretório temporário protegido, não são impressas e são eliminadas no fim.
Rotação de CA e contexto carregado
Na primeira experiência, um cliente que confia só na CA antiga aceita o servidor antigo e rejeita o certificado novo. Um contexto com as duas CAs aprovadas aceita ambos os estados. Isto demonstra sobreposição de confiança na fixture, sem decidir durante quanto tempo a CA antiga deve continuar autorizada. Outra experiência carrega confiança antiga, substitui o ficheiro no disco e volta a usar o mesmo contexto: este continua a rejeitar o servidor novo. Um contexto criado depois passa. Em WebSphere, confirma o mecanismo suportado de seleção e adoção, em vez de concluir que o comportamento Python exige um restart global da célula.
Nome do servidor e identidade de cliente
A cadeia confiável não responde sozinha à pergunta “é este o servidor esperado?”. O certificado da fixture contém partner.example.test, pelo que pedir other.example.test falha na verificação de nome. Reimportar a mesma CA não muda o SAN. No ensaio mTLS, o servidor exige também certificado de cliente: sem identidade apresentada, rejeita o handshake; com certificado e chave correspondentes, aceita-o. Um teste separado tenta carregar uma chave que não corresponde ao certificado e falha antes de existir handshake. Estes resultados ajudam a escolher a próxima evidência: nome, confiança, par de identidade ou exigência do servidor. Não são motivos para desligar validações permanentemente.
Autenticar não concede todas as ações
Imagina uma integração fictícia de consulta de dados de fundos. Depois de corrigir mTLS, a aplicação identifica o cliente, aceita uma consulta e recusa escrita com 403. Se o requisito da conta é apenas leitura, a recusa pode ser o resultado correto. O teste deve confirmar uma operação permitida e uma proibida, com evidência da política aplicada. Não concedas o papel mais amplo apenas para obter respostas de sucesso. Distingue também o componente que gerou o código HTTP, pois um 403 isolado não localiza a causa. O laboratório não executa autorização de aplicação; esta parte é um cenário de decisão a ensaiar no contexto real autorizado.
Guião de rotação e recuperação
Prepara uma matriz de consumidores, endpoints, identidades, confiança esperada e evidência antes e depois da mudança. Inclui clientes pouco frequentes: a ausência de um consumidor mensal nos logs de hoje não confirma a sua compatibilidade. Define responsáveis, janela de sobreposição, critérios de retirada e recuperação para o estado anterior quando ainda for permitido. Na oficina, explica cada falha do laboratório sem extrapolar para opções específicas de WebSphere. Depois escreve o pedido de evidência necessário à equipa middleware: configuração selecionada, adoção e teste pelo consumidor afetado. O resultado esperado é uma integração funcional com confiança delimitada, e um registo claro dos pontos que continuam por confirmar.
# ACTUAL TLS LIBRARY LAB: temporary PKI, no TCP sockets
python3 content/labs/was-recovery/run.py --openssl /opt/homebrew/bin/openssl
# Python 3.13.1 + OpenSSL 3.6.1, TLS 1.2 MemoryBIO handshakes
# old trust -> old peer: pass; old trust -> new peer: fail
# overlap trust -> either peer: pass
# No IBM JSSE, IHS, WebSphere, CRL/OCSP or application authorization tested.Um ficheiro de confiança atualizado não mudou um SSLContext Python existente. O contexto novo passou; o diagnóstico de WebSphere continua a exigir evidência do consumidor real.
Armadilhas comuns
Importar em vários stores sem identificar o utilizado; ignorar consumidores mensais; confundir mTLS com autorização; extrapolar reload Python para IBM JSSE.
Tópicos relacionados: TLS e acesso administrativo · Artefactos e percurso HTTP · Manutenção e recuperação
Segue a chamada real e identifica a etapa da falha. Uma rotação fica demonstrada por consumidores e operações relevantes, com limites de confiança explícitos.
Referência: ssl TLS wrapper and MemoryBIO · DR WebSphere traditional ND 9.0.5; maintenance baseline 9.0.5.29 (2026-09-08); documentation reviewed 2026-09-30