Criando um CA público tipo Let's Encrypt

seed

Requisitos, etapas, custos e tradeoffs para fundar um CA público de SSLTLS confiável (incluído em root stores dos navegadores), e o caminho pragmático de resellerproxy ACME — rota adotada pela Koder Stack.

TL;DR

Tecnicamente é viável com software open-source (Boulder, step-ca). O gargalo real é virar CA confiável nos root stores dos navegadoresOSes — leva 2–5 anos, custa centenas de milhares de dólaresano em auditoria e HSMs, e exige organização com governança formal.

A maioria de quem quer "dar SSL grátis" hoje monta uma camada de automação em cima de ACME do Let's Encrypt/ZeroSSL — é o caminho adotado pela Stack (ver §"Caminho pragmático" e §"Adoção na Koder Stack").

1. Camada legal/organizacional

  • Entidade legal idônea (Let's Encrypt = ISRG, non-profit 501(c)(3)). Programas de root rejeitam pessoa física.
  • CP/CPS publicados — Certificate Policy + Certification Practice Statement, escritos seguindo RFC 3647. É a "constituição" do CA.
  • Conformidade com CA/Browser Forum Baseline Requirements — regras técnicas e operacionais que todo CA público segue (validação de domínio, lifetimes, conteúdo de cert, key management).
  • Auditoria anual WebTrust for CAs (ou ETSI EN 319 411 na UE) — firmas qualificadas (BDO, Ernst & Young, KPMG, Schellman). Custa US$ 100–300k/ano só a auditoria.
  • Seguro E&O e separação de funções com background check da equipe.

2. Camada de root trust (o gargalo)

Aplicar nos 5 programas de root:

Cada um exige: 2+ auditorias consecutivas, histórico operacional, incident reports limpos. Tempo típico: 1–3 anos até inclusão; depois mais 1–2 anos pra atingir a maioria dos devices em campo.

Cross-signing enquanto espera: outro CA já confiável (IdenTrust assinou pra Let's Encrypt em 2015) emite cert intermediário cruzado pro seu, e você opera "alugando" a confiança dele. Negociação comercial — não é grátis.

3. Camada técnica

  • Root CA offline num cofre, com HSM FIPS 140-2/3 Level 3+ (Thales / Entrust / AWS CloudHSM / YubiHSM). Cerimônia de chave gravada em vídeo, com testemunhas.
  • Intermediate CAs online (1+) que assinam os end-entity certs do dia-a-dia. Também em HSM.
  • ACME server (RFC 8555) — protocolo de emissão automatizada. Open-source pronto:
    • Boulder — o que o Let's Encrypt roda (Go)
    • step-ca — mais simples, Go
    • Pebble — referência leve para testes
  • Validação de domínio (3 desafios canônicos): HTTP-01, DNS-01, TLS-ALPN-01.
  • Certificate Transparency — todo cert emitido tem que ser submetido a pelo menos 2 CT logs reconhecidos pelos navegadores. Possível rodar log próprio (Trillian) mas precisa passar no programa de inclusão de log também.
  • OCSP responder + CRLs para revogação.
  • Rate-limiting / anti-abuse — Let's Encrypt usa limites por domínio raiz, por conta, por IP, e bloqueia TLDs/domínios em listas de fraude.
  • Alta disponibilidade — DC redundante, SLO público de uptime, planos de DR.

4. Camada financeira

Let's Encrypt opera com ~US$ 5–7M/ano em doações (Mozilla, EFF, Cisco, Google, Meta, AWS, Sectigo). Para começar do zero, orce no mínimo:

Item Custo
Auditoria + advogados (ano 1) US$ 200–500k
HSMs + datacenter (CAPEX inicial) US$ 100–300k
HSMs + datacenter (OPEX anual) ~US$ 50k
Equipe (mín. 3–5 pessoas com clearance) US$ 500k+/ano
Cross-sign comercial 6 dígitos, negociável

5. Etapas, em ordem

  1. Constituir entidade legal sem fins lucrativos com missão pública clara.
  2. Escrever CPCPS v1 baseado em template do CAB Forum.
  3. Levantar capital recorrente (sponsors). Sem isso o resto não fecha.
  4. Montar root + intermediates em cerimônia formal.
  5. Cross-sign com um CA existente.
  6. Subir ACME (Boulder) + CT submission + OCSP.
  7. Primeira auditoria WebTrust antes de emitir cert público.
  8. Submeter aos programas de root, operar com cross-sign.
  9. Operação contínua, auditoria anual, incident reporting transparente (Bugzilla do Mozilla).

Caminho pragmático

Se o objetivo é "qualquer pessoa ter SSL grátis no site" e não "construir um CA do zero", o ROI é radicalmente melhor em uma destas alternativas:

Caminho O que é Quando faz sentido
Resellerautomation em cima de Let's EncryptZeroSSL UX, painel, DNS automation, multi-domain por cima de ACME público. Cloudflare faz isso Maioria absoluta dos casos — inclusive o nosso
CA privado para comunidade fechada step-ca + distribuir o root manualmente nos clientes (intranet, IoT, devices) Rede interna, devices Koder, ambientes air-gapped
Contribuir/financiar Let's Encrypt Doação direta à ISRG Quando o objetivo é impacto público e não diferenciação de produto

Adoção na Koder Stack

Decisão (2026-05-12): rota de reseller/proxy ACME, não CA próprio.

Arquitetura:

┌─────────────────────────┐    ┌──────────────────────────────┐
│ Koder Domains (UX)      │───▶│ services/foundation/certs/   │
│ products/dev/domains/   │    │  - ACME orchestrator         │
│ - toggle "SSL ON"       │    │  - upstreams: LE / ZeroSSL   │
│ - vincula a cada domain │    │  - HTTP-01 + DNS-01          │
└─────────────────────────┘    │  - storage, renewal, OCSP    │
                               │  - API consumida por:        │
                               │    Domains, Jet, Hub, ID, …  │
                               └──────────────────────────────┘

Por que serviço separado (vs embutir tudo em Domains):

  • Cert orchestration é cross-cutting — Koder Jet já precisa pros vhosts; Koder ID idem; futuro Koder Sign idem.
  • policies/reuse-first.kmd — regra dos 3 consumidores aplicada com folga.
  • policies/self-hosted-first.kmd — passar pra CA próprio (Gate 1+2) só faz sentido depois que o orquestrador estiver maduro; serviço separado deixa essa porta aberta sem reescrever o consumidor.

MVP enxuto:

  1. Implementar dentro de Koder Domains primeiro (módulo interno).
  2. Extrair pra services/foundation/certs/ quando o 2º consumidor pedir.
  3. Long-term: avaliar virar CA próprio na trilha self-hosted-first, com cross-sign comercial.

Backlog raiz: ticket a criar em projects/koder-stack — "Cert orchestration service (foundation/certs)".

Recursos canônicos

Tópicos relacionados neste compendium

  • 01-fundamentals/ — criptografia assimétrica, hash, KDFs (prerequisito)
  • 02-standards/ — RFC 5280 (X.509), RFC 6960 (OCSP)
  • 04-modelos-de-confianca/ — CA hierárquica vs web of trust vs blockchain
  • 06-ssl-and-tls/03-acme-protocol.kmd (planejado) — detalhamento do ACME
  • 06-ssl-and-tls/04-certificate-transparency.kmd (planejado)
  • 10-koder-stack/ — adoção da Stack: Koder Domains, futuro services/foundation/certs/