Repository navigation
Conversation
- Setup custom certs: certs go in data/caddy/config/, which the caddy
container mounts as /config. The old ./.caddy and /root/.caddy paths
date from Caddy v1 and are not mounted, so Caddy failed to start with
"no such file". Matches the manual Let's Encrypt handshake doc. Adds
PEM/full-chain/unencrypted-key requirements, restart command, and a
renewal note.
- Setup free Automatic TLS: the sample used `tls { max_certs 100 }`, a
Caddy v1 option that Caddy 2 rejects ("unknown subdirective:
max_certs"), on a wildcard name, which Let's Encrypt only issues via a
DNS challenge. Replaced with a plain FQDN site block and a note on
wildcard names.
Moves the Caddy-specific TLS material out of app-config/configure.md into docs/security/configure-tls-caddy.md, next to the manual Let's Encrypt handshake page, and adds: - an option chooser (automatic, custom certs, manual handshake, offload) - where the Caddyfile and certificate folders are mounted, how to validate, and restarting with ./graphistry (plain docker compose uses a different project name and fails on port 80) - automatic TLS requirements, firewalls that block Let's Encrypt validation (temporary port 80, renewal timing, staging fallback), and changing public IPs - custom certificate requirements, OCSP note for offline networks - HTTP to HTTPS: why `domain, :80` serves the app over plain HTTP by IP, and a :80 block that keeps the health check - common symptoms in Debugging TLS configure.md keeps the TLS intro and application server cookie settings, with the #tls / #tls-hardening / #caddy anchors kept as pointers. Fixes links that targeted the nonexistent docs/configure.md#tls-hardening and the unanchored (level 4) #application-servers heading.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Adds a Configure TLS with Caddy page (
docs/security/configure-tls-caddy.md, in the Security section next to the manual Let's Encrypt handshake page) and fixes Caddy TLS examples that do not work on current releases.New page
Collects the Caddy material that lived in
app-config/configure.md(a Visual Playbooks page) and adds what admins hit in practice:caddy validate, and restarting with./graphistry. Plaindocker composein the release folder uses a different project name and fails withport is already allocated.Timeout during connectsymptom, the staging fallback, opening port 80 temporarily, renewal timing, and changing public IPs./configpaths, an OCSP note for offline networks, and renewal.domain, :80 {serves the whole app over plain HTTP to requests by IP. Adds a separate:80block that keeps/caddy/health/(used by the container health check) and redirects everything else.configure.md, with a list of common symptoms added to debugging.configure.mdkeeps the TLS intro and the application server cookie settings. The#tls,#tls-hardeningand#caddyanchors stay, as pointers to the new page.Fixes
./.caddy/and/root/.caddy/..., Caddy v1 paths that current releases do not mount. On v2.53.6 thecaddycontainer mountsdata/config/Caddyfile,data/caddy/config(/config) anddata/caddy/data(/data), so Caddy failed with "no such file". Nowdata/caddy/config/and/config/..., matching the handshake page.tls { max_certs 100 }(Caddy v1; Caddy 2 rejects it:unknown subdirective: max_certs) on a wildcard name, which Let's Encrypt only issues through a DNS challenge. Replaced with a plain domain block.docs/configure.md#tls-hardening, and two to#application-servers, a level-4 heading that gets no anchor (myst_heading_anchors = 3). All now point to existing anchors.Testing
ocsp_stapling offand the:80redirect block, security headers,trusted_proxies) passescaddy validatewith Caddy 2.10.2.sphinx-build -b htmlwithsphinxdoc/sphinx:8.0.2andgraphistry[docs]: no warnings in the touched pages. The remaining warnings are pre-existing, in telemetry, SSO, debugging and scripts-reference. A script over the rendered HTML found 0 broken internal page or#anchorlinks on the five touched pages./configmount was checked on a v2.53.6 install. If an older supported release mounted.caddy, a version note may be needed.