OCSP contra uma CRL: como cada verificação de revogação realmente funciona

Uma destas duas verificações de revogação devolve uma resposta assinada sobre um único certificado, e a outra devolve uma lista assinada que você baixa por inteiro. Ambas devem dizer a um verificador se uma credencial ainda é confiável, e ambas falham de maneiras que não se parecem em nada. A ordem abaixo segue o que um operador realmente encontra em produção, começando pelos bytes no cabo e terminando numa gateway que recusa uma conexão. Pular uma etapa é a forma como uma implantação termina com uma política de revogação que só existe no papel.

Passo 1: O que cada verificação devolve e por quanto tempo continua utilizável

Uma CRL é publicada como um único objeto assinado que cobre todos os certificados que um emissor revogou, então um verificador a busca uma vez e a reutiliza até o nextUpdate da lista passar. Uma resposta OCSP é mais estreita: responde exatamente por um certificado e carrega thisUpdate, producedAt e normalmente também nextUpdate. Essa diferença governa todo o resto. Uma CRL em cache envelhece em silêncio, porque o arquivo ainda é analisado e a assinatura ainda é verificada, enquanto uma resposta OCSP expirada é obviamente inútil no momento em que você lê os carimbos de tempo.

Por isso o cache é a primeira coisa a fixar: qual componente guarda a cópia, e a que teto essa cópia obedece. Numa gateway o teto deve ser nextUpdate menos uma margem de segurança, nunca o que um cabeçalho de cache HTTP sugira por acaso. openssl crl -in issuer.crl -noout -lastupdate -nextupdate imprime as duas datas, e uma lista cujo nextUpdate já está no passado deve ser tratada como ausente e não apenas como antiga.

Passo 2: Para onde o certificado aponta o cliente

O certificado folha costuma trazer duas pistas: uma extensão de ponto de distribuição de CRL e uma entrada de acesso à informação da autoridade para OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints imprime a primeira, e a segunda fica sob a seção AIA de openssl x509 -in client.pem -noout -text. Qualquer das extensões é um ponteiro, não uma obrigação. Um cliente que nunca implementa a verificação de revogação se conectará perfeitamente a um certificado cujas extensões nomeiam um respondente que está morto há um ano.

Os pontos de distribuição costumam nomear um host interno que só resolve dentro de um segmento de rede, e alguns clientes mais antigos recusam URL ldap de imediato. Teste a alcançabilidade a partir do host que termina o túnel, não do seu próprio laptop, porque esse é o único ponto de vista cuja falha realmente importa.

Passo 3: Escolha fail-closed ou fail-open antes da queda

Um respondente inalcançável ou uma lista expirada forçam uma decisão: recusar a conexão, ou aceitá-la e registrar a lacuna. O subcomando verify do OpenSSL torna a escolha estrita explícita, porque acrescentar -crl_check transforma uma CRL indisponível em unable to get certificate CRL e uma verificação falha. O soft-fail na maioria das pilhas não é uma flag de modo algum, é a ausência da verificação, e é exatamente por isso que chega por acidente.

Para ver que comportamento um cliente realmente tem, retire o respondente e reconecte. Se o túnel ainda subir, encontre a linha de log que registrou a verificação ignorada e pergunte se alguém leria essa linha durante um incidente. O mesmo fornecedor pode diferir por protocolo, com um cliente IKEv2 e um cliente OpenVPN numa máquina lendo ajustes de configuração não relacionados.

Passo 4: Prove que a verificação roda onde o tráfego é admitido

Encontre o processo que termina ou autoriza a conexão e pergunte por qual linha de configuração a verificação de revogação é habilitada. Uma gateway que valida a cadeia mas nunca pergunta sobre revogação aplica uma política diferente da que está na sua documentação, e nenhuma captura de tela de uma cadeia de certificados prova o contrário. O OpenVPN escreve a opção como crl-verify; o strongSwan mantém as buscas de CRL e OCSP sob a configuração da CA, onde crl_uris ou ocsp_uris são definidos. Se não puder apontar nenhuma das duas, suponha que a verificação está ausente.

Uma resposta OCSP só conta quando a CA emissora a assinou, ou quando um respondente com o uso estendido de chave OCSPSigning delegado por essa CA a assinou, então uma resposta de um serviço não relacionado não prova nada. Se você mesmo opera o respondente, monitore-o como dependência rígida, porque um único serviço morto vira uma queda para cada cliente fail-closed de uma vez.

Passo 5: Revogue um certificado de propósito

Pegue um certificado de teste, revogue-o pelo mesmo canal que a produção usa e pergunte diretamente ao respondente. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text deveria reportar Cert Status: revoked junto com um horário de revogação, e uma resposta good significa que sua revogação não chegou ao respondente que seus clientes consultam. Depois execute openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem para ver a mesma decisão pelo caminho da lista. Leia a string do motivo em vez do código de saída, porque uma recusa por revogação e um erro de cadeia terminam ambos em falha.

O passo que realmente importa é o último: reconecte com o perfil antigo contra o ponto de aplicação real e confirme que a recusa vem da revogação. Depois reconecte com um certificado novo e válido para provar que você não apenas quebrou o ouvinte. Apagar o perfil no cliente não prova nada sobre a decisão do servidor, e uma execução bem-sucedida de openssl verify numa máquina que nunca termina um túnel também não. RFC 6960 define o que uma resposta OCSP conforme contém, incluindo os valores de status que este teste lê.