CRL vs OCSP é a questão de como uma parte confiável (relying party, RP) fica sabendo que um certificado foi revogado antes de expirar. Uma lista de certificados revogados (RFC 5280 §5) é uma lista assinada de números de série revogados que os clientes baixam; o Online Certificate Status Protocol (OCSP, RFC 6960) responde a uma consulta sobre um único certificado. Na PKI pública da web, a resposta mudou de forma decisiva desde 2024: as CRLs se tornaram obrigatórias, o OCSP passou a ser opcional e a maior CA desligou o OCSP.
Visão geral
| CRL | OCSP | |
|---|---|---|
| Especificação | RFC 5280 §5 | RFC 6960 (nonce: RFC 8954) |
| O que o cliente recebe | Lista assinada de todos os números de série revogados em um escopo | Status assinado (good, revoked, unknown) de um único número de série |
| Tamanho (medido em 20/10/2026) | Fragmento de CRL da Let’s Encrypt com 62.116 bytes e 1.591 entradas | Resposta OCSP da DigiCert com 471 bytes |
| Atualidade | De thisUpdate a nextUpdate (nesse fragmento: 9 dias) | Validade da resposta (nessa resposta: 7 dias) |
| Privacidade | O servidor só fica sabendo que uma CRL foi baixada | O respondedor fica sabendo qual site o cliente está visitando |
| Dependência de disponibilidade | Pode ser armazenada em cache, espelhada e pré-carregada | Depende do respondedor em tempo real, a menos que haja stapling |
| Regra da Web PKI (Baseline Requirements) | Obrigatória desde 15 de março de 2024; nova CRL pelo menos a cada 4 dias (7 se todos os certificados tiverem uma URL de OCSP) e em até 24 horas após uma revogação | Opcional desde 15 de março de 2024 |
| Uso pelos navegadores | Agregada: CRLite no Firefox, CRLSets no Chrome | O Firefox deixou de consultar para certificados DV (versão 142); o Chrome não consulta para a maioria dos certificados |
| Entrega pelo servidor | Não se aplica | OCSP stapling (status_request, RFC 6066) |
Como cada um funciona
Uma CRL indica o emissor, traz thisUpdate e nextUpdate, um número de CRL monotonicamente crescente e uma entrada por certificado revogado (número de série, data da revogação e, opcionalmente, o motivo) e é assinada pela CA. Os certificados apontam para a CRL correspondente na extensão CRL Distribution Points; as CAs grandes dividem as CRLs em fragmentos para que cada arquivo continue com um tamanho administrável, e as CAs públicas divulgam o conjunto completo de URLs de CRL no CCADB para que os agregadores possam coletar todas as revogações. Os clientes que verificam CRLs as baixam e as armazenam em cache, e as CRLs delta (RFC 5280 §5.2.4) podem reduzir o tráfego no caso de listas grandes.
Um cliente OCSP envia o hash do nome do emissor, o hash da chave do emissor e o número de série para a URL indicada na extensão Authority Information Access do certificado; o respondedor retorna um status assinado com sua própria janela de validade. As respostas podem ficar em cache até nextUpdate, e os servidores podem fazer o stapling de uma resposta recente no handshake TLS, para que os clientes não precisem contatar a CA.
As medições acima foram feitas nos serviços em produção: um certificado da Let’s Encrypt emitido em setembro de 2026 aponta apenas para http://ye2.c.lencr.org/96.crl (sem URL de OCSP), e esse fragmento tinha 62 KB; um certificado da DigiCert ainda traz http://ocsp.digicert.com, cuja resposta tinha 471 bytes.
Por que o OCSP perdeu espaço na web
Três propriedades inviabilizaram o OCSP em tempo real nos navegadores. Privacidade: cada consulta informa à CA qual site um usuário está visitando e a partir de qual endereço IP. Disponibilidade: um respondedor lento ou inacessível ou bloqueia o carregamento das páginas ou, como os navegadores optaram pela falha permissiva (soft-fail), é ignorado silenciosamente — ou seja, um atacante capaz de bloquear o respondedor anula a verificação. Custo: os respondedores precisam atender a cada carregamento de página na internet. O stapling resolveu a privacidade e o custo, mas dependia de todos os servidores renovarem as respostas de forma confiável, e só o Firefox oferecia suporte ao Must-Staple (RFC 7633), que permitiria exigir o stapling.
O CA/Browser Forum respondeu com a votação SC-063 (em vigor desde 15 de março de 2024): CRLs obrigatórias, OCSP opcional. A Let’s Encrypt removeu as URLs de OCSP dos novos certificados e deixou de aceitar pedidos com Must-Staple em 7 de maio de 2025, e desligou seus respondedores em 6 de agosto de 2025. O Firefox ativou o CRLite para todos os usuários de desktop na versão 137: uma codificação local compacta de todas as revogações entre os certificados registrados nos logs de CT, atualizada a cada 12 horas, com uma média de cerca de 300 kB baixados por dia. Depois, o Firefox 142 deixou de fazer consultas OCSP para certificados validados por domínio. O Chrome conta com os CRLSets, um conjunto selecionado com foco em revogações de alto impacto, em vez de consultas por site.
A terceira opção: certificados de curta duração
Um certificado válido por alguns dias dispensa a verificação de revogação: quando uma revogação chegasse a se propagar, ele já teria expirado. Os Baseline Requirements permitem que as CAs omitam as informações de revogação em certificados de curta duração (no máximo 7 dias para os emitidos a partir de 15 de março de 2026), e a Let’s Encrypt oferece certificados de 160 horas pelo perfil ACME shortlived desde janeiro de 2026. Somada à redução geral da vida útil para 47 dias até 2029 (votação SC-081v3), a revogação está deixando de ser o controle principal e passando a ser uma rede de segurança. A calculadora de vida útil de certificados mostra os limites por data de emissão.
Quando escolher cada um
- Servidores TLS públicos: não é preciso fazer nada especial; confirme que os certificados vêm de uma CA que publica CRLs e não ative o Must-Staple. Remova configurações de stapling que falham quando não existe URL de OCSP.
- Software cliente que verifica certificados públicos: use o verificador da plataforma; ele aplica os conjuntos de revogação dos fabricantes de navegadores quando estão disponíveis.
- PKI privada com muitos clientes, alguns offline: CRLs com
nextUpdatecurto, servidas por HTTP de alta disponibilidade. - PKI privada com certificados de alto valor e clientes online: OCSP, com stapling onde o protocolo oferecer suporte, e políticas de falha restritiva (hard-fail) se o respondedor estiver sob seu controle.
- Identidades de cargas de trabalho e de serviços: certificados de curta duração (de horas a dias) emitidos automaticamente, sem nenhuma infraestrutura de revogação.
- Assinatura de código e de documentos: a revogação continua importante para assinaturas de longa duração; combine CRLs ou OCSP com carimbos do tempo para que os verificadores possam conferir o status no momento da assinatura.
Notas de migração
- Faça um inventário do que depende do OCSP: configuração de stapling nos servidores, clientes que falham de forma restritiva (hard-fail) sem OCSP, monitoramento que verifica os respondedores.
- Torne o stapling opcional: o nginx e o Apache não devem se recusar a iniciar quando um certificado não tem URL de OCSP.
- Em CAs privadas, publique CRLs primeiro: adicione pontos de distribuição de CRL aos novos certificados, divida as listas grandes em fragmentos, defina
nextUpdatede acordo com o SLA de revogação e disponibilize as CRLs por HTTP (não por HTTPS, para evitar dependências circulares). - Reduza a vida útil dos certificados onde a automação permitir; cada redução diminui o peso que a revogação precisa carregar.
- Teste a revogação de ponta a ponta: revogue um certificado de teste e confirme que os clientes passam a rejeitá-lo dentro do prazo esperado. O decodificador de CRL e o decodificador de OCSP mostram o que os clientes vão ver.