# 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-cert` and `--tls-key` flags. 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-key` example.
- **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 `-insecure` to 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.

## Related documents

- [Guide](/guide.md): updated insecure note for custom cert path