Mutual TLS Comes to Workers for Service-to-Service Calls
Cloudflare has announced that Workers will soon support mutual TLS (mTLS) on outbound fetch() requests. This will let developers present a client certificate when a Worker talks to an origin, database, or another service—so the receiving server can verify not just that the request came from Cloudflare, but which specific Worker sent it.
Why Two-Way Authentication Matters
Standard TLS ensures a client can trust the server it is connecting to. Mutual TLS flips that around as well: the server validates the client's certificate against a CA before accepting the request. If the certificate is missing or invalid, the server can reject the connection.
Cloudflare already offers this capability for origin connections through Authenticated Origin Pull. When enabled, Cloudflare attaches a client certificate—either Cloudflare-managed or customer-uploaded—to every outbound request. The origin checks that certificate and can drop any traffic that does not carry the expected one. That effectively restricts traffic to Cloudflare-only and blocks unexpected external requests.
Internal Pain Points With Existing Options
Many Cloudflare services are built on Workers, and it is common for one service to call another, read or write to a database, or send data to an upstream provider. That internal traffic is often sensitive and needs authentication. But the existing mechanisms have gaps.
Authenticated Origin Pull is tied to a publicly hosted hostname or domain. That is a poor fit for internal services that do not need to be exposed to the public Internet at all. More importantly, it lacks granularity: if multiple Workers write to the same origin, Authenticated Origin Pull attaches the same Cloudflare client certificate to every request, so the origin cannot tell Worker A from Worker B. That makes it impossible to grant write access to one Worker while keeping another read-only, or to revoke write permission from a specific Worker.
Another common approach is Cloudflare Access Token Authentication with a pre-shared key checked in Worker code. That gives per-service control, but internal teams that have used it report that it is cumbersome to manage, forces services to communicate over HTTP, and does not expose the calling client's identity.
What the New Feature Brings
The upcoming mTLS support in Workers lets customers upload client certificates to Cloudflare and attach them to individual fetch() calls inside a Worker. That gives per-Worker—or even per-request—granularity for authentication and identification.
When a Worker makes a subrequest, Cloudflare will present the attached client certificate. The receiving server will then be able to check two things:
- Is the client presenting a valid certificate?
- Within Cloudflare, what service or Worker is the request coming from?
The feature is one of the most frequently requested additions, both from external customers and internal Cloudflare teams. It is expected to be generally available within the next few months.
