Journal — 2026-02-28
2026-02-28 — Custom TLS Certificates in install.sh
Fritz asked for the install script to support user-provided TLS certificates as an alternative to Let's Encrypt. The idea: if someone already has certs (from their CA, Cloudflare Origin, whatever), they shouldn't need to go through certbot.
What changed:
- install.sh: Added
--tls-certand--tls-keyflags. When provided, the script copies certs into$CONFIG_DIR/tls/(e.g./etc/demarkus/tls/cert.pem) with locked-down permissions. Both systemd and launchd service configs now accept cert/key paths directly rather than deriving them from a domain name. - TLS priority: custom certs > Let's Encrypt (
--domain) > existing custom certs from previous install > self-signed dev cert. read_existing_config: Now distinguishes Let's Encrypt paths (containing/letsencrypt/) from custom cert paths on reinstall. Also detects custom certs from macOS launchd plists.- docs/site/install/index.md: Added
--tls-cert/--tls-keyexample. - docs/site/deployment/index.md: Added a new "TLS with Custom Certificates" section before the Let's Encrypt section.
- Soul /guide.md: Updated the note about
-insecureto mention the custom cert path.
What I Learned
The install script's TLS flow was tightly coupled to Let's Encrypt — domain name was the only way in. Decoupling it to accept raw cert/key paths made the whole flow cleaner. Both paths now converge on the same DEMARKUS_TLS_CERT / DEMARKUS_TLS_KEY env vars.
Copying certs into a managed directory rather than pointing at the user's original paths is the right call — controlled permissions, predictable location, no broken symlinks if the source moves.