Domains and SSL

With NODE_ENV=production the login response sets accessToken and sessionId with Secure and SameSite=None. Browsers discard Secure cookies delivered over HTTP, and SameSite=None is invalid without Secure. The login request returns 200, the session is created server-side, and the very next request arrives anonymous — with nothing in the logs that looks like a failure. No setting relaxes this. The certificate is part of the install, not optional hardening.

dig +short example.com
dig +short www.example.com

location ^~ /.well-known/acme-challenge/ {
    default_type "text/plain";
    root /var/www/html;
    try_files $uri =404;
}

A server-level return 301 https://$host$request_uri; runs before any location block, so it rewrites the challenge request too and validation fails. Scope the redirect as location / { return 301 https://$host$request_uri; } instead, so the ACME block above can still win. Set root to the same document root the challenge files are written to — on a panel-managed box that is the site's real docroot, not /var/www/html.

1. Install certbot — from the distribution packages.

   apt install certbot python3-certbot-nginx

2. Prove the vhost is valid — a config error here reads as a certbot failure later.

   nginx -t && systemctl reload nginx

3. Request the certificate — both names in one command, so one certificate covers both.

   certbot --nginx -d example.com -d www.example.com

   --nginx edits the vhost for you: it adds the listen 443 ssl block, the ssl_certificate lines and an HTTP-to-HTTPS redirect. On a hand-written vhost with the proxy blocks already in place, prefer certonly so certbot writes nothing:

   certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com

   With certonly you add the listen 443 ssl;, ssl_certificate and ssl_certificate_key lines yourself, pointing at /etc/letsencrypt/live/example.com/fullchain.pem and privkey.pem.

4. Check TLS is really serving the app — /api/settings is unauthenticated and is the same readiness probe the updater uses, so a JSON body here proves the certificate, the proxy and the backend are all working together.

   curl -sI https://example.com | head -1
   curl -sS https://example.com/api/settings | head -c 120

#!/bin/sh
systemctl reload nginx

chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
systemctl list-timers | grep certbot
certbot renew --dry-run

API responses carry Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Once a browser has seen that over HTTPS it refuses plain HTTP to the domain and every subdomain for a year, and clearing it is a per-visitor action you cannot perform. So: do not go live on HTTPS while a subdomain you also serve is still HTTP-only, and treat "we will move back to HTTP for a bit" as impossible for anyone who has already visited.

NEXT_PUBLIC_SITE_URL="https://example.com"
APP_PUBLIC_URL="https://example.com"
FRONTEND_URL="https://example.com"
NEXT_PUBLIC_WS_URL="wss://example.com"

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;

This page previously showed $proxy_add_x_forwarded_for on that line, which appends to whatever the client sent rather than replacing it, producing <attacker's choice>, <real client> at the backend. The backend reads that list from the right, so the forgery is ignored — but $remote_addr removes the ambiguity at the source and costs nothing.

$remote_addr overwrites the header with the address nginx actually accepted the connection from, which is the only value a visitor cannot forge. nginx configuration has always shown it this way; the two pages disagreed, and an operator following the SSL step landed on the vulnerable combination while being told it was correct.

Editing .env and restarting does nothing for NEXT_PUBLIC_SITE_URL or NEXT_PUBLIC_WS_URL. Both are inlined into the browser bundle when the frontend is built, and the hostname is written into the next/image allowlist at the same moment. Until you rebuild, browsers keep calling the old origin and next/image refuses every image served from the new one.

pnpm stop
pnpm build:frontend
pnpm start

pnpm stop raises the maintenance page and proves ports 3000 and 4000 are free before the build starts, so this is the safe order rather than building in place.

1. Add the DNS records for the new name and let them resolve, keeping the old ones live for now.

2. Issue a certificate for the new name with the ACME location already in place on the new vhost.

3. Update .env — NEXT_PUBLIC_SITE_URL, APP_PUBLIC_URL, FRONTEND_URL and NEXT_PUBLIC_WS_URL together. Leaving one behind is what produces the half-broken states above.

4. Rebuild and restart — nothing in the browser changes until this runs.

   pnpm stop
   pnpm build:frontend
   pnpm start

5. Re-paste every webhook URL into each payment provider's dashboard. Open the gateway's page under Finance → Payment Systems → Gateways and copy the URL shown there — it is now built from the new APP_PUBLIC_URL. Providers keep posting to whatever you told them last.

6. Update the authorised origins for Google sign-in in the Google Cloud console if NEXT_PUBLIC_GOOGLE_CLIENT_ID is configured. Google rejects the sign-in from an origin it does not know, and the button simply does nothing.

7. Keep the old domain redirecting for as long as e-mails, referral links and bookmarks with the old host are still in circulation.