Dashboard-managed Tunnel: Should https://localhost preserve the public hostname for TLS validation?
Hi Cloudflare team,
I'm evaluating Dashboard-managed Cloudflare Tunnel with an OpenLiteSpeed reverse proxy hosting multiple HTTPS virtual hosts, and I'd like to clarify the intended behavior for HTTPS origins.
The documentation shows that an HTTPS origin such as:
https://localhost:443
is a supported Service URL.
However, I'm trying to understand how cloudflared establishes the HTTPS connection to the origin.
Example setup
Origin server:
Ubuntu 24.04
OpenLiteSpeed
Multiple HTTPS virtual hosts
For example:
example.com
blog.example.com
shop.example.com
Each virtual host has its own Let's Encrypt certificate.
The tunnel route is configured as:
Public Hostname:
example.com
↓
Service URL:
https://localhost:443
Expected behavior
Since Cloudflare already knows both:
Public hostname:
example.com
and
Origin destination:
localhost:443
I expected the origin connection to behave conceptually like this:
Visitor
│
▼
https://example.com
│
▼
Cloudflare Edge
│
▼
cloudflared
│
Connect to localhost:443
│
TLS SNI
example.com
│
HTTP Host
example.com
│
▼
OpenLiteSpeed
In other words:
- TCP destination =
localhost:443 - TLS SNI =
example.com - HTTP Host header =
example.com
This would allow OpenLiteSpeed to select the correct virtual host and present the corresponding Let's Encrypt certificate.
Actual behavior observed
Instead, cloudflared logs:
tls: failed to verify certificate:
x509: certificate is valid for xyz, not localhost
This suggests that certificate hostname verification is performed against the Service URL hostname (localhost) rather than the public hostname.
Interestingly, changing the Service URL to:
http://localhost
works correctly. This suggests that the HTTP Host header is preserved independently of the origin address. Otherwise, in a virtual-host based deployment, the origin would typically resolve the request to the default virtual host instead of the intended application.
Questions
- Is this the expected behavior for Dashboard-managed tunnels?
- Does
cloudflaredalways use the Service URL hostname for TLS hostname verification? - Is there a Dashboard-managed equivalent of
originServerName(available for locally managed tunnels) that allows:
​
TCP destination:
localhost:443
TLS server name:
example.com
- If not, what is the recommended approach for reverse proxies hosting multiple HTTPS virtual hosts on the same local web server, where each virtual host presents its own certificate?
I'm interested in understanding whether this is an intentional design decision or whether there is another recommended configuration for Dashboard-managed tunnels.
The documentation explicitly lists https://localhost:443 as a supported HTTPS origin, so I'd appreciate clarification on how TLS hostname verification is expected to work in this scenario.
Thank you.
