wrangler dev error: HTTPS preview certificate not trusted by browser

TL;DR

wrangler dev serves HTTPS with a locally generated self-signed certificate, which no browser trusts by default. Either accept the risk once in the browser (fine for local testing), or run wrangler dev over plain HTTP if your feature does not need secure context. The certificate is expected and safe; it only exists on your dev machine.

wrangler dev error: HTTPS preview certificate not trusted by browser

1. Confirm which URL you are opening. wrangler dev prints both, typically http and https variants on port 8787.

Expected: you know whether the warning is on the https URL (expected) or the http URL (something else is wrong).

1. If your feature does not need a secure context (most API testing, plain fetch handlers), just use the http URL.

Expected: the page loads with no warning. Cookies with Secure flags and some Web APIs will not work over http, which is the trade-off.

1. If you need https (Secure cookies, crypto.subtle in some contexts, service workers), open the https URL and use the browser's advanced option to proceed past the warning. In Chrome this is "Advanced" then "Proceed to [host] (unsafe)".

Expected: the warning is bypassed for this host. The certificate has not changed; the browser just recorded your exception.

1. To avoid the click-through every session, add the certificate to your OS trust store once. wrangler dev generates the cert locally; trusting your machine's own dev CA is the standard fix (the same pattern tools like mkcert use).

Expected: after trusting, the https preview loads with a clean lock icon and no warning.

1. Verify the worker actually responds over the trusted connection by making a request that exercises the feature you needed https for.

Expected: the secure-context feature works. If it does not, the problem was never the certificate.

Use this when

• The browser warns about the certificate on the wrangler dev https URL.
• You need to test Secure cookies, service workers, or other secure-context features locally.
• The warning appeared after switching from http to https in dev.

Not for this skill when

• A deployed workers.dev or custom-domain URL shows a cert warning. That is a real TLS problem, not a dev cert; do not bypass it.
• The page fails to load with connection refused instead of a cert warning. The dev server is not running or the port is wrong.
• The API response is wrong but the page loads fine. Certificate trust is unrelated.

Variant phrasings

• wrangler dev https certificate invalid
• NET::ERRCERTAUTHORITY_INVALID wrangler dev
• cloudflare workers local https not trusted
• wrangler dev self signed certificate browser warning

Why it happens

Browsers only trust certificates signed by a certificate authority in their trust store. wrangler dev cannot get a publicly trusted cert for a local address, so it generates a self-signed one on the fly. Every browser correctly flags it as untrusted, because from the browser's point of view it is indistinguishable from an attacker's cert. This is normal local-dev behavior across every framework, not a Cloudflare bug.

Edge cases

• The cert regenerates when you clear wrangler's local state, so a previously trusted exception can stop applying. Re-trust after wiping .wrangler.
• Firefox uses its own certificate store, separate from the OS store. Trusting at the OS level fixes Chrome/Edge/Safari but not Firefox; add the exception inside Firefox too.
• Automated browser tests (Playwright, Cypress) need an ignore-https-errors flag for the dev URL; otherwise the suite fails on the cert, not on your code.
• If you proxy the dev server through another tool, the browser sees the proxy's cert, not wrangler's. Trust or bypass at the proxy layer instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstWhq1cl-KMUGTRBsfjlc7g