SYSTEM Cited by 1 source

Boulder¶

What¶

Boulder (github.com/letsencrypt/boulder) is the ACME server software that powers Let's Encrypt — the certificate-issuance infrastructure that handles certificate requests, domain-control validation, and issuance workflows over the ACME protocol. It is described as "widely deployed and well-tested," having issued certificates at Let's Encrypt's scale (~10 M certs/day). (Source: sources/2026-09-29-cloudflare-building-a-post-quantum-certificate-authority-with-merkle-tr)

Role in Cloudflare's MTC CA¶

Cloudflare's post-quantum certificate authority does not build its ACME infrastructure from scratch — it forks Boulder. The rationale is reuse of battle-tested issuance machinery: Let's Encrypt is actively developing MTC support in Boulder (letsencrypt.org/2026/06/03/pq-certs), so Cloudflare plans to maintain its own fork incorporating those upstream changes plus Cloudflare-specific modifications, contributing back upstream where possible.

In the MTC issuance flow, Boulder (as forked) is the issuance side:

Receives an ACME certificate-issuance request.
Checks the requester actually controls the domain (ACME domain-control validation).
Serializes the validated data and adds it as an entry to the CA's append-only issuance log (rather than signing a standalone certificate and then logging it — the "issue by logging" inversion).

The mirroring/cosigning side is handled separately by Azul, Cloudflare's Rust transparency log.

Why fork rather than rebuild¶

Boulder embodies years of production hardening of the hardest parts of a CA: ACME challenge handling, rate limiting, validation, and issuance workflows. Forking lets Cloudflare stand up a CA quickly while tracking the upstream MTC work Let's Encrypt is doing — an instance of building on a well-tested shared primitive and contributing changes back rather than diverging permanently.

Raw-scope caveats¶

The 2026-09-29 post names Boulder as the ACME software Cloudflare forks and notes Let's Encrypt's MTC work in Boulder. Boulder's internal architecture (component split — WFE / RA / CA / VA / SA, database, etc.) is not detailed in this post; it lives in the Boulder repository and Let's Encrypt's own writeups.

Seen in¶

sources/2026-09-29-cloudflare-building-a-post-quantum-certificate-authority-with-merkle-tr — canonical wiki instance. Cloudflare's MTC CA forks Boulder for ACME issuance
domain validation, tracking Let's Encrypt's upstream MTC support and contributing back; Boulder adds validated requests as entries to the CA's append-only issuance log.

systems/lets-encrypt — the CA Boulder was built for and powers.
systems/cloudflare-certificate-authority — the CA forking Boulder for MTC issuance.
systems/merkle-tree-certificates — the certificate form whose issuance Let's Encrypt is adding to Boulder.
systems/web-pki — the trust system Boulder issues into.