espresso_frame

211 Commits 2 Branches 13 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
tfaour	5588ce3e1b	HTTPS trust: use the public CA bundle + one missing root, not a pinned cert Build and push server image / build-and-push (push) Successful in 33s Details Root-caused the earlier "No matching trusted root certificate found" failure properly this time by reading ESP-IDF's actual bundle-matching code (esp_crt_bundle.c): it looks up a trusted root by the ISSUER name of whatever certificate it can't otherwise validate, not by matching the presented certificate itself. The live server's chain ends in a GTS Root R4 certificate cross-signed by the old GlobalSign Root CA R1 (common Cloudflare/Google Trust Services practice, for compatibility with older/embedded clients) -- and ESP-IDF's current bundle snapshot has dropped that old GlobalSign root entirely, so the lookup came up empty. This was a general gap, not something specific to this one deployment's cert. Fix: keep the standard public CA bundle (esp_crt_bundle_attach) as the trust mechanism -- so any normal reverse-proxy cert (Let's Encrypt, etc.) works out of the box -- and add the one missing root on top via ESP-IDF's CONFIG_MBEDTLS_CUSTOM_CERTIFICATE_BUNDLE mechanism (sdkconfig.defaults), which appends a project-supplied cert file to the bundle at build time. Fetched GlobalSign's official Root CA R1 cert and cryptographically verified (openssl verify) it actually validates the live server's certificate before embedding it -- see firmware/main/certs/additional_root_ca.pem (replaces the old tools_server_ca.pem, which pinned one exact certificate directly and would've broken for anyone else's reverse proxy). Confirmed working against the real deployment on hardware.	2026-07-19 17:38:39 -04:00
tfaour	bb4f473bfa	Fix HTTPS handshake: trust the actual cert the proxy presents, not Origin CA The Tools Server hostname turned out to be Cloudflare-proxied, not a direct connection to nginx -- so the ESP32 (and any browser) sees Cloudflare's own edge certificate (issued by Google Trust Services), never the Origin CA cert, which only ever sits on the Cloudflare-to- origin leg. Confirmed on hardware: ESP_ERR_HTTP_CONNECT. Tried switching to ESP-IDF's built-in public CA bundle instead (esp_crt_bundle_attach) as the more general fix, but that also failed on hardware ("No matching trusted root certificate found") -- the bundle's copy of the relevant Google root has the same name and public key as the live one but a different serial/signature (a reissue), and the bundle does an exact byte-level match, not a semantic one. Simplest reliable fix: embed the exact certificate the proxy actually presents (extracted live via openssl s_client, see firmware/main/certs/tools_server_ca.pem) and trust that directly via cert_pem, sidestepping bundle-matching semantics entirely. Documented in firmware/README.md how to re-extract if the proxy's CA ever changes.	2026-07-19 12:09:08 -04:00
tfaour	6c7468a36e	Add HTTPS support and a management-token gate for the web UI Build and push server image / build-and-push (push) Successful in 31s Details ESP32 side can now reach the tools server over HTTPS: the Tools Server field accepts an https:// address for a TLS-terminating reverse proxy in front of the server (which still only ever speaks plain HTTP itself), trusting Cloudflare's Origin CA root (embedded at build time) since that's the common way to get a real cert on a private origin. Every URL the device builds -- image fetch, config check, manage-menu data, the QR codes' own links -- goes through one build_url() helper that picks the scheme from what's configured. Also adds an optional MANAGEMENT_TOKEN (docker-compose.yml) that gates the web UI (/, /api/) behind a shared secret -- unset by default, so existing trusted-LAN deployments are unaffected. The same token is entered once during the ESP32's captive-portal setup and gets baked into the manage-menu's QR code (?token=...), so scanning it just works; visiting the page without a valid token shows a plain entry prompt instead of the config UI, and a valid query-param hit sets a cookie so the page's own fetch()/<img> calls stay authorized for the rest of the visit. Device-facing /frame/ endpoints are unaffected -- a separate, already-documented trust boundary.	2026-07-19 09:42:38 -04:00

Author

SHA1

Message

Date

tfaour

5588ce3e1b

HTTPS trust: use the public CA bundle + one missing root, not a pinned cert

Build and push server image / build-and-push (push) Successful in 33s

Details

Root-caused the earlier "No matching trusted root certificate found"
failure properly this time by reading ESP-IDF's actual bundle-matching
code (esp_crt_bundle.c): it looks up a trusted root by the ISSUER name
of whatever certificate it can't otherwise validate, not by matching
the presented certificate itself. The live server's chain ends in a
GTS Root R4 certificate cross-signed by the old GlobalSign Root CA R1
(common Cloudflare/Google Trust Services practice, for compatibility
with older/embedded clients) -- and ESP-IDF's current bundle snapshot
has dropped that old GlobalSign root entirely, so the lookup came up
empty. This was a general gap, not something specific to this one
deployment's cert.

Fix: keep the standard public CA bundle (esp_crt_bundle_attach) as the
trust mechanism -- so any normal reverse-proxy cert (Let's Encrypt,
etc.) works out of the box -- and add the one missing root on top via
ESP-IDF's CONFIG_MBEDTLS_CUSTOM_CERTIFICATE_BUNDLE mechanism
(sdkconfig.defaults), which appends a project-supplied cert file to the
bundle at build time. Fetched GlobalSign's official Root CA R1 cert and
cryptographically verified (openssl verify) it actually validates the
live server's certificate before embedding it -- see
firmware/main/certs/additional_root_ca.pem (replaces the old
tools_server_ca.pem, which pinned one exact certificate directly and
would've broken for anyone else's reverse proxy). Confirmed working
against the real deployment on hardware.

2026-07-19 17:38:39 -04:00

tfaour

bb4f473bfa

Fix HTTPS handshake: trust the actual cert the proxy presents, not Origin CA

The Tools Server hostname turned out to be Cloudflare-proxied, not a
direct connection to nginx -- so the ESP32 (and any browser) sees
Cloudflare's own edge certificate (issued by Google Trust Services),
never the Origin CA cert, which only ever sits on the Cloudflare-to-
origin leg. Confirmed on hardware: ESP_ERR_HTTP_CONNECT.

Tried switching to ESP-IDF's built-in public CA bundle instead
(esp_crt_bundle_attach) as the more general fix, but that also failed
on hardware ("No matching trusted root certificate found") -- the
bundle's copy of the relevant Google root has the same name and public
key as the live one but a different serial/signature (a reissue), and
the bundle does an exact byte-level match, not a semantic one.

Simplest reliable fix: embed the exact certificate the proxy actually
presents (extracted live via openssl s_client, see
firmware/main/certs/tools_server_ca.pem) and trust that directly via
cert_pem, sidestepping bundle-matching semantics entirely. Documented
in firmware/README.md how to re-extract if the proxy's CA ever changes.

2026-07-19 12:09:08 -04:00

tfaour

6c7468a36e

Add HTTPS support and a management-token gate for the web UI

Build and push server image / build-and-push (push) Successful in 31s

Details

ESP32 side can now reach the tools server over HTTPS: the Tools Server
field accepts an https:// address for a TLS-terminating reverse proxy
in front of the server (which still only ever speaks plain HTTP
itself), trusting Cloudflare's Origin CA root (embedded at build time)
since that's the common way to get a real cert on a private origin.
Every URL the device builds -- image fetch, config check, manage-menu
data, the QR codes' own links -- goes through one build_url() helper
that picks the scheme from what's configured.

Also adds an optional MANAGEMENT_TOKEN (docker-compose.yml) that gates
the web UI (/, /api/*) behind a shared secret -- unset by default, so
existing trusted-LAN deployments are unaffected. The same token is
entered once during the ESP32's captive-portal setup and gets baked
into the manage-menu's QR code (?token=...), so scanning it just works;
visiting the page without a valid token shows a plain entry prompt
instead of the config UI, and a valid query-param hit sets a cookie so
the page's own fetch()/<img> calls stay authorized for the rest of the
visit. Device-facing /frame/* endpoints are unaffected -- a separate,
already-documented trust boundary.

2026-07-19 09:42:38 -04:00