Creating a Let's Encrypt-style public CA

seed

Requirements, steps, costs, and tradeoffs for founding a trusted public SSLTLS CA (included in browser root stores), and the pragmatic ACME resellerproxy path — the route adopted by the Koder Stack.

TL;DR

Technically it's feasible with open-source software (Boulder, step-ca). The real bottleneck is becoming a trusted CA in the browserOS root stores — it takes 2–5 years, costs hundreds of thousands of dollarsyear in auditing and HSMs, and requires an organization with formal governance.

Most of those who want to "give away free SSL" today build an automation layer on top of Let's Encrypt/ZeroSSL's ACME — that's the path adopted by the Stack (see §"Pragmatic path" and §"Adoption in the Koder Stack").

1. Legal/organizational layer

  • Reputable legal entity (Let's Encrypt = ISRG, a 501(c)(3) non-profit). Root programs reject individuals.
  • Published CP/CPS — Certificate Policy + Certification Practice Statement, written following RFC 3647. It's the "constitution" of the CA.
  • Compliance with CA/Browser Forum Baseline Requirements — technical and operational rules every public CA follows (domain validation, lifetimes, cert content, key management).
  • Annual WebTrust for CAs audit (or ETSI EN 319 411 in the EU) — qualified firms (BDO, Ernst & Young, KPMG, Schellman). The audit alone costs US$ 100–300k/year.
  • E&O insurance and separation of duties with team background checks.

2. Root trust layer (the bottleneck)

Apply to the 5 root programs:

Each one requires: 2+ consecutive audits, an operational track record, clean incident reports. Typical timeline: 1–3 years until inclusion; then another 1–2 years to reach the majority of devices in the field.

Cross-signing while you wait: another already-trusted CA (IdenTrust signed for Let's Encrypt in 2015) issues a cross-signed intermediate cert for yours, and you operate by "renting" its trust. A commercial negotiation — it isn't free.

3. Technical layer

  • Offline root CA in a vault, with a FIPS 140-2/3 Level 3+ HSM (Thales / Entrust / AWS CloudHSM / YubiHSM). Key ceremony recorded on video, with witnesses.
  • Online intermediate CAs (1+) that sign the day-to-day end-entity certs. Also in an HSM.
  • ACME server (RFC 8555) — automated issuance protocol. Ready-made open-source:
    • Boulder — what Let's Encrypt runs (Go)
    • step-ca — simpler, Go
    • Pebble — lightweight reference for testing
  • Domain validation (3 canonical challenges): HTTP-01, DNS-01, TLS-ALPN-01.
  • Certificate Transparency — every issued cert must be submitted to at least 2 CT logs recognized by browsers. It's possible to run your own log (Trillian) but it also has to pass the log inclusion program.
  • OCSP responder + CRLs for revocation.
  • Rate-limiting / anti-abuse — Let's Encrypt uses limits per registered domain, per account, per IP, and blocks TLDs/domains on fraud lists.
  • High availability — redundant DC, public uptime SLO, DR plans.

4. Financial layer

Let's Encrypt operates on ~US$ 5–7M/year in donations (Mozilla, EFF, Cisco, Google, Meta, AWS, Sectigo). To start from scratch, budget at a minimum:

Item Cost
Audit + lawyers (year 1) US$ 200–500k
HSMs + datacenter (initial CAPEX) US$ 100–300k
HSMs + datacenter (annual OPEX) ~US$ 50k
Team (min. 3–5 people with clearance) US$ 500k+/year
Commercial cross-sign 6 figures, negotiable

5. Steps, in order

  1. Incorporate a non-profit legal entity with a clear public mission.
  2. Write CPCPS v1 based on a CAB Forum template.
  3. Raise recurring capital (sponsors). Without it, the rest doesn't add up.
  4. Set up root + intermediates in a formal ceremony.
  5. Cross-sign with an existing CA.
  6. Stand up ACME (Boulder) + CT submission + OCSP.
  7. First WebTrust audit before issuing a public cert.
  8. Submit to the root programs, operate with the cross-sign.
  9. Continuous operation, annual audit, transparent incident reporting (Mozilla's Bugzilla).

Pragmatic path

If the goal is "anyone gets free SSL on their site" and not "build a CA from scratch," the ROI is radically better with one of these alternatives:

Path What it is When it makes sense
Resellerautomation on top of Let's EncryptZeroSSL UX, dashboard, DNS automation, multi-domain on top of public ACME. Cloudflare does this The overwhelming majority of cases — including ours
Private CA for a closed community step-ca + distributing the root manually to clients (intranet, IoT, devices) Internal network, Koder devices, air-gapped environments
Contribute to/fund Let's Encrypt Direct donation to ISRG When the goal is public impact and not product differentiation

Adoption in the Koder Stack

Decision (2026-05-12): ACME reseller/proxy route, not our own CA.

Architecture:

┌─────────────────────────┐    ┌──────────────────────────────┐
│ 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, …  │
                               └──────────────────────────────┘

Why a separate service (vs. embedding everything in Domains):

  • Cert orchestration is cross-cutting — Koder Jet already needs it for vhosts; Koder ID likewise; future Koder Sign likewise.
  • policies/reuse-first.kmd — the 3-consumers rule applies with room to spare.
  • policies/self-hosted-first.kmd — moving to our own CA (Gate 1+2) only makes sense once the orchestrator is mature; a separate service leaves that door open without rewriting the consumer.

Lean MVP:

  1. Implement inside Koder Domains first (internal module).
  2. Extract to services/foundation/certs/ when the 2nd consumer asks for it.
  3. Long-term: evaluate becoming our own CA on the self-hosted-first track, with a commercial cross-sign.

Root backlog: ticket to create in projects/koder-stack — "Cert orchestration service (foundation/certs)".

Canonical resources

  • 01-fundamentals/ — asymmetric cryptography, hashing, KDFs (prerequisite)
  • 02-standards/ — RFC 5280 (X.509), RFC 6960 (OCSP)
  • 04-modelos-de-confianca/ — hierarchical CA vs. web of trust vs. blockchain
  • 06-ssl-and-tls/03-acme-protocol.kmd (planned) — ACME deep dive
  • 06-ssl-and-tls/04-certificate-transparency.kmd (planned)
  • 10-koder-stack/ — Stack adoption: Koder Domains, future services/foundation/certs/