APRENDER. PRATICAR. EVOLUIR.Ler uma resposta com três estados
O mesmo script da aula anterior cria um pedido para good.pem, revoked.pem e o serial 9999, ausente do índice. A CA assina uma resposta que contém good, revoked e unknown. Primeiro o comando valida o objeto contra o pedido original; depois uma consulta por CertID apresenta os estados individuais. Nesta segunda leitura, -no_nonce evita gerar um novo nonce que não pertence ao pedido anterior, mantendo a verificação da assinatura. Esta opção serve uma comparação delimitada do ensaio, não recomenda desativar nonce indiscriminadamente. Os resultados e as opções completas ficam no ficheiro de evidência.
Distinguir sucesso da ferramenta de aceitação
No OpenSSL 3.6.1 executado, o lote apresenta Response verify OK e termina com código zero, apesar de incluir um certificado revogado e outro desconhecido. Por isso, um script de monitorização que converte apenas zero em autorizado classifica mal o resultado. A resposta pode ser autêntica e comunicar uma recusa. Num caso fictício de APS, corrige primeiro a regra de interpretação e preserva a evidência original. Não apliques o primeiro estado a todos os seriais do lote. Regista cada CertID, a verificação do objeto, os tempos relevantes e o estado comunicado, com conclusão explícita sobre a aceitação.
Verificar origem e correspondência
O probe com wrong-ca.pem falha na verificação da resposta. Outro probe usa um pedido novo, com nonce diferente, e observa Nonce Verify error. Finalmente, uma resposta que só contém good.pem é consultada para revoked.pem: a assinatura verifica, mas o estado procurado está ausente. Cada caso testa uma condição distinta. Não interpretes conteúdo legível como fonte autorizada nem transfiras good entre certificados da mesma CA. A prova de nonce cobre o modo usado neste laboratório; outros perfis e clientes exigem avaliação própria. O objetivo é reconhecer exatamente qual condição foi demonstrada e qual ficou por cumprir.
Conservar a dimensão temporal
A resposta contém informação temporal para o estado comunicado. thisUpdate identifica quando esse estado era conhecido; nextUpdate delimita a disponibilidade prevista de informação mais recente, quando presente. producedAt refere-se à produção da resposta e não deve ser usado para prolongar arbitrariamente um estado antigo. A política deve definir atualidade e tolerâncias de relógio compatíveis com o serviço. Este laboratório imprime tempos de respostas atuais; não executa cache HTTP, envelhecimento de respostas OCSP ou todos os perfis possíveis. Para um consumidor real, acrescenta testes representativos de expiração, atualização falhada e comportamento quando falta informação aceitável.
Preparar recuperação com confiança atual
Num incidente fictício, a chave privada foi exposta, o certificado revogado e o novo par está em preparação. O rollback antigo repõe precisamente o segredo comprometido. Esse plano precisa de revisão: a recuperação deve usar material aprovado e excluir o par exposto. Publicar revogação também não demonstra que as ligações já abertas terminaram ou foram revalidadas. Identifica operações em curso, responsáveis por contenção e critérios de continuidade. A decisão de risco deve ser documentada sem transformar indisponibilidade de OCSP em good. Um resultado offline não autoriza automaticamente a mudança no caminho de produção.
Entregar uma conclusão proporcional à prova
Usa a grelha abaixo numa simulação de reunião em inglês. Uma equipa apresenta o estado por certificado; outra pergunta pela cadeia, identidade, tempos e caminho efetivamente executado. Se o projeto inclui stapling num balanceador ou responder delegado, mantém essas provas separadas: este ensaio só processa ficheiros e usa a própria CA para assinar. A aceitação funcional do batch também exige observação própria. Fecha apenas a etapa que foi demonstrada e atribui responsáveis e critérios às restantes. O exercício é proposto para estudo; não houve workshop humano nem revisão independente por especialista.
PROPOSED REVOCATION HANDOVER
Certificate: issuer identity, serial / CertID, intended service name.
Object: source, public artifact hash, signature/trust result.
Time: thisUpdate / lastUpdate, nextUpdate, verifier clock, policy.
Status: good / revoked / unknown / unavailable / not applicable.
Observation: exact command, runtime version, exit code AND content.
Impact: affected consumers, batch operations, existing connections.
Recovery: approved material, owner, trigger, acceptable rollback.
Acceptance: positive control, negative controls, functional result.
Outstanding: representative TLS path, refresh/cache, delegated responder,
full-chain coverage, session policy and production integration.
Statement: Fourteen offline CRL/OCSP groups passed; these results do not
establish production stapling or existing-session enforcement.
No human workshop has been performed.
Exercício: o dashboard diz verde, mas o lote contém revoked e unknown. Reescreve o estado do incidente, identifica a regra errada e propõe provas de recuperação sem prometer integração ainda não executada.
Armadilhas comuns
Usar exitCode=0 como autorização, transferir good para outro leaf, ignorar tempos, restaurar chave comprometida ou declarar stapling validado por uma leitura offline.
Tópicos relacionados: Identidade, nome e tempo · Revogação e transição de confiança · Ativação, contextos e ligações existentes
Autenticidade, correspondência, atualidade e estado são condições próprias. O handover deve ligar cada conclusão à prova e manter explícito o trabalho ainda necessário.
Referência: OpenSSL ocsp: local request and response processing · DR TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics