Website /check endpoint for Caddy/others #468
Labels
No labels
action
check-aws
action
discussion-needed
action
for-external-contributors
action
for-newcomers
action
more-info-needed
action
need-funding
action
triage-required
kind
correctness
kind
ideas
kind
improvement
kind
performance
kind
testing
kind
usability
kind
wrong-behavior
prio
critical
prio
low
scope
admin-api
scope
background-healing
scope
build
scope
documentation
scope
k8s
scope
layout
scope
metadata
scope
ops
scope
rpc
scope
s3-api
scope
security
scope
telemetry
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#468
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Was reading the Caddy documentation when I came across the "On-Demand TLS" feature:
They recommend that the backend that serves these dynamic FQDNs implement a small
/check
endpoint that verifies that the site is a valid one to be served:Whilst a niche usecase (most people would just configure static domains) - could still be good to have the endpoint.
Hmm, just found the
authority_to_host()
function already seems to listen on:3902
's root, testing this out now.We have
/health
on the admin API endpoint that is meant exactly for this, does it not work with Caddy ?Looking at the code in
fn handle_health(&self) -> Result<Response<Body>, Error> {
The
/health
endpoint seems better suited for an active health check in Caddy: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#active-health-checksWhilst the
/check
endpoint Caddy purposes is more for "is this a valid domain for you to be serving before I request a TLS certificate for it?"Thanks, I understand the difference now. This is definitely a valid feature request, we also do ondemand TLS with our custom reverse proxy (Tricot) and are vulnerable to the kind of attack described in the community thread.
It's not clear to me how Caddy transmits the domain name it wants to check to the
/check
endpoint, does it send theHost
header as if it tried to actually access the website?Also: is it OK for this endpoint to be implemented in the admin API endpoint, or does it have to be on the website endpiont? And can we use a path different than
/check
?The PR that added this is at https://github.com/caddyserver/caddy/pull/1939 - it seems to send a
domain
field at the/check
and looks for a2XX
response.I think the admin API should be used - as a user might create a file called
check
in their bucket?