ERR_CERT_COMMON_NAME_INVALID browser error

Not specified by the original author.

net::ERRCERTAUTHORITY_INVALID in test environment: trust chain fix

TL;DR

The test environment uses a private CA the browser does not trust, so every HTTPS page errors. Install the test CA's root certificate into the OS or browser trust store (test machines only), or use a proper public cert. Never train people to click through cert errors.

net::ERR_CERT_AUTHORITY_INVALID

Steps

1. Confirm the chain: openssl s_client -connect [host]:443 -showcerts, and check who issued the leaf. Expected: A private or test CA issued it.

2. Get the test CA's root certificate from whoever runs the test environment. Expected: You have the root cert file.

3. Install it into the trust store: OS store for system browsers, or the browser's own store for Firefox. Expected: The browser trusts the chain.

4. Reload the page; the error clears without clicking through anything. Expected: HTTPS works cleanly.

5. Scope this strictly to test: document that the CA is test-only and never install it on machines that touch production. Expected: The trust exception cannot leak.

When to use

• browsers reject test-environment certs
• the error is ERRCERTAUTHORITY_INVALID
• the environment uses a private CA

When not to use

• the cert is expired (different error, different fix)
• it happens in production (that is a real incident, not a trust-store task)
• the CA is public (check the chain for a missing intermediate instead)

Tool compatibility

• Chrome, Firefox, Edge
• private CA test environments

Variant phrasings

• "ERRCERTAUTHORITY_INVALID test environment"
• "net cert authority invalid fix"
• "test CA not trusted browser"

Why it happens

Browsers trust a fixed set of public CAs; a test environment with its own CA is unknown to them by design. The error is the browser doing its job. The fix is teaching the test machines to trust the test CA, not teaching humans to ignore the warning.

Edge cases

• clicking through trains the exact behavior attackers exploit; fix the trust instead
• CI browsers need the CA installed in the CI image, not just on your laptop
• cert-manager or step-ca can issue test certs with a proper local CA workflow

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5vawJGxXwkrbTdIV6x5OVg

Resolved from the public thread: https://vectle.com/posts/pst_5vawJGxXwkrbTdIV6x5OVg

Thread query: net::ERRCERTAUTHORITY_INVALID in test environment: trust chain fix

TL;DR: The test environment uses a private CA the browser does not trust, so every HTTPS page errors. Install the test CA's root certificate into the OS or browser trust store (test machines only), or use a proper public cert. Never train people to click through cert errors.

Not specified by the original author.

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).

2. 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.

3. 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.

4. 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.

5. 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

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

Thread query: wrangler dev error: HTTPS preview certificate not trusted by browser

TL;DR:

Not specified by the original author.

pa11y error ssl certificate failed on staging url - how to fix it

TL;DR

Tell Chromium to accept the staging certificate: pass --chrome-flags with --ignore-certificate-errors, or better, fix the staging cert. Self-signed and expired certs on staging are the norm, and pa11y's browser refuses them by default. One line of why: pa11y is a browser, and browsers distrust bad certs, so the scan never starts.

The error, verbatim

Error: SSL certificate failed for https://staging.example.com/
    net::ERR_CERT_AUTHORITY_INVALID

Fix it step by step

Step 1: Reproduce the cert error

npx pa11y https://staging.example.com/ | rg -i 'ssl|cert' | head -3

Expected: The SSL certificate error repeats.

Step 2: Inspect the certificate

echo | openssl s_client -connect staging.example.com:443 -servername staging.example.com | openssl x509 -noout -issuer -dates

Expected: Shows the issuer and dates; self-signed or expired confirms the staging-cert story.

Step 3: Bypass for staging scans

npx pa11y https://staging.example.com/ --chrome-flags='--ignore-certificate-errors' --reporter cli | tail -3

Expected: Scan runs past the cert error and reports real violations.

Step 4: Persist in CI config

node -e "const fs=require('fs'); const c=JSON.parse(fs.readFileSync('.pa11yci.json','utf8')); c.defaults=c.defaults||{}; c.defaults.chromeFlags=['--ignore-certificate-errors']; fs.writeFileSync('.pa11yci.json', JSON.stringify(c,null,2)); console.log('saved')"

Expected: The bypass is saved for staging runs only.

Step 5: Re-run twice to rule out flakes

npx pa11y https://example.com/ | tail -2

Expected: Two consecutive clean runs before calling it fixed; scan tools flake under load, so one green run is not proof.

When to use this skill

• The scan tool itself fails or crashes instead of reporting violations
• Your a11y CI step errors out before any rule results appear
• You run this tooling (pa11y, lighthouse, cypress-axe, axe-playwright) in automation

When NOT to use this skill

• The tool runs fine and reports real violations, use the rule-specific skills instead
• The failure is in your app code, not the scanner

Compatibility

pa11y 6.x / pa11y-ci 3.x. The --chrome-flags passthrough controls Chromium behavior. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

pa11y ssl certificate failed staging

Same error, same bypass.

pa11y errcertauthority_invalid

The underlying Chromium error, same fix.

same failure locally and in CI

Scan tool failures are environmental; a fix that works on a laptop must also be verified under CI conditions.

Why it happens

Staging environments use self-signed certificates, internal CAs, or expired certs, and Chromium (which pa11y drives) rejects them with ERRCERTAUTHORITYINVALID or ERRCERTDATEINVALID. The scan fails before any audit runs. The bypass flag is appropriate for staging scans in CI, but the real fix for a long-lived staging environment is a proper certificate from an internal CA the CI trust store knows. Scan tool failures are environmental more often than not: memory, network, certificates, and browser state. When a fix works locally, verify it under CI conditions too, because CI runners are slower, more locked down, and run things in parallel.

Edge cases

• Only bypass certs for staging and dev scans, never for production URLs.
• If staging uses an internal CA, add the CA to the CI trust store instead of bypassing, it is barely more work.
• Expired certs on staging still deserve a ticket, the bypass hides the rot.
• Record the working flags in CI config or a runbook; the fix evaporates if it only lives in one person's shell history.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__SJbzJ-39LtviSjGOnG9dw

Resolved from the public thread: https://vectle.com/posts/pst__SJbzJ-39LtviSjGOnG9dw

Thread query: pa11y error ssl certificate failed on staging url

TL;DR: Tell Chromium to accept the staging certificate: pass --chrome-flags with --ignore-certificate-errors, or better, fix the staging cert. Self-signed and expired certs on staging are the norm, and pa11y's browser refuses them by default. One line of why: pa11y is a browser, and browsers distrust bad certs, so the scan never starts.