Cloudflare quer virar CA diante da concentração das CAs gratuitas

A Cloudflare depende há anos de 16 CAs públicas parceiras sem nunca ter emitido ela mesma um certificado de confiança pública. Agora pretende se tornar uma, e o interessante é o projeto: certificados clássicos e Merkle Tree Certificates sob uma única CA, com contenção de falhas embutida desde o início.

Uma consumidora de certificados vira emissora #

A maioria das empresas de infraestrutura fica de um só lado da relação com certificados. Elas pedem certificados, instalam e reclamam quando uma CA tem um incidente. A Cloudflare esteve firmemente do lado do consumo. Pelo seu próprio relato, nunca emitiu ela mesma um único certificado de confiança pública.

Isso está prestes a mudar, ou pelo menos a Cloudflare diz que pretende que mude. A empresa anuncia a intenção de se tornar uma autoridade certificadora pública. O anúncio é cuidadoso sobre onde as coisas estão hoje, e este artigo também deve ser. A Cloudflare ainda não emite certificados. Tudo sobre o comportamento do serviço, da interface ACME às regras de renovação e ao suporte a Merkle Tree Certificates, é uma declaração de planos e não a descrição de um sistema em funcionamento.

O que dá credibilidade ao anúncio não é a ambição, e sim o trabalho preparatório já visível. A Cloudflare pediu inclusão nos programas raiz do Chrome, da Apple, da Microsoft e da Mozilla. Ela diz que está percorrendo o processo de candidatura e aprovação com cada um dos principais programas de chaves raiz da web, e observa que esses processos acontecem de forma pública. Qualquer pessoa pode, em princípio, acompanhar se a candidatura terá sucesso.

Por que a Cloudflare está em posição de levantar a questão #

O argumento da Cloudflare para criar uma CA começa pela sua posição como cliente. Ela fica à frente de mais de 20 por cento do tráfego global de requisições da Internet. Ela termina TLS para milhões de domínios e depende de milhões de certificados por ano. Fornece pacotes de certificados aos clientes via Universal SSL, e também consome certificados de muitas CAs diferentes para operar os próprios sistemas e operações internas.

Para manter os serviços dos clientes no ar, a Cloudflare obtém esses certificados por meio de várias CAs, com caminhos principais e de reserva, para que os serviços continuem funcionando em quedas de CAs e em eventos de revogação. A rede de CAs públicas parceiras em que ela se apoia há muitos anos soma 16.

O mecanismo de reserva merece um olhar mais atento, porque mostra como a Cloudflare pensa sobre falhas. Todo certificado Universal SSL já vem com um certificado de reserva, protegido por uma chave separada e emitido por outra autoridade. Se o principal for revogado ou comprometido, o de reserva está pronto para ser implantado automaticamente. É uma proteção contra a falha de qualquer CA isolada, construída do lado do cliente da relação.

É também uma proteção com teto. Só é possível diversificar entre as CAs que existem, e a fonte argumenta que a oferta de CAs capazes é mais rala do que parece.

O problema da concentração #

Os números por trás desse argumento impressionam. O Let's Encrypt emite na casa de dez milhões de certificados por dia. Atende mais de 500 milhões de sites e passou de quatro bilhões de certificados ativos em 2025. São números de uma única CA gratuita, e descrevem uma web cuja criptografia depende fortemente de uma só organização.

A fonte tira a conclusão óbvia, com uma ressalva adequada: se a autoridade certificadora gratuita dominante tivesse uma semana ruim, boa parte da web não teria uma alternativa gratuita e automatizada comparável pronta para assumir a carga. É uma afirmação sobre uma hipótese, e a Cloudflare a apresenta como tal. Ela não diz que uma semana assim aconteceu nem que está por vir.

Mesmo assim, a lógica é fácil de acompanhar. Uma CA gratuita e automatizada só é uma opção de resiliência se existir antes da emergência. A proposta da Cloudflare é que ela pode fornecer uma segunda em escala. Eu diria que essa é a razão comercial e técnica mais forte do anúncio, e ela não depende de nenhuma das partes mais especulativas do plano. Uma web com uma CA gratuita dominante e pouco mais é uma web com um ponto único de falha, seja qual for a qualidade das operações dessa CA.

Dimensão	CA gratuita e automatizada tradicional (Let's Encrypt)	CA pública proposta pela Cloudflare
Estratégia de âncora de confiança	ISRG Root X1 / X2 (raízes próprias criadas a partir de 2015)	Raiz da GlobalSign adquirida (confiável desde 2012) + nova raiz
Protocolo de emissão	ACME padrão (RFC 8555)	ACME com aplicação obrigatória de ARI (RFC 9773)
Paradigma de revogação	CRL / OCSP + substituição emergencial em massa nos assinantes	Antecipação coordenada da renovação via endpoints ARI
Caminho pós-quântico	Assinaturas X.509 híbridas em avaliação	Merkle Tree Certificates (MTCs) nativos convivendo com X.509 clássico
Escala e carga inicial	~10 mi de certificados por dia em mais de 500 mi de sites	Validação Customer Zero em mais de 20% do tráfego web global

Comprar uma raiz em vez de esperar por uma #

A decisão mais prática do anúncio diz respeito à raiz. A Cloudflare diz ter assinado um acordo definitivo para adquirir da GlobalSign uma raiz estabelecida e amplamente confiável. A fonte dá o motivo diretamente: uma raiz totalmente nova não tem utilidade ampla por anos. A raiz existente da GlobalSign, por outro lado, é confiável em navegadores, sistemas operacionais e dispositivos desde 2012.

A confiança em uma raiz avança devagar porque fica instalada nos dispositivos, e os dispositivos se atualizam devagar. Uma raiz nova pode ser aceita por todos os programas e ainda assim não validar em um celular antigo ou em um sistema embarcado. Adquirir uma raiz que está em campo desde 2012 contorna essa espera, pelo menos da forma como a fonte apresenta.

A Cloudflare não abandona totalmente o caminho de uma raiz nova. Ela também vai submeter uma nova raiz para inclusão nos programas de chaves raiz, que descreve como pensada para a direção em que o ecossistema caminha, incluindo programas que começam a limitar a idade de uma raiz confiável. Esse último detalhe é um lembrete útil de que a idade corta para os dois lados. A idade de uma raiz confiável é um trunfo para a cobertura de dispositivos, e alguns programas caminham para limites de idade para raízes confiáveis. Manter ao mesmo tempo uma raiz adquirida e uma nova submissão parece uma resposta a essa tensão, embora a fonte não detalhe o raciocínio nesses termos.

Um serviço ACME primeiro, com condições #

A adoção é o ponto em que muitos anúncios de CA ficam vagos. A Cloudflare é específica. Sua CA pública será ACME primeiro, ou seja, vai falar o protocolo Automated Certificate Management Environment que a automação existente já usa. A afirmação é que quem já aponta para uma CA gratuita existente pode migrar para a CA da Cloudflare trocando uma URL de diretório, sem ferramentas novas e sem rearquitetar nada. É um plano, não um caminho de migração testado, e deve ser lido assim. Mas uma mudança de configuração de uma linha é o alvo certo, porque o custo de migração é o que mantém as pessoas em um padrão.

O porém é uma exigência que a maioria dos usuários de ACME nunca precisou cumprir. A Cloudflare só vai emitir para clientes que suportem ACME Renewal Information, ou ARI, padronizado na RFC 9773. Os assinantes precisam manter uma automação que consulte o endpoint de renovação da Cloudflare, aja conforme as janelas de renovação que a Cloudflare publica e identifique o certificado que está substituindo.

É uma posição firme, e acho que é a correta. Ela também levanta uma questão justa sobre adoção: uma CA que só atende clientes compatíveis com ARI é mais restrita do que uma que atende qualquer pessoa com uma biblioteca ACME. A fonte não diz quantos clientes isso exclui hoje, então não vou chutar. O que ela diz é por que a Cloudflare quer essa restrição.

Revogar sem derrubar sites #

A Cloudflare afirma ter observado algumas coisas nos últimos 16 anos, e uma dessas observações orienta este projeto. Ela viu autoridades certificadoras presas entre a revogação no prazo e manter no ar os sites dos assinantes.

Essa tensão é real para qualquer CA. Revogar um certificado rapidamente protege o público, mas pode derrubar todos os sites que dependem desse certificado se o assinante não conseguir substituí-lo rápido o bastante. Uma CA presa no meio ou revoga tarde ou derruba os clientes.

O ARI é a resposta da Cloudflare. Quando for preciso aposentar certificados, a Cloudflare diz que pode antecipar as janelas de renovação dos certificados afetados. Como os assinantes são obrigados a consultar o endpoint de renovação e a agir conforme as janelas publicadas, a CA pode conduzi-los à substituição antes que uma revogação dura aconteça. Esse mecanismo é descrito como uma capacidade que a Cloudflare pretende ter, não como uma que ela tenha demonstrado como CA. Ainda assim, a lógica se sustenta: a exigência de consulta existe para que essa alavanca funcione.

O mesmo raciocínio aparece em um objetivo de projeto mais amplo. A Cloudflare pretende construir uma autoridade certificadora cuja confiabilidade não dependa apenas de evitar erros, mas, como no restante dos produtos da Cloudflare, de falhar pequeno e limitar o impacto de qualquer problema. Evitar erros é necessário para uma CA, e nenhuma CA consegue prometer isso com perfeição. Projetar para que um erro fique contido é a postura de engenharia mais honesta.

Transparência além da auditoria #

CAs públicas costumam ser julgadas por auditorias. A fonte é direta sobre os limites delas: auditorias são pontuais e dizem que uma CA passou. Elas não dizem o que a CA está fazendo numa terça-feira qualquer depois disso.

A resposta da Cloudflare é dizer que vai publicar builds reproduzíveis do software que assina os certificados. Isso é apresentado como um compromisso, não como uma entrega concluída. Builds reproduzíveis permitem que terceiros verifiquem se o binário em execução no caminho de assinatura corresponde ao código-fonte publicado, o que é uma propriedade contínua, coisa que um relatório de auditoria não é. Se isso vai bastar depende do que a Cloudflare realmente publicar e de outros verificarem.

A segunda metade do anúncio: Merkle Tree Certificates #

O material pós-quântico é onde o anúncio olha mais longe. A Cloudflare anuncia planos de ser uma das primeiras CAs a servir certificados pós-quânticos, e planeja emitir seus primeiros Merkle Tree Certificates no primeiro trimestre de 2027. Outro trecho da fonte diz que os primeiros MTCs são esperados no início de 2027. Ambos são planos.

A fonte descreve os MTCs como uma forma nova e muito mais compacta de entregar certificados de confiança pública. Essa formulação é uma descrição, e a fonte não traz medições nos trechos com que estou trabalhando, então não posso dizer quanto mais compactos eles são. A Cloudflare diz que vem defendendo no IETF a proposta baseada em padrões para os MTCs. Ela também relata que o Chrome apontou, no início deste ano, os MTCs como o caminho preferido para a autenticação pós-quântica. Esse é um fato demonstrado, e importa, porque a preferência declarada de um fabricante de navegador é o que transforma uma proposta em algo com que uma CA pode planejar.

A Cloudflare não espera uma transição repentina. Ela prevê que boa parte da Internet continue dependendo de certificados clássicos e da WebPKI existente por muitos anos ainda. Nesse período, espera que os MTCs ocupem uma fatia da emissão em crescimento constante. São expectativas, e a fonte as identifica como tais.

Uma CA, um ciclo de vida #

A escolha de arquitetura que decorre disso é a que considero mais convincente. A nova CA foi projetada para abrigar certificados clássicos e Merkle Tree Certificates sob uma única CA, com um ciclo de vida e um conjunto de garantias. Os clientes podem então adotar no ritmo que lhes convier e ajudar a web a fazer a travessia sem uma virada brusca.

A alternativa seriam duas CAs paralelas, dois conjuntos de procedimentos e uma migração forçada em algum momento. Uma virada brusca é a forma mais arriscada de mudar um ecossistema de certificados, e o objetivo declarado da fonte é evitá-la. A formulação é cautelosa, e com razão: trata-se de uma intenção de projeto para uma CA que ainda não emite.

Isso também combina com o quadro de incentivos. A Cloudflare diz esperar que o número de certificados de que depende a cada ano continue crescendo à medida que os prazos máximos de validade diminuem, a atividade agêntica aumenta e os certificados pós-quânticos se popularizam. Mais certificados, emitidos com mais frequência, pedem automação e uma CA que trate a renovação como uma operação de primeira linha. Um sistema construído em torno do ARI e de um único ciclo de vida é uma resposta razoável a essa expectativa, embora a expectativa em si seja uma previsão, não uma medição.

Customer Zero #

Como testar uma CA antes que o público dependa dela? A resposta da Cloudflare é ser a própria primeira cliente. Ela será a Customer Zero da nova CA e dos seus certificados, tanto WebPKI quanto MTC. O objetivo declarado é garantir que todos os aspectos dos novos sistemas e processos atendam aos altos padrões internos da Cloudflare e que a infraestrutura da CA seja posta à prova na escala da Cloudflare.

Considerando os números anteriores, é uma carga interna exigente: milhões de certificados por ano, em uma empresa que fica à frente de mais de 20 por cento do tráfego global de requisições. As afirmações não conseguem nos dizer se os primeiros anos de operação vão correr bem. O que elas mostram é uma ordem de operações sensata. A empresa começa como usuária intensa do que está construindo, com um histórico de provisionamento com várias CAs, caminhos de reserva e 16 CAs parceiras por trás.

Vale ser claro sobre o que falta. Nada na fonte relata volumes de emissão, taxas de erro, latência de validação ou histórico de incidentes da própria CA da Cloudflare, porque esse histórico ainda não existe. O anúncio é uma declaração de intenção apoiada em candidaturas, em um acordo de aquisição e em um projeto. Não é um histórico de resultados.

O que acompanhar #

Três coisas vão decidir se isto é um acréscimo relevante à WebPKI ou apenas um anúncio interessante.

A primeira são os programas raiz. A Cloudflare se candidatou ao Chrome, à Apple, à Microsoft e à Mozilla, e os processos são públicos. Acompanhá-los é a forma mais direta de ver até onde o plano chegou, e nenhuma das afirmações me permite prever o resultado.

A segunda é a exigência de ARI. Uma CA que insiste no suporte à RFC 9773 aposta que a automação da renovação pode avançar em toda a sua base de assinantes. Se a aposta estiver certa, a Cloudflare ganha a capacidade de antecipar janelas de renovação quando certificados precisarem ser aposentados, que é a resposta declarada ao dilema da revogação que ela observou. Se estiver errada, a adoção será mais lenta do que sugere a história da migração em uma linha.

A terceira é o primeiro trimestre de 2027. É quando a Cloudflare planeja seus primeiros Merkle Tree Certificates. A questão em aberto é com que rapidez a fatia em crescimento constante que ela espera vai de fato crescer, dada a sua própria visão de que boa parte da Internet vai continuar com certificados clássicos por muitos anos ainda. A empresa disse que a travessia não deveria exigir uma virada brusca. O primeiro trimestre de 2027 será a primeira chance de ver se uma CA que abriga os dois tipos de certificado consegue tornar isso verdade.

O que isso significa por setor #

O surgimento de uma autoridade certificadora pública automatizada e de alto volume vinda de um provedor de infraestrutura de borda altera o risco operacional e o planejamento de PKI em vários domínios técnicos.

Infraestrutura de nuvem e redes de borda #

Operar uma CA pública em escala de borda reduz a dependência externa de APIs de verificação e CRLs de terceiros. Ao combinar a terminação na borda por proxy reverso com renovações automatizadas ACME ARI, os provedores de infraestrutura podem proteger seus clientes contra quedas de autoridades certificadoras a montante.

PKI corporativa e equipes de DevOps #

Organizações que dependem do Let's Encrypt para endpoints públicos ganham uma alternativa automatizada e confiável. No entanto, a aplicação obrigatória da RFC 9773 (ARI) significa que as equipes precisam auditar seus clientes ACME (Certbot, Lego, Caddy, Traefik) para garantir que o suporte a ARI esteja ativo antes de trocar o endpoint de diretório.

Fabricantes de navegadores e governança de raízes #

Os programas raiz (Chrome, Mozilla, Apple, Microsoft) enfrentam um ecossistema crescente de CAs automatizadas de alto volume. A abordagem de raiz em duas frentes (adquirir uma raiz legada de 2012 enquanto submete uma raiz moderna) navega por políticas de navegador que restringem cada vez mais a vida útil dos certificados raiz, mantendo a compatibilidade com dispositivos antigos.

Conclusão #

A decisão da Cloudflare de se tornar uma autoridade certificadora pública ataca uma vulnerabilidade estrutural real da WebPKI moderna: a concentração extrema na emissão gratuita e automatizada de certificados. Ao combinar uma raiz estabelecida da GlobalSign, uma automação rigorosa da renovação com ARI e uma ponte para os Merkle Tree Certificates pós-quânticos, o projeto mira a resiliência operacional, e não o mero provisionamento de certificados. O sucesso será determinado pelas aprovações dos programas raiz e pela rapidez com que as ferramentas cliente adotarem os padrões ARI antes da implantação de 2027.

Perguntas frequentes #

Posso trocar meu cliente ACME para a CA da Cloudflare hoje?

Ainda não. A Cloudflare anunciou a intenção, assinou o acordo de aquisição da raiz e enviou candidaturas aos principais programas raiz. A emissão pública está prevista para depois das aprovações dos programas raiz.

O que é ACME Renewal Information (ARI) e por que isso importa?

O ARI (RFC 9773) é uma extensão do protocolo ACME que permite às autoridades certificadoras avisar os assinantes quando um certificado deve ser renovado. Assim as CAs podem coordenar com tranquilidade renovações antecipadas antes de revogações planejadas, evitando quedas de sites.

Em que os Merkle Tree Certificates (MTCs) diferem dos certificados X.509 padrão?

Os MTCs substituem as assinaturas criptográficas individuais tradicionais por provas de inclusão Merkle ancoradas em um log verificável publicamente. Isso reduz bastante o tamanho do certificado e a sobrecarga de transmissão, tornando-os um candidato preferido para a autenticação TLS pós-quântica.

Referências #

Cloudflare, (2026). Construindo uma autoridade certificadora para toda a Internet ⧉. Blog da Cloudflare.
IETF, (2024). RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) ⧉. IETF.
IETF, (2025). Merkle Tree Certificates para TLS ⧉. IETF.
Chrome Root Program, (2026). Política e considerações sobre autenticação pós-quântica ⧉. Chromium Projects.

Última revisão 2026-09-20.

Última revisão 2026-10-27.

Republicar este artigo

Cloudflare quer virar CA diante da concentração das CAs gratuitas — Sebastien Rousseau

A Cloudflare quer ser uma autoridade certificadora pública: candidatura aos programas raiz, compra de uma raiz da GlobalSign, ARI obrigatório e certificados Merkle.

Este artigo está licenciado sob Creative Commons Attribution 4.0 International. A republicação exige atribuição à URL canônica.

Cloudflare quer virar CA diante da concentração das CAs gratuitas — Sebastien Rousseau

A Cloudflare quer ser uma autoridade certificadora pública: candidatura aos programas raiz, compra de uma raiz da GlobalSign, ARI obrigatório e certificados Merkle.

Originally published at https://sebastienrousseau.com/pt-br/2026-09-20-cloudflare-quer-virar-ca-diante-concentracao/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER