-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
caddytls: tailscale cert manager not used as fallback for *.ts.net certs #6327
Comments
Okay, I think I have found some clues. From autohttps.go
So configuring on-demand access for the site does seem to work...
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://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 🤔 |
But even that still requires the
So then I'm either specifying |
I'm pretty sure enabling |
yes, this is with the last master branch... still see that error. |
Okay - PRs welcome if you want to patch that (to skip the Basically a |
Certificate automation has permission modules that are designed to prevent inappropriate issuance of unbounded or wildcard certificates. When an explicit cert manager is used, no additional permission should be necessary. For example, this should be a valid caddyfile: https:// { tls { get_certificate tailscale } respond OK } This is accomplished when provisioning an AutomationPolicy by tracking whether there were explicit managers configured directly on the policy (in the ManagersRaw field). Only when a number of potentially unsafe conditions are present AND no explicit cert managers are configured is an error returned. The problem arises from the fact that ctx.LoadModule deletes the raw bytes after loading in order to save memory. The first time an AutomationPolicy is provisioned, the ManagersRaw field is populated, and everything is fine. An AutomationPolicy with no subjects is treated as a special "catch-all" policy. App.createAutomationPolicies ensures that this catch-all policy has an ACME issuer, and then calls its Provision method again because it may have changed. This second time Provision is called, ManagesRaw is no longer populated, and the permission check fails because it appears as though the policy has no explicit managers. Address this by storing a new boolean on AutomationPolicy recording whether it had explicit cert managers configured on it. Also fix an inverted boolean check on this value when setting failClosed. Updates caddyserver#6060 Updates caddyserver#6229 Updates caddyserver#6327 Signed-off-by: Will Norris <will@tailscale.com>
Certificate automation has permission modules that are designed to prevent inappropriate issuance of unbounded or wildcard certificates. When an explicit cert manager is used, no additional permission should be necessary. For example, this should be a valid caddyfile: https:// { tls { get_certificate tailscale } respond OK } This is accomplished when provisioning an AutomationPolicy by tracking whether there were explicit managers configured directly on the policy (in the ManagersRaw field). Only when a number of potentially unsafe conditions are present AND no explicit cert managers are configured is an error returned. The problem arises from the fact that ctx.LoadModule deletes the raw bytes after loading in order to save memory. The first time an AutomationPolicy is provisioned, the ManagersRaw field is populated, and everything is fine. An AutomationPolicy with no subjects is treated as a special "catch-all" policy. App.createAutomationPolicies ensures that this catch-all policy has an ACME issuer, and then calls its Provision method again because it may have changed. This second time Provision is called, ManagesRaw is no longer populated, and the permission check fails because it appears as though the policy has no explicit managers. Address this by storing a new boolean on AutomationPolicy recording whether it had explicit cert managers configured on it. Also fix an inverted boolean check on this value when setting failClosed. Updates #6060 Updates #6229 Updates #6327 Signed-off-by: Will Norris <will@tailscale.com>
@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.
The text was updated successfully, but these errors were encountered: