Quasar devServer HTTPS and Vite proxy HTTPS certificate validation

Short answer

No. Quasar CLI v2+ does not propagate devServer.https.ca into the Vite proxy httpsAgent. devServer.https configures the development server's own TLS listener. Proxy entries control backend requests independently, and Quasar does not document a shared CA bridge between them. There is no published plan for a first-class devServer.ca option spanning SPA, SSR, Capacitor, and Electron targets.

Confirmed facts versus likely explanation

Confirmed: devServer.https accepts a boolean for auto-generated certificates or an object with key, cert, and ca. In Node/Vite TLS configuration, ca is primarily used to verify client certificates when mutual TLS is enabled; it does not make browsers or web views trust the server certificate.

Confirmed: proxy trust is decided by the Node process running Vite. Each devServer.proxy entry can specify its own agent. Quasar does not expose a global proxy CA option that inherits from devServer.https.ca.

Likely explanation: the two trust decisions are intentionally separate. The dev server certificate must be trusted by each client. The proxy must trust the backend certificate separately within Node. Combining them would conflate client trust with server-side outbound trust.

Steps for this case

1. Determine whether failing requests pass through devServer.proxy or call the backend directly from the client or web view.
2. If they pass through the proxy, configure the proxy entry with an explicit HTTPS agent:

import fs from 'node:fs';
import path from 'node:path';
import https from 'node:https';

const caPath = path.resolve(__dirname, 'certs', 'local-ca.pem');

export default function (ctx) {
  return {
    devServer: {
      https: {
        key: fs.readFileSync(path.resolve(__dirname, 'certs', 'server.key')),
        cert: fs.readFileSync(path.resolve(__dirname, 'certs', 'server.crt')),
        ca: [fs.readFileSync(caPath)]
      },
      proxy: {
        '/api': {
          target: 'https://backend.local:8443',
          changeOrigin: true,
          agent: new https.Agent({
            ca: [fs.readFileSync(caPath)]
          })
        }
      }
    }
  };
}

Alternatively, run NODE_EXTRA_CA_CERTS=/abs/path/local-ca.pem quasar dev so Node trusts the backend CA for outbound requests from the Vite process.

1. For the dev server certificate itself, install the issuing CA into each client trust store: desktop browser, device trust settings for Capacitor or Cordova, and Electron's certificate handling. Node-only trust does not cover web views.

Missing diagnostic detail

Confirm whether the failing request originates from the browser or web view through Vite proxy, or directly from the app to the backend. If it bypasses the proxy, NODE_EXTRA_CA_CERTS will not help; trust the backend CA on the client or operating system instead.

Assumptions and uncertainty

• This assumes Quasar CLI v2 with @quasar/app-vite and Vite's standard proxy implementation. Older Quasar versions or custom Vite overrides may behave differently.
• No Quasar roadmap item for unified devServer.ca is confirmed. Do not design around an undocumented feature.
• Node TLS options normally expect PEM contents or Buffers. If your Quasar version accepts file paths directly, verify that behavior in your installed version.

Verification

1. Reproduce with a private-CA HTTPS backend through devServer.proxy, capture the exact Node error, then rerun with NODE_EXTRA_CA_CERTS set to that CA PEM and no other change.
2. Inspect the served certificate with openssl s_client -connect localhost:PORT -servername localhost and confirm the issuer and chain in the browser or operating-system trust view.
3. Run quasar info to confirm @quasar/app-vite and Vite versions before applying version-specific configuration.
4. For Capacitor, Cordova, or Electron, repeat the HTTPS load on the actual target. Success in desktop Chrome does not prove the web view trusts the certificate.