Put mcp.internetcomputer.org behind Cloudflare: origin cert plus an SSE compatibility test

[aterga]

Is your feature request related to a problem?

mcp.internetcomputer.org is currently served directly by Caddy on the production host, with a single DNS-only A record. That means no Cloudflare WAF or DDoS protection in front of it, and the origin address is publicly visible. PfOps have asked for the hostname to be protected by Cloudflare, which is reasonable and is the right end state; this issue tracks the work that has to happen first.

The record was deliberately set to DNS-only rather than Proxied when the endpoint was brought up, for two reasons:

1. Caddy issues its own certificate. It uses the TLS-ALPN-01 (443) or HTTP-01 (80) challenge, and a proxied record terminates both at Cloudflare's edge, so the challenge never reaches the origin and no certificate is ever issued. This was not hypothetical — it is the state the hostname was in before, serving nothing behind a proxied record.
2. The service is an MCP server on the Streamable HTTP transport (rmcp with transport-streamable-http-server), so text/event-stream responses and long-lived sessions. /version reports active_sessions and live_sessions, so session longevity is load-bearing rather than incidental.

Enabling the proxy without addressing both would break certificate issuance outright and risk intermittent stream truncation.

Describe the solution you'd like

Two pieces, in order.

Origin certificate. Install a Cloudflare Origin CA certificate on the host and set the zone's SSL mode to Full (strict). Origin CA certs are free, long-lived, and trusted by Cloudflare only, which is exactly the trust relationship wanted here. Concretely this means shipping a cert and key to the host and pointing the Caddyfile at them with an explicit tls directive instead of letting Caddy manage ACME for this site. The cert and key become deploy inputs, so they need somewhere to live alongside the existing PROD_DEPLOY_* secrets, and deploy/native/deploy.sh needs to place them.

SSE compatibility test, before flipping the proxy. Confirm that a proxied request survives a long-lived text/event-stream response. The specific risks are Cloudflare's idle-connection timeout (100 seconds outside Enterprise) and response buffering. Worth testing with a session held open past that timeout with and without traffic, and checking whether events arrive incrementally or are buffered — buffering would break the transport's streaming semantics even where the connection survives. Do this on a proxied test hostname pointed at the same origin rather than by flipping production and watching.

Only enable the proxy on mcp.internetcomputer.org once both are done. Keep DNS-only as the documented fallback if the SSE test finds the proxy unsuitable, and record that outcome here either way — it is the kind of finding that gets rediscovered expensively.

Alternatives considered

• DNS-01 challenge via the Cloudflare plugin. Keeps a publicly-trusted certificate on the origin while proxied. Rejected as the primary approach: deploy.sh installs a stock Caddy static binary, and DNS-01 needs a custom build with caddy-dns/cloudflare plus a Cloudflare API token on the host. More moving parts and a bespoke binary to maintain, for no benefit over Origin CA given only Cloudflare needs to trust the origin.
• SSL mode Flexible (Cloudflare to origin over plain HTTP). Rejected: the origin leg would be unencrypted, and Caddy's HTTP→HTTPS redirect would cause a redirect loop.
• SSL mode Full, not strict (any origin certificate accepted, including self-signed). Works, and Caddy's internal CA would satisfy it, but it leaves the Cloudflare-to-origin leg unauthenticated. Origin CA with Full (strict) is barely more work.
• Leave it DNS-only permanently. The status quo, and acceptable on reachability grounds, but it declines the WAF and DDoS protection PfOps asked for and leaves the origin address exposed.

Additional context

• Context and the exchange with PfOps are in Deploy production on release-* tags #81, which documents the production public path and why the record ended up DNS-only. The A record points at an Elastic IP on a second ENI in a public subnet; the previous address sat in a NAT-routed subnet and could never receive inbound traffic.
• The AAAA record was deleted when the A record was corrected, so the endpoint is IPv4-only. That is fine — IPv4 reaches effectively everyone, and IPv6-only clients reach it via NAT64/DNS64 — but it is worth knowing before changing anything here, because putting Cloudflare in front would restore dual-stack for clients as a side effect.
• Staging is in the same subnet with the same NAT-routed IPv4, so if its hostname is DNS-only it is currently IPv4-dark. Worth confirming separately; it may want the same second-ENI treatment, and any Cloudflare decision here probably wants to apply to both.

[aterga]

Correction: staging is not IPv4-dark, and the origin-exposure framing has a caveat

Two updates from measuring rather than reasoning.

The last bullet of this issue is wrong. It says staging "is in the same subnet with the same NAT-routed IPv4, so if its hostname is DNS-only it is currently IPv4-dark." It isn't. Staging already has the second-ENI treatment:

ENI	Private	Public	Subnet
eni-0f4388df0fa314357	private address	unused EIP, inbound-dead	NAT-routed private
eni-0905365a07e1aaf39	private address	live EIP	public

The staging hostname resolves to that public EIP and returns HTTP/2 200 over both IPv4 and IPv6 — it has a live AAAA, unlike production. So no second-ENI work is needed for staging, and any Cloudflare decision applies to a host that is currently dual-stack, where production is IPv4-only. Worth noting the asymmetry: proxying both would make them consistent, which is a mild argument in favour.

The unused association on the private ENI is inbound-dead only because its subnet routes 0.0.0.0/0 to a NAT gateway. It should be disassociated regardless — tracked on #91 — since repairing that routing later would silently restore an internet path.

On the origin-IP exposure, raised separately as a disclosure finding: the premise is right but it is a property of the DNS record, not of this issue. A public dig of the production hostname returns the origin address to anyone, so documenting it adds nothing an attacker cannot get in one query. This issue is the fix for it.

One caveat on that reasoning, and the reason the address is not quoted here: "already public via DNS" holds only for as long as DNS still answers with it. Once this issue lands, the origin address becomes precisely the thing Cloudflare exists to hide, and a public issue quoting it would be a durable way to bypass the proxy. Public-by-DNS is revocable; public-in-an-issue is not. Recorded in #101 along with the pre-publication scrub.

One thing that has changed since this was filed and is worth knowing before touching the proxy: 22/tcp is no longer reachable from the internet on either host (see #91). The web ENIs now carry a security group with 80/443 only. That does not affect the Cloudflare plan, but it does mean the origin is a smaller target than when this issue was written, which slightly weakens the urgency argument for the WAF while leaving the DDoS and origin-concealment arguments intact.

---

Generated by Claude Code