daniel/furtka

Fork 0

HTTPS force-redirect toggle breaks Caddy mid-handshake (SSL_ERROR_INTERNAL_ERROR_ALERT) #10

New issue

Closed

opened 2026-04-18 21:02:13 +02:00 by daniel · 1 comment

daniel commented

2026-04-18 21:02:13 +02:00

Owner

Symptom

Fresh install of 26.4-alpha on a smoke VM, hostname furtka, user trusted the local Caddy CA in Firefox, then clicked the "Force HTTPS" toggle in /settings. After that, https://furtka.local/ fails immediately in Firefox:

Secure Connection Failed
An error occurred during a connection to furtka.local.
Peer reports it experienced an internal error.
Error code: SSL_ERROR_INTERNAL_ERROR_ALERT

That's an alert coming from the server side — Caddy is sending TLS internal_error mid-handshake, not a client-side trust issue.

Scope

Reproducible: yes (tested 2026-04-18 on fresh VM install).
Blocker for the HTTPS phase-1 opt-in path — user who enables the toggle is locked out of the browser UI until rollback.
Rollback works: sudo rm /etc/caddy/furtka.d/redirect.caddyfile && sudo systemctl reload caddy restores HTTP.

Hypotheses to check

Caddyfile parse error after the redirect snippet import — need caddy validate /etc/caddy/Caddyfile + journalctl -u caddy -n 200 to see the actual error body.
Cert provisioning failure for furtka.local — maybe tls internal was configured for a specific SNI list that doesn't include the installer-chosen hostname.
Hostname-change flow — CA was generated once on the ISO, installer wrote a different hostname, Caddy's on-disk pki doesn't match. Memory note project_ssl_local_deferred.md already flagged "Hostname-change flow" as untested end-to-end.

Next debug steps

SSH into the affected VM.
journalctl -u caddy -n 200 --no-pager — the real error is here.
cat /etc/caddy/Caddyfile and cat /etc/caddy/furtka.d/redirect.caddyfile — verify syntax.
caddy validate --config /etc/caddy/Caddyfile — syntactic check.
ls -la /var/lib/caddy/.local/share/caddy/pki/authorities/local/ — CA files present and readable?
ls -la /var/lib/caddy/.local/share/caddy/certificates/ — was a leaf cert for the actual hostname issued?

Rollback for users who get locked out

Document one of these in /settings before re-enabling the toggle after the fix lands:

sudo rm /etc/caddy/furtka.d/redirect.caddyfile && sudo systemctl reload caddy (clears redirect, HTTP comes back)
Or expose an unauth'd /api/furtka/https/force DELETE endpoint that does the same.

Memory: project_ssl_local_deferred.md — Phase 1 HTTPS opt-in, same feature.
Shipped in: 26.4-alpha (commit range 663bd74 .. caa8609).

## Symptom Fresh install of 26.4-alpha on a smoke VM, hostname `furtka`, user trusted the local Caddy CA in Firefox, then clicked the "Force HTTPS" toggle in `/settings`. After that, `https://furtka.local/` fails immediately in Firefox: ``` Secure Connection Failed An error occurred during a connection to furtka.local. Peer reports it experienced an internal error. Error code: SSL_ERROR_INTERNAL_ERROR_ALERT ``` That's an alert coming from the server side — Caddy is sending TLS `internal_error` mid-handshake, not a client-side trust issue. ## Scope - Reproducible: yes (tested 2026-04-18 on fresh VM install). - Blocker for the HTTPS phase-1 opt-in path — user who enables the toggle is locked out of the browser UI until rollback. - Rollback works: `sudo rm /etc/caddy/furtka.d/redirect.caddyfile && sudo systemctl reload caddy` restores HTTP. ## Hypotheses to check 1. **Caddyfile parse error after the redirect snippet import** — need `caddy validate /etc/caddy/Caddyfile` + `journalctl -u caddy -n 200` to see the actual error body. 2. **Cert provisioning failure for `furtka.local`** — maybe `tls internal` was configured for a specific SNI list that doesn't include the installer-chosen hostname. 3. **Hostname-change flow** — CA was generated once on the ISO, installer wrote a different hostname, Caddy's on-disk pki doesn't match. Memory note `project_ssl_local_deferred.md` already flagged "Hostname-change flow" as untested end-to-end. ## Next debug steps - SSH into the affected VM. - `journalctl -u caddy -n 200 --no-pager` — the real error is here. - `cat /etc/caddy/Caddyfile` and `cat /etc/caddy/furtka.d/redirect.caddyfile` — verify syntax. - `caddy validate --config /etc/caddy/Caddyfile` — syntactic check. - `ls -la /var/lib/caddy/.local/share/caddy/pki/authorities/local/` — CA files present and readable? - `ls -la /var/lib/caddy/.local/share/caddy/certificates/` — was a leaf cert for the actual hostname issued? ## Rollback for users who get locked out Document one of these in /settings before re-enabling the toggle after the fix lands: - `sudo rm /etc/caddy/furtka.d/redirect.caddyfile && sudo systemctl reload caddy` (clears redirect, HTTP comes back) - Or expose an unauth'd `/api/furtka/https/force` DELETE endpoint that does the same. ## Related - Memory: `project_ssl_local_deferred.md` — Phase 1 HTTPS opt-in, same feature. - Shipped in: 26.4-alpha (commit range `663bd74` .. `caa8609`).

daniel referenced this issue from a commit

2026-04-20 11:40:20 +02:00

fix(https): restore TLS handshake — name hostname + correct PKI path

daniel closed this issue

2026-04-20 11:40:23 +02:00

daniel referenced this issue from a commit

2026-04-20 11:52:41 +02:00

chore: release 26.5-alpha

daniel commented

2026-04-20 13:42:32 +02:00

Author

Owner

Verified fixed in 26.5-alpha.

Tested on a fresh install (VM 192.168.178.23):

openssl s_client -connect 127.0.0.1:443 -servername furtka.local completes a TLS 1.3 handshake against Caddy's internal CA — was internal_error alert on 26.4-alpha.
/var/lib/caddy/certificates/local/ populated with leaf certs for both furtka.local and furtka (matching the two names in the templated :443 site block).
/api/furtka/https/status returns ca_available: true with a real fingerprint — was false on 26.4-alpha because the hardcoded path didn't exist.
GET /rootCA.crt returns 200 with the proper Content-Disposition — was 404 on 26.4-alpha.
Browser flow end-to-end: downloaded rootCA.crt from /settings, imported it into Firefox's trust store, https://furtka.local/ loads with a green padlock, /settings then exposed the "Force HTTPS" toggle and enabling it redirected HTTP → HTTPS without any handshake error.

Ships in 26.5-alpha.

Follow-up caught during the test (separate fix, not part of the hot path): the SHA-256 fingerprint overflowed the Local HTTPS card because the colon-separated hex string had no wrap opportunities — fixed locally (e7ee169), will ride the next push.

Verified fixed in 26.5-alpha. Tested on a fresh install (VM `192.168.178.23`): - `openssl s_client -connect 127.0.0.1:443 -servername furtka.local` completes a TLS 1.3 handshake against Caddy's internal CA — was `internal_error` alert on 26.4-alpha. - `/var/lib/caddy/certificates/local/` populated with leaf certs for both `furtka.local` and `furtka` (matching the two names in the templated `:443` site block). - `/api/furtka/https/status` returns `ca_available: true` with a real fingerprint — was `false` on 26.4-alpha because the hardcoded path didn't exist. - `GET /rootCA.crt` returns 200 with the proper `Content-Disposition` — was 404 on 26.4-alpha. - Browser flow end-to-end: downloaded `rootCA.crt` from `/settings`, imported it into Firefox's trust store, `https://furtka.local/` loads with a green padlock, `/settings` then exposed the "Force HTTPS" toggle and enabling it redirected HTTP → HTTPS without any handshake error. Ships in [26.5-alpha](https://forgejo.sourcegate.online/daniel/furtka/releases/tag/26.5-alpha). Follow-up caught during the test (separate fix, not part of the hot path): the SHA-256 fingerprint overflowed the Local HTTPS card because the colon-separated hex string had no wrap opportunities — fixed locally (`e7ee169`), will ride the next push.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: daniel/furtka#10

No description provided.

Rows
Columns