What is the difference between the Stirling Docker variant via browser and the desktop variant?

[techsupportkoeln]

Hello,
I've been using Stirling PDF for a while now as a Docker variant on an Ubuntu server with Nginx as a reverse proxy.
Although it's only available internally, I'm using it with a valid SSL certificate.

My problem is that I cannot log in via the Stirling Desktop variant on either Windows 11 or macOS. I always get an error message stating that the server is unreachable.

However, everything works fine via the browser. So now I'm wondering, what is actually the difference between the Docker version and the Desktop version?

Or is it even more efficient for individuals to use the desktop version?

Alternatively, I would also appreciate tips on how to find the error so that I can log in to my Stirling Docker version using the desktop variant.

[fstandhartinger]

What's different. The browser version is just the web UI your server serves, so every request goes through Chrome/Edge/Safari's own network stack. The desktop app is a Tauri app with its own bundled backend (a JRE plus the Stirling jar, used for the "local tools") and can optionally connect to your server. Its requests to your server don't go through the webview's network stack. They go through Tauri's Rust HTTP client (tauri-plugin-http → reqwest + rustls). For one person on one machine, the desktop app alone is enough because everything runs locally. The Docker server is worth it when several people or devices share it, or when you want login/SSO.

Most likely cause: Nginx sends an incomplete certificate chain. "Works in the browser, desktop app says unreachable" is the classic sign of this. Browsers quietly download a missing intermediate certificate (AIA fetching) and cache intermediates they've seen before. rustls does neither. In the current code (cd48ccb), the desktop app checks certificates in three different ways:

• The setup wizard's connection test falls back to "no cert validation" if the strict check fails (connectionModeService.ts#L447-L451).
• The normal API client always sets acceptInvalidCerts for https (tauriHttpClient.ts#L287-L296).
• The background health check that drives the "Your Stirling-PDF server is unreachable" banner validates strictly, with no bypass (selfHostedServerMonitor.ts#L102-L105).

So a chain that a browser accepts can still make the desktop app call your server offline.

Check it from the Ubuntu box (OpenSSL doesn't fetch missing intermediates either, so it behaves like the desktop app):

openssl s_client -connect your.host:443 -servername your.host </dev/null 2>/dev/null \
  | grep -E '^ *[0-9] s:|^Verify return code'
curl -sS https://your.host/api/v1/info/status

• If you only see 0 s: and Verify return code: 21 (unable to verify the first certificate), the chain is incomplete. I reproduced exactly that output with a leaf-only test server. Sending the intermediate as well gives 1 s: and 0 (ok).
• The fix is in Nginx: ssl_certificate must point to the full chain. For Let's Encrypt that's fullchain.pem, not cert.pem. For a purchased cert, concatenate your certificate and then the CA's intermediate into one file. Then run nginx -t && systemctl reload nginx.
• If you use your own internal CA, the root must be in the Windows/macOS trust store. The desktop app's client loads the OS store (rustls-native-certs), but it still needs the intermediate from the server.

If the chain is fine, the curl above should return {"status":"UP",...}. That's the exact URL the desktop app polls, and it's public even with login enabled. If curl fails, or returns HTML or a 404, your Nginx location (for example a sub-path or an IP allowlist that doesn't include the client) isn't passing /api/v1/info/status through. When you enter the server URL in the app, write it exactly as you do in the browser, including any sub-path. Without a scheme, the app prepends https://.

Disclosure: I build a hosted HTML-to-PDF API (not linked here, not related to this problem). I traced this through the Stirling-PDF source with an AI assistant (Claude Code) and ran the certificate-chain test before posting.

[techsupportkoeln]

Thank you for the detailed answer. I use ACME with the DNS-01 challenge to provide a valid certificate for the Nginx proxy. It is a Let's Encrypt certificate. The Stirling server itself is only accessible within the internal network, but it has a subdomain (pdf..com) assigned to it. My clients access the server via this subdomain since I modified the hosts file accordingly.

root@STIRLING:~# openssl s_client -connect pdf.xyz.com:443 -servername pdf.xyz.com </dev/null 2>/dev/null \ | grep -E '^ *[0-9] s:|^Verify return code' curl -sS https://pdf.xyz.com/api/v1/info/status 0 s:CN=pdf.xyz.com 1 s:C=US, O=Let's Encrypt, CN=YR2 2 s:C=US, O=ISRG, CN=Root YR Verify return code: 0 (ok) {"version":"3.2.2","status":"UP"}root@TSK-STIRLING:~# ^C root@STIRLING:~#

did i miss something in the nginx config?

`server {
listen 80;
server_name pdf.xyz.com; # Passen Sie dies an

# HTTP zu HTTPS Weiterleitung (optional, falls SSL genutzt wird)
return 301 https://$host$request_uri;

}

server {
listen 443 ssl http2;
server_name pdf.xyz.com; # Passen Sie dies an

# SSL Zertifikate (Pfade anpassen)
ssl_certificate /etc/ssl/certs/stirling.crt;
ssl_certificate_key /etc/ssl/private/stirling.key;

# Maximale Upload-Gr   ^=e f  r gro ^=e PDFs (auf z.B. 100M setzen)
client_max_body_size 100M;

location / {
    proxy_pass http://127.0.0.1:8080; # IP und Port von Stirling PDF
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # WebSocket-Unterst  tzung f  r aktive Verbindungen
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    # Timeouts f  r gro ^=e PDF-Verarbeitungen erh  hen
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;
    proxy_connect_timeout 600s;
}

}`