Start DSH web with native TLS: cert chain, key and cookies

DeepSeek Harness can terminate TLS inside dsh web: add --tls-cert and --tls-key, and the listener serves HTTPS on its existing port, 3080 by default. This is the shortest path when one host owns one endpoint and you do not want another proxy in front. The trade-off is certificate lifecycle: files are read once, a bad file fails startup, and rotation requires a restart.

DeepSeek Harness: When native TLS is the right choice

Native TLS pays off when the browser can reach this host directly; if a shared entry point already exists, let the proxy own TLS. Three common shapes:(source)

Native TLS does not request certificates, renew them, or watch files. It only loads the files you give it and serves HTTPS. That narrow scope is the point.

DeepSeek Harness: Four hard requirements for the files

The official requirements are specific: a full chain, an unencrypted key, paths resolved from the process working directory, and files read only at startup. Check each one:(source)

1. Put the full chain in the certificate file — include intermediate certificates in order. Expected: openssl s_client -connect host:3080 -showcerts shows the site certificate and intermediates.
2. Use an unencrypted PEM key — a passphrase-protected key cannot be unlocked automatically. Expected: openssl pkey -in server.key -noout succeeds without prompting.
3. Resolve relative paths against the process cwd — --tls-cert and --tls-key are relative to where dsh starts, not to a config directory. Expected: use absolute paths when starting from arbitrary directories.
4. Cover the actual access name — the browser validates names against its own trust store. Expected: the SAN includes the hostname or IP you open.

Fail any of these and startup fails. The official behavior is explicit: missing or invalid files are a startup error, never an HTTP fallback.

DeepSeek Harness: Start and verify

The minimal command is dsh web --tls-cert <cert> --tls-key <key>; add --public-url and --trusted-host for external access. A complete example:(source)

dsh web \
  --tls-cert /etc/dsh/fullchain.pem \
  --tls-key /etc/dsh/privkey.pem \
  --public-url https://dsh.example.com/ \
  --trusted-host dsh.example.com

1. Check the listener locally — curl -vk https://127.0.0.1:3080/. Expected: TLS handshake succeeds; a self-signed certificate warns but does not refuse the connection.
2. Check the chain — openssl s_client -connect 127.0.0.1:3080 -servername dsh.example.com -showcerts. Expected: the site and intermediate certificates are present.
3. Check the browser path — open the --public-url address and exchange the startup token for a cookie. Expected: the address bar stays on HTTPS and the auth page does not loop.

If step 1 fails, read the terminal error for “file missing”, “key cannot be parsed”, or “certificate/key mismatch” before touching proxy settings.

DeepSeek Harness: Secure cookies, public-url, and trusted-host

TLS protects transport; it does not decide whether an authority is trusted. --public-url announces, --trusted-host admits. Keep the three roles separate:(source)

• TLS adds Secure to the session cookie — the browser will only send it over HTTPS. If another proxy terminates TLS in front, that hop must not downgrade the cookie.
• --public-url is an announcement — it feeds the printed startup URL, DSH_WEB_URL, and the Web GUI URL in agent runtime context. It does not admit a host through the fence.
• --trusted-host is the fence list — an authority not on the list gets 403 on every /api call, even when TLS is perfect.

A common false alarm: the page opens, but every API returns 403. That is the trust fence, not the certificate. Copy the browser authority into --trusted-host and restart.

DeepSeek Harness: Certificate checks worth running

A configured TLS listener is not the same as a correct certificate; three read-only commands answer the important questions. Run them before blaming DSH:(source)

1. Which names are covered — openssl x509 -in fullchain.pem -noout -text | grep -A1 "Subject Alternative Name". Expected: the hostname or IP you use is listed.
2. Is the chain complete — openssl verify -CAfile ca.pem -untrusted intermediate.pem server.pem. Expected: OK; a site-only file fails with an issuer error.
3. Does the handshake work — openssl s_client -connect 127.0.0.1:3080 -servername dsh.example.com -showcerts. Expected: the expected chain appears and verification succeeds or fails only because the local root is missing.

These commands do not test Web authentication or the trust fence. A successful handshake with 403 responses still points back to --trusted-host.

DeepSeek Harness: Rotation, limits, and what to avoid

Rotation means replace the files and restart or reload the listener; the process does not watch the files. The safe order:(source)

1. Back up the old pair — keep the old certificate and key readable. Expected: you can roll back immediately.
2. Validate the new pair — run openssl verify and openssl pkey -noout. Expected: both pass before restart.
3. Restart and re-check — repeat the curl and s_client checks. Expected: the new fingerprint appears.

Avoid native TLS when you need automatic renewal, path-based routing to multiple backends, or a shared WAF and access log. In those cases, terminate TLS at the proxy and keep dsh web on loopback.

DeepSeek Harness FAQ

Can I use a self-signed certificate? Yes, but every client must trust its root. DSH serving the certificate does not make the browser trust it; phones and other machines need the root separately.

Can I change the port to 443? Yes, with dsh web --port 443. Port 443 may require extra privileges and container port mapping; update --public-url and --trusted-host to match.

Do I still need a reverse proxy after enabling native TLS? No, unless you need domain routing, WAF, centralized certificates, or access logs. Native TLS and proxy TLS are alternatives, not mandatory layers.

Why does the browser ask me to authenticate again after a restart? The session cookie is bound to hostname and port. Changing either, or changing the access authority through TLS configuration, invalidates the old cookie.

The short version: native TLS gives dsh web its own certificate; it works for a single entry point, but the certificate is only half the job—--trusted-host and Secure cookies make it usable.