image
Fix intermittent 502 on dashboard attestation verification
The attestation dialog intermittently failed with 502, then recovered on its own — while a direct curl
http:///attestation always worked.
Cause: the API proxy forced HTTPS and preferred the domain (https:///attestation), hitting the enclave's
Caddy block that uses on-demand Let's Encrypt TLS. Uncached certs trigger inline ACME issuance during the handshake;
when that's slow/rate-limited/fails, the handshake fails and the API returns 502. Once the cert is cached it works
again — hence the come-and-go behavior. The working curl never hit TLS (port 80), which is why it was unaffected.
Fix: proxy attestation over plain HTTP by IP — the path that's proven reliable. The attestation document is a
COSE_Sign1 verified entirely client-side (cert chain + signature + nonce), so transport TLS isn't load-bearing here.
This drops the on-demand ACME dependency. Also removed the now-unneeded danger_accept_invalid_certs and tidied the
query to query_scalar.
Fix intermittent 502 on dashboard attestation verification
The attestation dialog intermittently failed with 502, then recovered on its own — while a direct curl
http://<ip>/attestation always worked.
Cause: the API proxy forced HTTPS and preferred the domain (https://<domain>/attestation), hitting the enclave's
Caddy block that uses on-demand Let's Encrypt TLS. Uncached certs trigger inline ACME issuance during the handshake;
when that's slow/rate-limited/fails, the handshake fails and the API returns 502. Once the cert is cached it works
again — hence the come-and-go behavior. The working curl never hit TLS (port 80), which is why it was unaffected.
Fix: proxy attestation over plain HTTP by IP — the path that's proven reliable. The attestation document is a
COSE_Sign1 verified entirely client-side (cert chain + signature + nonce), so transport TLS isn't load-bearing here.
This drops the on-demand ACME dependency. Also removed the now-unneeded danger_accept_invalid_certs and tidied the
query to query_scalar.