HTTPS and the local CA

Canonical .knot names are not ordinary public DNS names, so client-side browser compatibility uses a local per-device CA.

Two trust layers

browser -- local TLS --> KnotRoute proxy -- authenticated service session --> .knot service

The browser trusts the local proxy certificate. KnotRoute independently authenticates the remote service identity.

Server-side impact

A hidden web service can usually expose plain HTTP to its local sidecar, for example app:8080. A public WebPKI certificate is still needed for any ordinary public hostname served through Traefik/Caddy/nginx.

Certificate errors

Do not click through certificate warnings. Verify CA installation, proxy use, system time and the .knot hostname.

Why not one network-wide CA

A shared CA private key would create an unnecessary global secret. A local CA limits compromise impact to a single device and keeps Control/Beacon out of the certificate-authority role.

Which addresses support HTTPS

Local TLS termination applies to every resolvable .knot hostname:

https://<service-identity>.knot/
https://web.<node-identity>.knot/
https://<local-alias>.knot/

For service.node.knot, browser TLS terminates on the client and ordinary HTTP is carried to the selected service listener inside KnotRoute. The remote application does not need its own TLS listener just for .knot.

Older clients that blindly tunnel CONNECT to a plaintext HTTP service produce ERR_SSL_PROTOCOL_ERROR. Update the client; enabling TLS on the sidecar target is not the correct fix.

Source