Closed willnorris closed 4 months ago
Okay, I think I have found some clues. From autohttps.go
// tailscale names go in their own automation policies because // they require on-demand TLS to be enabled, which we obviously // can't enable for everything
So configuring on-demand access for the site does seem to work...
{
debug
on_demand_tls {
ask http://localhost:8080/
}
}
:443 {
tls {
on_demand
}
respond OK
}
:8080 {
respond OK
}
Do I have that right? I'm not too worried about requiring a proper hostname for production use, I'm just trying to add to the caddy-tailscale examples that will work without additional config changes
I think you need to do this:
https:// {
tls {
get_certificate tailscale
}
respond OK
}
https://caddyserver.com/docs/caddyfile/directives/tls#certificate-managers
We could probably adjust the docs to mention that this pattern can be used if you need wildcard TS domains :thinking:
But even that still requires the on_demand_tls
global option, right? Otherwise, you get the error:
Error: loading initial config: loading new config: loading http app module: provision http: on-demand TLS cannot be enabled without a permission module to prevent abuse; please refer to documentation for details
So then I'm either specifying get_certificate tailscale
or on_demand
on each site, so it's roughly equivalent.
I'm pretty sure enabling get_certificate
should obviate the need for that. Are you testing with latest on master
? I thought we adjusted that already :thinking:
yes, this is with the last master branch... still see that error.
Okay - PRs welcome if you want to patch that (to skip the permission
module check if get_certificate
is used).
Basically a get_certificate
module is effectively a permission
module that returns a certificate or nil instead of a boolean. So I don't think it makes sense to ever require a permission module when get_certificate
is used.
@willnorris Is this patched up now? If so I'll close this and prepare to release 2.8 rc.1.
Yes, I think so. I just tested again, and while we still have some pending changes on the Tailscale side to merge (for things like proper QUIC support), everything on the Caddy side is done.
Excellent!! Thanks. I'll tag rc1 today.
It appears that the tailscale cert manager is only used when a ts.net domain is explicitly configured for a site:
This works fine, and shows debug output of:
However, when configured as:
I get debug logs:
Since caddy is already treating ts.net domains special when setting up cert managers, I'm wondering if it could do the same in the fallback handler (or maybe I've got some terminology wrong here?). I'm already looking into this myself, but wanted to open the issue in case there was a reason it behaves this way, or if you have any pointers on where to hook in.