Online Certificate Status Protocol (OCSP)

OCSP foi criado para evitar o download de listas de revogação inteiras quando o cliente precisa saber o estado de um certificado. A RFC 6960 define mensagens. O cliente constrói CertID com hash do nome do emissor, hash da chave do emissor, número de série e algoritmo de hash. Envia por HTTP GET ou POST ao responder indicado em Authority Information Access. A resposta contém `good`, `revoked` ou `unknown`, tempos como `thisUpdate`, `nextUpdate` quando presente, `producedAt` e assinatura. `good` significa que o responder não conhece revogação do certificado segundo o escopo; não prova que o certificado foi emitido corretamente nem que está dentro da validade. `revoked` inclui horário e pode trazer motivo. `unknown` significa que o responder não tem informação autoritativa. O cliente valida assinatura, certificado do responder, Extended Key Usage `id-kp-OCSPSigning`, cadeia, tempo, CertID e nonce quando usado. A CA pode assinar diretamente ou delegar a um responder com certificado. Esse certificado pode ter extensão `id-pkix-ocsp-nocheck`, reduzindo necessidade de verificar sua revogação, mas exige vida curta e proteção. O relógio é crítico. Respostas podem ser pré-produzidas e cacheadas. O intervalo define frescor. Uma resposta muito antiga não deve ser aceita. A consequência prática é revogar um gateway perdido sem distribuir uma CRL de megabytes a cada cliente.

Na consulta direta, o navegador ou cliente informa ao responder que está validando um certificado, revelando uso e criando uma chamada adicional. OCSP stapling move a consulta para o servidor TLS. O servidor obtém periodicamente uma resposta, armazena e a inclui no handshake pela extensão `status_request`. O cliente valida a assinatura. Isso reduz latência, carga no responder e exposição do cliente. O servidor precisa renovar antes de expirar. Se falha, pode continuar com resposta em cache até limite. TLS 1.3 mantém mecanismos de status. A extensão Must-Staple em certificado pode exigir que o servidor entregue, mas o suporte e comportamento variam. Em serviços internos, stapling é útil se servidores e proxies suportam. Nginx, Apache, HAProxy e alguns brokers podem. A cadeia precisa estar configurada para que o servidor descubra o responder. DNS e acesso de saída. Um erro comum é ativar uma diretiva sem verificar que o stapling realmente aparece. Use `openssl s_client -status`. O servidor deve validar a resposta que cacheia. Não buscar durante cada handshake. Em uma casa, um reverse proxy que termina TLS para Home Assistant pode staplear. Porém, certificados ACME de curta duração e comportamento de clientes podem reduzir a relevância. O desenho não deve tornar serviço local dependente de OCSP externo em cada acesso.

OCSP é online por nome, mas respostas não precisam ser geradas em tempo real. Podem ser cacheadas até `nextUpdate`. A CA escolhe frequência. Frescor curto reduz janela de revogação, aumenta carga. Um responder de alta disponibilidade usa réplicas e CDN. A assinatura permite cache intermediário. GET favorece cache para requisições pequenas. Nonce vincula resposta a uma requisição e reduz replay, mas impede cache eficiente e nem todos os responders suportam. A RFC 8954 atualizou formato e limites do nonce; implementações precisam interoperar. Muitos clientes não enviam nonce em Internet pública. Em PKI privada, pode. O comportamento em indisponibilidade é decisão. Navegadores historicamente usam soft-fail em vários cenários para não permitir que um atacante derrube a navegação bloqueando OCSP. Isso reduz garantia de revogação. Aplicações de alto risco podem hard-fail, mas precisam de responder redundante e stapling. Um controlador de fechadura não deve depender de consulta Internet síncrona. Pode usar gateway local, CRL ou certificado curto. O status deve ser cacheado. O cliente deve distinguir timeout, `tryLater`, `unauthorized`, `malformedRequest`, `unknown` e assinatura inválida. Não transformar tudo em `good`. Logs e métricas. O responder não é um serviço de autenticação; apenas status de certificado.

OCSP não resolve revogação instantânea. Há atraso entre evento, atualização da CA, geração e cache. O estado `good` é limitado. A consulta direta expõe ao operador da CA quais certificados são usados e quando, dependendo do contexto. Stapling reduz. CRL oferece privacidade e operação offline, mas pode ser grande. Certificados de curta duração reduzem necessidade: a credencial expira rapidamente e a emissão contínua é controlada. Para identidades de dispositivo sem conectividade constante, CRL ou lista de autorização local pode ser melhor. Em ecossistemas web, mecanismos proprietários e listas agregadas são usados. O cliente deve seguir sua plataforma. Um responder comprometido ou chave delegada roubada pode produzir respostas falsas dentro do escopo. Proteja em HSM, limite validade e monitore. OCSP também não verifica hostname, EKU, política, validade ou assinatura da cadeia; a validação X.509 completa continua. O termo “good” frequentemente é interpretado errado. Um certificado não emitido pode receber unknown; alguns responders podem responder good por design de escopo. A aplicação precisa consultar a CA correta. O uso de HTTP não significa inseguro: a resposta é assinada. HTTPS pode criar dependência circular para verificar o certificado do responder. Por isso HTTP é comum. Em uma casa inteligente, preferir OCSP quando há conectividade estável, PKI central e necessidade de status granular; preferir CRL/cache para controle local offline.