docs: add Caddy+LetsEncrypt TLS example #4585
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bpmct
commented
Oct 17, 2022
|
|
||
| ## Generating wildcard certificates | ||
|
|
||
| By default, this configuration uses Caddy's [on-demand TLS](https://caddyserver.com/docs/caddyfile/options#on-demand-tls) to generate a certificate for each subdomain (e.g. `app1.coder.example.com`, `app2.coder.example.com`). When users visit new subdomains, such as accessing [ports on a workspace](../../networking/port-forwarding.md), the request will take an additional 5-30 seconds since a new certificate is being generated. |
There was a problem hiding this comment.
the request will take an additional 5-30 seconds
I'm fairly certain this is the only downside of using Caddy's on-demand TLS. While LetsEncrypt's rate limit (50 certificates/domain/week) can quickly be exhausted, Caddy will silently fall back to ZeroSSL which has no rate limit. ZeroSSL is significantly slower though. If you think this needs further explanation in the docs, I can expand.
With that being said, the extra effort for a wildcard is worth it if a Coder deployment is being actively being used in production.
ghuntley
reviewed
Oct 17, 2022
ammario
reviewed
Oct 18, 2022
sharkymark
approved these changes
Oct 18, 2022
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is inspired by GitLab's Caddy Recipe and I plan to add additional ones for NGINX and Kubernetes ingress+cert-manager.
As much as possible, I tried to reference the Caddy docs for custom builds/providers, while showing one concrete example for wildcards: AWS Route53. If we want to make it slightly more concrete, I could actually modify the docker-compose to support building a custom Dockerfile there that the user could just uncomment.
I understand this adds some debt to the codebase, so I'm open to other ideas. I could just include code snippets in the docs but I found that structure a bit confusing. One advantage of having this in the codebase is I could create an automated (weekly) test to spin up a Coder server with Caddy and ensure everything works as planned. If we wanted to do that as a prerequisite to merging, I'd totally understand.
Contributes to #3518