Durante duas décadas, o protocolo OCSP foi a forma padrão de um navegador perguntar a uma autoridade certificadora “este certificado ainda é válido?”. Em agosto de 2025 essa pergunta mudou de resposta. A Let’s Encrypt, a maior emissora de certificados gratuitos do mundo, desligou os seus servidores OCSP e passou a apostar em CRLs, Certificate Transparency e certificados de vida curta.
A mudança não ficou isolada. O CA/Browser Forum já aprovou um calendário que reduz a validade máxima de um certificado SSL/TLS de 398 dias para apenas 47 dias até março de 2029. Quem gere servidores, lojas online ou aplicações empresariais em Portugal vai sentir o impacto direto desta transição nos próximos meses. Este artigo compara OCSP, CRL e Certificate Transparency ponto a ponto, com dados, preços e um guia prático de migração, um tema que se junta a outras mudanças recentes na área de cibersegurança que exigem atenção imediata de quem gere infraestrutura.
Durante anos, qualquer discussão sobre segurança de certificados centrou-se quase sempre em dois temas: o algoritmo de cifra usado e a validade do protocolo TLS 1.3 vs TLS 1.2 vs TLS 1.0. A revogação ficou esquecida, tratada como um detalhe de infraestrutura que raramente aparecia numa auditoria de segurança. Isso mudou por completo em 2025 e 2026, à medida que a maior CA pública do mundo decidiu simplesmente desligar o mecanismo mais antigo, e o CA/Browser Forum aprovou a redução de validade mais agressiva da história do protocolo HTTPS.
O Que é a Revogação de Certificados SSL/TLS
Um certificado SSL/TLS garante que um site é quem diz ser. Mas certificados podem ser comprometidos antes de expirar: uma chave privada roubada, um erro de emissão ou uma empresa que muda de domínio são motivos suficientes para revogar um certificado antes do tempo. A revogação existe exatamente para isso, avisar os navegadores de que um certificado já não deve ser confiado, mesmo que a data de expiração ainda não tenha chegado.
O problema é verificar essa revogação sem atrasar cada ligação HTTPS e sem expor a privacidade de quem navega. É aqui que entram os três mecanismos deste artigo. Já explicámos os fundamentos do protocolo em HTTPS e TLS: o que o cadeado protege (e o que não protege), mas a revogação ficou sempre em segundo plano, até agora.
Cada mecanismo resolve este problema de forma diferente. O OCSP pergunta em tempo real. A CRL distribui uma lista inteira de certificados revogados. A Certificate Transparency nem revoga nada, mas ajuda a detetar emissões indevidas antes que causem dano. Juntos, formam o esqueleto da confiança pública na internet.
Porque os Mecanismos de Revogação Existem
Para entender porque a indústria constrói sistemas inteiros à volta de revogação, ajuda recordar dois incidentes que marcaram a história da PKI pública. Em 2011, a autoridade certificadora holandesa DigiNotar foi invadida e emitiu centenas de certificados fraudulentos, incluindo para domínios da Google, um caso que levou vários navegadores a remover permanentemente a confiança na empresa. Em 2014, a vulnerabilidade Heartbleed no OpenSSL expôs chaves privadas de milhares de servidores em todo o mundo, obrigando administradores a revogar e substituir certificados em massa.
Estes dois episódios mostram as duas faces do problema. DigiNotar é um caso de emissão fraudulenta, resolvido hoje principalmente por Certificate Transparency, que torna impossível emitir um certificado sem deixar rasto público. Heartbleed é um caso de compromisso de chave privada em massa, resolvido pela combinação de revogação rápida e, mais recentemente, por validades cada vez mais curtas que limitam o estrago possível. Compreender esta distinção ajuda a explicar porque nenhum dos três mecanismos deste artigo, por si só, resolve todo o problema de confiança da internet.
OCSP Explicado: Como Funciona o Protocolo de Verificação em Tempo Real
O Online Certificate Status Protocol nasceu nos anos 90 para resolver um problema simples: perguntar diretamente à autoridade certificadora se um certificado específico ainda é válido, em vez de descarregar uma lista enorme de revogações. O navegador envia o número de série do certificado ao servidor OCSP da CA e recebe uma resposta assinada digitalmente, válido, revogado ou desconhecido.
A limitação mais citada do OCSP sempre foi a privacidade. Cada consulta revela à autoridade certificadora exatamente qual site o utilizador está a visitar, porque o certificado identifica o domínio. A Let’s Encrypt usou este argumento como justificação central para desligar o serviço, descrevendo a infraestrutura antiga como algo que “não tornava ninguém mais seguro”, segundo o relato publicado no blogue técnico Crawlex sobre OCSP stapling e revogação.
Além da privacidade, há o problema do chamado “soft-fail”. Quando um responder OCSP está em baixo ou demora a responder, a maioria dos navegadores simplesmente ignora a verificação e deixa a ligação passar. Isto significa que, na prática, um atacante que consiga bloquear o tráfego para o responder OCSP consegue também neutralizar a revogação. É uma falha de design conhecida há mais de dez anos e que nunca foi totalmente resolvida.
Durante muito tempo, a alternativa ao soft-fail seria o chamado “hard-fail”, bloquear a ligação sempre que a verificação OCSP falhasse. Nenhum navegador popular adotou esta política por omissão, porque uma simples instabilidade de rede no responder da CA passaria a derrubar o acesso a milhões de sites ao mesmo tempo. Foi exatamente este dilema sem boa saída, entre aceitar o risco de segurança do soft-fail ou aceitar o risco de disponibilidade do hard-fail, que empurrou toda a indústria a procurar alternativas fora do OCSP.
CRL Explicado: As Listas de Revogação Que Nunca Morreram
A Certificate Revocation List é o mecanismo mais antigo dos três e, ironicamente, o que está a ganhar terreno em 2026. Uma CRL é simplesmente um ficheiro assinado pela autoridade certificadora com os números de série de todos os certificados que revogou. O cliente descarrega o ficheiro periodicamente e consulta-o localmente, sem precisar de perguntar nada em tempo real.
Durante anos, as CRLs foram criticadas por um motivo prático: ficheiros grandes. A DigiCert já recomendava às autoridades certificadoras que distribuíssem várias CRLs menores em vez de uma única lista gigante, precisamente para reduzir o peso do download, segundo o artigo “How Short-Lived Certificates Improve Certificate Trust” da própria DigiCert. Não existe um tamanho padrão de CRL, e esse é parte do motivo pelo qual Chrome e Firefox evitam descarregar CRLs brutas diretamente.
Em vez disso, os navegadores construíram as suas próprias versões comprimidas e curadas. É essa adaptação, e não a CRL tradicional, que hoje protege a maioria dos utilizadores finais. A Let’s Encrypt passou a emitir URLs de ponto de distribuição de CRL em todos os certificados novos a partir de 7 de maio de 2025, substituindo a antiga URL de OCSP.
Há também uma distinção técnica importante entre CRLs completas e CRLs parciais, por vezes chamadas de delta CRLs. Uma lista completa contém todos os certificados revogados desde sempre por aquela autoridade certificadora. Uma lista parcial contém apenas as revogações mais recentes, reduzindo o peso do ficheiro a descarregar em cada atualização. A maioria das autoridades certificadoras públicas optou por este modelo fragmentado precisamente para evitar o problema de escala que afastou os navegadores das CRLs brutas durante tanto tempo.
Certificate Transparency e Certificados de Vida Curta: a Terceira Via
A Certificate Transparency não verifica revogação. Faz algo diferente e complementar: obriga todas as autoridades certificadoras públicas a registar cada certificado emitido num conjunto de logs públicos e auditáveis. Qualquer pessoa pode pesquisar esses logs através de ferramentas como o crt.sh, operado pela Sectigo, para descobrir se alguém emitiu um certificado indevido para o seu domínio.
No início de 2026 existiam entre 30 e 40 shards de logs CT ativos, operados por nomes como Google, Cloudflare, Let’s Encrypt e Sectigo, de acordo com o artigo “Open Season: Certificate Transparency” do THOR Collective Dispatch. Cada entrada combina o certificado com metadados que permitem auditoria pública, tornando praticamente impossível emitir um certificado fraudulento sem deixar rasto.
A outra peça da equação é o certificado de vida curta. Em vez de revogar um certificado comprometido, a ideia é simplesmente deixar que ele expire sozinho, rápido. A Let’s Encrypt já oferece certificados opcionais com apenas 6 dias de validade a todos os subscritores, segundo a documentação oficial em “Certificate Lifetime Rationale and Plans”. O CA/Browser Forum define formalmente como “vida curta” qualquer certificado válido por 7 dias ou menos, isentando-o das regras normais de disponibilidade de OCSP e CRL.
Cada certificado também transporta, cada vez mais, um ou mais Signed Certificate Timestamps, provas criptográficas de que foi submetido a um log de Certificate Transparency. Estes SCTs podem chegar ao navegador de três formas: embutidos diretamente no certificado, entregues durante o handshake TLS, ou associados à resposta OCSP através de stapling, segundo a explicação da Fastly em “Improve CA ops visibility with Cert Transparency”. Na prática, a forma embutida tornou-se amplamente dominante, o que reduz ainda mais a dependência de qualquer pedido de rede em tempo real durante a navegação normal.
OCSP vs CRL vs CT: Tabela Comparativa Completa
A tabela seguinte resume os dez elementos mais relevantes do ecossistema de revogação em 2026, incluindo as variantes que os navegadores realmente usam no dia a dia.
| Mecanismo | O Que Verifica | Pedido em Rede? | Risco de Privacidade | Quem Usa em 2026 | Estado Atual |
|---|---|---|---|---|---|
| OCSP clássico | Estado de 1 certificado | Sim, por certificado | Alto | Cada vez menos CAs públicas | Desligado pela Let’s Encrypt a 6 ago 2025 |
| OCSP Stapling | Resposta OCSP pré-carregada no handshake | Não (cache no servidor) | Baixo | Popularizado pela Cloudflare | Cada vez menos necessário sem OCSP ativo |
| Must-Staple | Exige stapling por extensão X.509 | Depende do emissor | Variável | Contas antigas da Let’s Encrypt | Emissão nova bloqueada desde 30 jan 2025 |
| CRL tradicional | Lista completa de revogados | Não, download periódico | Baixo | Todas as CAs públicas desde maio 2025 | Obrigatória nos certificados Let’s Encrypt atuais |
| CRLSet | Subconjunto curado de revogações críticas | Não, via update do browser | Baixo | Google Chrome | Mecanismo principal do Chrome |
| CRLite | Estrutura comprimida baseada em CT | Não, local no browser | Baixo | Mozilla Firefox | Mecanismo principal do Firefox |
| Certificados de vida curta | Expiração rápida substitui revogação | Não aplicável | Nenhum | Opcional em contas Let’s Encrypt (6 dias) | Isento das regras normais de OCSP/CRL |
| Certificate Transparency | Deteção de emissão indevida, não revogação | Consulta pública a logs | Nenhum | Google, Cloudflare, Let’s Encrypt, Sectigo | 30 a 40 shards ativos no início de 2026 |
| crt.sh | Motor de pesquisa sobre logs CT | Pesquisa manual ou API | Nenhum | Operado pela Sectigo | Ferramenta gratuita de monitorização |
| SC-081v3 (validade) | Reduz a janela máxima de exposição | Não aplicável | Não aplicável | Toda a indústria via CA/Browser Forum | 398 a 47 dias entre 2026 e 2029 |
Porque a Let’s Encrypt Desligou o OCSP em Agosto de 2025
A transição da Let’s Encrypt seguiu três fases bem documentadas. A 30 de janeiro de 2025, a emissão de novos certificados com a extensão Must-Staple ficou restrita a contas que já tinham usado essa funcionalidade antes. A 7 de maio de 2025, os certificados novos deixaram de conter URLs de responder OCSP e passaram a incluir URLs de ponto de distribuição CRL. Finalmente, a 6 de agosto de 2025, os responders OCSP foram desligados por completo.
Esta sequência só foi possível porque os certificados da Let’s Encrypt já têm uma validade curta, 90 dias. Quando chegou a 6 de agosto, praticamente todos os certificados antigos com URL de OCSP já tinham expirado naturalmente, o que evitou quebras em massa. É uma lição de automação: quem gere certificados de forma manual sentiu muito mais atrito nesta transição do que quem usa renovação automática via ACME, como descrevemos em HTTPS no Nginx com Let’s Encrypt em 12 passos.
A Let’s Encrypt é hoje descrita como a maior autoridade certificadora do mundo por volume de certificados emitidos, segundo a análise da Encryption Consulting em “Post-Quantum OCSP and CRL Design”. O peso desta CA específica na decisão de abandonar o OCSP ajuda a explicar porque o resto da indústria seguiu o mesmo caminho quase sem resistência pública.
SC-081v3: O Calendário Que Leva os Certificados a 47 Dias
Enquanto a revogação mudava de mecanismo, o CA/Browser Forum aprovava, em abril de 2025, a Ballot SC-081v3. A proposta, inicialmente levantada pela Apple e depois apoiada pela Sectigo, reduz a validade máxima de um certificado TLS publicamente confiável de 398 dias para 47 dias, num processo gradual com quatro fases distintas.
| Data de Emissão do Certificado | Validade Máxima | Reutilização de Validação de Domínio |
|---|---|---|
| Antes de 15 de março de 2026 | 398 dias | 398 dias |
| 15 março 2026 a 14 março 2027 | 200 dias | 200 dias |
| 15 março 2027 a 14 março 2029 | 100 dias | 100 dias |
| A partir de 15 de março de 2029 | 47 dias | 10 dias |
Esta tabela explica por si só porque a revogação clássica está a perder importância. Quanto menor a validade de um certificado, menor a janela em que uma chave comprometida pode ser abusada sem ser automaticamente invalidada pela simples passagem do tempo. Um certificado de 47 dias que seja roubado expira sozinho em pouco mais de um mês e meio, mesmo sem qualquer ação de revogação.
É também por isso que o calendário SC-081v3 e os certificados de vida curta opcionais da Let’s Encrypt (6 dias) apontam na mesma direção: encurtar o tempo de vida do certificado em vez de confiar em sistemas de revogação que sempre tiveram falhas conhecidas de latência e privacidade.
Benchmarks de Desempenho: o Que os Dados Independentes Mostram
Os números de desempenho nesta área são difíceis de comparar diretamente, porque dependem da localização do utilizador, do estado da cache e da existência ou não de uma CDN a servir o responder. Mesmo assim, três fontes independentes de 2025 e 2026 dão uma imagem clara do problema que o OCSP sempre teve.
| Métrica | Valor Medido | Fonte |
|---|---|---|
| Pedidos OCSP com resposta abaixo de 18 ms (percentil 85, com CDN) | <18 ms | Bhowmick et al., estudo académico 2025 |
| Sites do top 100 mil com atraso igual ou superior a 100 ms por verificação OCSP (medição desde Sydney) | 51,9% | Bhowmick et al., estudo académico 2025 |
| Ligações TLS afetadas pela verificação OCSP quando o responder tem apoio de CDN | 43,32% | Bhowmick et al., estudo académico 2025 |
| Ligações TLS afetadas pela verificação OCSP sem apoio de CDN | 91,93% | Bhowmick et al., estudo académico 2025 |
| Shards de logs Certificate Transparency ativos no início de 2026 | 30 a 40 | THOR Collective Dispatch, 2026 |
| Meta de disponibilidade global definida pela DigiCert para artefactos de confiança (CT, OCSP e CRL) | Abaixo de 100 ms | DigiCert, whitepaper “Upgrading WebPKI for 10X Scale”, 2026 |
O dado mais revelador é a diferença entre 43,32% e 91,93%. Mostra que, sem uma rede de distribuição de conteúdo a acelerar o responder OCSP, quase todas as ligações TLS pagam algum custo de latência pela verificação. Com CDN, esse número cai para menos da metade, mas continua a afetar quase meio dos acessos. Nenhuma das três fontes publicou um número direto de “OCSP demora X ms, CRL pesa Y MB” comparável de forma simples, e qualquer artigo que apresente esse tipo de número sem citar origem deve ser lido com desconfiança.
Para quem aloja sites fora de uma grande CDN, como acontece com muitas pequenas e médias empresas portuguesas que usam alojamento partilhado nacional, este dado tem um peso prático direto. Significa que, enquanto o OCSP ainda estava ativo, esses sites tendiam a sofrer mais atraso por verificação de revogação do que sites equivalentes atrás da Cloudflare ou de outra rede global. A transição para CRLs curadas pelo navegador remove essa desigualdade, porque a verificação passa a ser local, independentemente de o site ter ou não uma CDN própria.
Preços: Quanto Custa Cada Abordagem em 2026
A revogação em si não tem preço direto para o cliente final, o custo de manter responders OCSP ou publicar CRLs é suportado pela autoridade certificadora. Mas a escolha de fornecedor determina se a automação via ACME, essencial para sobreviver ao calendário de 47 dias, está disponível de origem ou é uma funcionalidade paga.
| Fornecedor | Suporte ACME/Automação | Certificados de Vida Curta | Preço |
|---|---|---|---|
| Let’s Encrypt | Nativo, criado para isto | Sim, opcional, 6 dias | $0 |
| ZeroSSL | Sim, inclusive no plano gratuito | Via ACME, 90 dias por omissão | $0 a $219,99/mês nos planos Platinum |
| SSL.com | ACME disponível em planos pagos | Não confirmado publicamente | $36,75 a $319,20/ano, dependendo do tipo (DV, OV, EV) |
O detalhe que mais importa aqui não é o preço do certificado, é a presença de automação. Um certificado gratuito mas gerido manualmente vai custar mais em horas de trabalho do que um certificado pago com renovação automática embutida, à medida que os ciclos de validade encurtam para 100 e depois 47 dias. Já tínhamos discutido o equilíbrio entre gratuito e pago em Let’s Encrypt vs SSL Pago, mas o calendário SC-081v3 muda o peso dessa decisão: a automação deixou de ser um luxo.
O Que Isto Significa Para Empresas em Portugal
Para equipas de TI em Portugal, esta transição chega ao mesmo tempo que o regime jurídico da cibersegurança (NIS2) exige processos documentados de gestão de risco a milhares de empresas. Segundo o enquadramento que já analisámos em NIS2 Portugal: 9.000 empresas abrangidas, coimas até 10 milhões de euros, entidades essenciais e importantes precisam de demonstrar controlo sobre a gestão do ciclo de vida de certificados, não apenas sobre a existência de HTTPS.
Um certificado gerido manualmente, sem automação ACME, torna-se um risco de conformidade à medida que o calendário SC-081v3 avança. Uma empresa que hoje renova certificados uma vez por ano vai precisar de o fazer quase duas vezes por mês a partir de 2029. Sem automação, isso significa multiplicar por mais de oito o número de operações manuais de renovação, com o respetivo risco de esquecimento, expiração e queda de serviço. Equipas de TI portuguesas que ainda gerem este processo à mão deveriam tratar 2026 como o ano para migrar definitivamente para ACME, não como mais um ano de adiamento.
Como Chrome, Firefox e Safari Tratam a Revogação Hoje
Nenhum dos três grandes navegadores depende de um pedido OCSP em tempo real para a maioria das ligações HTTPS do dia a dia. O Chrome usa o CRLSet, um subconjunto de revogações que o Google considera de alto impacto, comprimido e distribuído através das próprias atualizações do navegador. Não é uma cópia completa de todas as CRLs emitidas por todas as CAs, é uma seleção curada daquilo que a Google decide ser suficientemente grave para merecer distribuição imediata.
A Mozilla segue uma filosofia diferente com o CRLite, associado principalmente ao Firefox. Em vez de uma lista curada, o CRLite constrói uma estrutura de dados probabilística com cobertura muito mais ampla, construída a partir dos próprios dados de Certificate Transparency. O resultado é uma verificação local, rápida e sem pedido de rede durante o handshake.
A Safari da Apple manteve-se historicamente mais discreta sobre o seu mecanismo exato, embora a própria Apple tenha sido a autora original da proposta que se tornou a Ballot SC-081v3, o que mostra o peso que a empresa tem na definição das regras gerais da indústria mesmo sem detalhar publicamente a sua implementação de revogação. Para o utilizador final, a consequência prática é simples: uma falha num responder OCSP isolado já não derruba o acesso a um site como aconteceria há uma década.
7 Casos Reais: Quem Está a Mudar e Porquê
Estes sete exemplos mostram como organizações concretas estão a lidar com a transição, com datas e decisões documentadas publicamente. Vale notar que nenhuma destas empresas agiu isoladamente, todas fazem parte do mesmo processo de padronização coordenado pelo CA/Browser Forum, o que explica porque a mudança avançou tão rápido entre 2025 e 2026 sem gerar uma fragmentação visível entre navegadores.
- Let’s Encrypt: desligou o OCSP a 6 de agosto de 2025 e tornou-se a primeira grande CA pública a oferecer certificados de vida curta de 6 dias como alternativa direta à revogação tradicional.
- Google Chrome: continua a evitar pedidos OCSP em tempo real na maioria dos casos, apostando no CRLSet distribuído via atualizações automáticas do navegador para mais de um bilião de instalações ativas.
- Mozilla Firefox: usa o CRLite para fazer verificação de revogação totalmente local, sem depender da disponibilidade de um responder externo durante a navegação.
- Apple: foi a autora original, em janeiro de 2025, da proposta que reduz a validade dos certificados para 47 dias, aprovada depois como Ballot SC-081v3 com o apoio da Sectigo.
- DigiCert: publicou em 2026 o whitepaper “Upgrading WebPKI for 10X Scale”, no qual defende a expansão de infraestrutura multi-CDN para garantir que Certificate Transparency, OCSP e CRL continuam a escalar com o crescimento do número de certificados emitidos.
- Sectigo: mantém o crt.sh, a ferramenta gratuita mais usada para pesquisar logs de Certificate Transparency, e apoiou formalmente a redução de validade para 47 dias.
- Cloudflare: popularizou historicamente o OCSP stapling como forma de reduzir a dependência de pedidos em tempo real, uma técnica que continua relevante para quem ainda opera certificados com Must-Staple ativo.
Qual Mecanismo Escolher: 7 Cenários Práticos
A resposta certa depende quase sempre do tipo de infraestrutura e do nível de automação já existente. Estes sete cenários cobrem a maioria das situações reais em Portugal.
- Site institucional simples em WordPress: usar Let’s Encrypt com renovação automática via plugin ou painel de alojamento, sem necessidade de configurar nada relacionado com OCSP.
- Loja online com pagamentos: priorizar automação ACME total e considerar certificados de vida curta de 6 dias para reduzir ao mínimo a janela de exposição em caso de fuga de chave privada.
- Equipas DevOps com centenas de domínios: investir agora em automação, antes do corte para 200 dias em março de 2026, para não serem surpreendidas pelas fases seguintes de 100 e 47 dias.
- PKI interna de empresa (certificados privados): continuar a usar CRLs geridas internamente, já que esta infraestrutura não está sujeita às regras públicas do CA/Browser Forum.
- Aplicações móveis e dispositivos IoT com rede instável: preferir mecanismos locais como CRLite em vez de depender de um pedido OCSP online que falha sem ligação.
- Equipas de segurança e marcas com risco de phishing: monitorizar o crt.sh regularmente para detetar certificados emitidos indevidamente em nome do próprio domínio.
- Bancos e fintechs com requisitos de alta disponibilidade: combinar certificados de vida curta com automação ACME e alertas de Certificate Transparency, tratando a revogação clássica como última linha de defesa, não a primeira.
Guia de Migração: de OCSP Para CRL e Certificados de Vida Curta
Quem ainda depende de configurações antigas de OCSP deve seguir estes passos antes que o próximo corte de validade, em março de 2026, torne a automação obrigatória em vez de opcional. A boa notícia é que a maioria destes passos já é suportada nativamente pelas ferramentas de automação mais comuns, como o Certbot, o acme.sh ou integrações diretas em painéis de alojamento, pelo que o esforço real tende a ser menor do que parece à primeira vista.
- Fazer o inventário de todos os certificados ativos e das respetivas datas de validade.
- Procurar configurações antigas de Must-Staple em servidores Nginx ou Apache e removê-las se o certificado já não suportar OCSP.
- Adotar um cliente ACME como o Certbot ou o Caddy para automatizar emissão e renovação, conforme descrevemos em HTTPS no Nginx com Let’s Encrypt.
- Confirmar que o firewall e o proxy da organização não bloqueiam o acesso aos URLs de ponto de distribuição de CRL incluídos nos certificados novos.
- Planear a transição para o limite de 200 dias que entra em vigor a 15 de março de 2026, idealmente com meses de antecedência.
- Avaliar a ativação de certificados de vida curta de 6 dias nos sistemas já totalmente automatizados, como ambientes de contentores ou balanceadores de carga geridos por infraestrutura como código.
- Configurar monitorização via crt.sh ou uma ferramenta equivalente para o próprio domínio, de forma a detetar emissões não autorizadas.
- Atualizar qualquer sistema interno de alerta que ainda verifique a saúde de um responder OCSP, substituindo-o por verificação de validade de certificado e de disponibilidade da CRL.
Vantagens e Desvantagens de Cada Abordagem
Nenhum dos três mecanismos é perfeito isoladamente. A tabela comparativa já mostrou as diferenças técnicas, mas vale resumir os prós e contras de forma direta, porque é essa síntese que normalmente decide uma arquitetura de certificados numa empresa.
Um erro comum é tratar esta escolha como exclusiva, como se fosse preciso escolher apenas um dos três. Na prática, qualquer site público em 2026 já está a usar uma combinação dos três ao mesmo tempo: um certificado com URL de CRL, visível para auditoria em logs de Certificate Transparency, e cada vez mais próximo de uma validade curta imposta pelo próprio calendário da indústria. A pergunta relevante não é “qual escolher” mas sim “que nível de automação preparar para cada um deles”.
- OCSP: resposta teoricamente em tempo real, mas com custo de privacidade alto e comportamento de soft-fail que um atacante pode explorar. Está a ser abandonado pelas maiores CAs públicas.
- CRL: simples, sem pedido em tempo real e sem expor o domínio visitado à CA, mas historicamente pesada para distribuir sem curadoria, o que levou Chrome e Firefox a criar as suas próprias versões comprimidas.
- Certificate Transparency: excelente para detetar emissão indevida e fraude, mas não substitui a revogação, apenas complementa a deteção.
- Certificados de vida curta: reduzem drasticamente a necessidade de revogar qualquer coisa, mas exigem automação completa, sem margem para renovação manual ou atraso humano.
Veredito: o Futuro da Revogação de Certificados SSL/TLS
O OCSP clássico está a desaparecer do ecossistema público. A Let’s Encrypt já o desligou, o CA/Browser Forum está a reduzir a validade dos certificados a um ritmo que torna a revogação cada vez menos relevante, e os dois navegadores com maior quota de mercado, Chrome e Firefox, há muito que não dependem de pedidos OCSP em tempo real para a maioria dos acessos.
O caminho que os dados apontam é claro: CRLs curadas pelo navegador, Certificate Transparency como camada de deteção e certificados cada vez mais curtos como substituto prático da revogação tradicional. Até março de 2029, qualquer certificado SSL/TLS público vai durar, no máximo, 47 dias. Quem ainda gere certificados manualmente tem pouco mais de dois anos para automatizar esse processo por completo, ou vai simplesmente deixar de conseguir acompanhar o calendário.
Para quem administra infraestrutura hoje, a recomendação prática é direta: tratar a automação via ACME como prioridade imediata, não como projeto para o próximo trimestre. Os prazos de março de 2026, março de 2027 e março de 2029 não vão mudar, e cada fase reduz ainda mais a margem para erro humano.
Vale a pena comparar este momento com outras transições de segurança já vividas pela indústria, como a passagem de SHA-1 para SHA-256 ou a adoção generalizada de mTLS em arquiteturas de microsserviços, que já descrevemos em mTLS em Node.js com TLS 1.3. Em todos estes casos, as organizações que começaram a automatizar cedo passaram pela mudança sem incidentes visíveis, enquanto as que deixaram para a última hora enfrentaram quebras de serviço evitáveis. A revogação de certificados em 2026 segue exatamente o mesmo padrão.
Perguntas Frequentes
O que é OCSP e porque deixou de ser usado pela Let’s Encrypt?
É um protocolo que pergunta em tempo real a uma autoridade certificadora se um certificado ainda é válido. A Let’s Encrypt desligou-o a 6 de agosto de 2025, citando o custo de privacidade de cada consulta, que revela à CA qual site está a ser visitado.
As CRLs não eram consideradas tecnologia antiga? Porque voltaram a ser relevantes?
São antigas, sim, mas resolvem o problema de privacidade do OCSP e não dependem de um pedido em tempo real. Os navegadores modernos usam versões comprimidas e curadas desta ideia, como o CRLSet do Chrome e o CRLite do Firefox.
Os certificados de vida curta, com apenas 6 dias, são seguros?
São considerados mais seguros do ponto de vista de exposição, porque reduzem drasticamente o tempo em que uma chave comprometida pode ser usada antes de o certificado expirar sozinho. Exigem, no entanto, automação total, sem a qual um site fica fora do ar a cada poucos dias.
Certificate Transparency serve para revogar certificados?
Não diretamente. A CT regista publicamente cada certificado emitido, o que permite detetar emissões fraudulentas ou indevidas, mas a revogação em si continua a depender de CRLs ou da expiração natural do certificado.
Quando é que o meu certificado vai passar a durar apenas 47 dias?
Só a partir de 15 de março de 2029. Antes disso há duas fases intermédias: 200 dias a partir de 15 de março de 2026 e 100 dias a partir de 15 de março de 2027, segundo o calendário aprovado na Ballot SC-081v3.
O OCSP stapling ainda faz sentido configurar em 2026?
Cada vez menos. Sem um responder OCSP ativo por detrás, não há resposta para fazer stapling. Para quem já migrou para CAs sem OCSP, como a Let’s Encrypt, a configuração deixa de ter efeito prático.
Como sei se o meu site está preparado para esta mudança?
Verificando se a emissão e a renovação de certificados já são totalmente automatizadas via ACME. Se ainda houver qualquer passo manual no processo, esse é o ponto a corrigir antes do corte de validade de março de 2026.
Isto afeta apenas grandes empresas ou também sites pequenos?
Afeta todos os certificados TLS publicamente confiáveis, independentemente do tamanho do site. A diferença está na preparação: grandes equipas de DevOps já automatizaram este processo há anos, enquanto sites pequenos geridos manualmente vão sentir mais o impacto a cada fase do calendário.
Preciso de pagar por um certificado para ter automação e certificados de vida curta?
Não. A Let’s Encrypt oferece automação ACME nativa e certificados opcionais de 6 dias gratuitamente. Fornecedores pagos como o SSL.com ou o ZeroSSL acrescentam validação de organização, suporte dedicado ou garantias contratuais, mas a automação em si não exige pagamento.
