How to Fix Playwright net::ERR_CERT_AUTHORITY_INVALID

TL;DR

For a disposable local HTTPS server, set ignoreHTTPSErrors: true on the Playwright project or browser context. For staging and CI, install the approved CA, repair any incomplete server chain, and confirm with a strict browser test in the failing environment.

Key Takeaways

• Identify whether page navigation, an API request, or the webServer readiness probe failed.
• Use a narrowly scoped ignoreHTTPSErrors setting only for controlled local endpoints.
• Install an approved private root CA in the runner or container to keep staging checks strict.
• Inspect the final hostname, SNI, and intermediate chain when one site still fails.
• Configure standalone API request contexts and webServer probes separately.
• Verify the repair from the exact CI or Docker environment that reported the error.

To fix Playwright ERR CERT AUTHORITY INVALID, first identify which HTTPS connection fails: a page navigation, an API request, or the test runner's server readiness check. The error commonly appears when a local certificate is self-signed, a company proxy uses a private certificate authority (CA), or a CI container lacks the CA trusted on your laptop.

Error: page.goto: net::ERR_CERT_AUTHORITY_INVALID at https://app.internal.example.test/

A quick bypass can unblock a disposable local test, but a trusted certificate chain is the durable fix. Follow the failing hostname and the failing Playwright operation, then apply only the relevant configuration below.

TL;DR

For a local test that intentionally visits a self-signed HTTPS server, set ignoreHTTPSErrors: true in the Playwright Test use configuration, or set it on the context that creates the page. Run the failing spec again. This bypass is appropriate for a controlled test endpoint, not a default for production monitoring.

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  use: {
    ignoreHTTPSErrors: true,
  },
});

npx playwright test tests/tls.spec.ts --project=chromium

If the same test still fails, identify whether request.get() or webServer.url fails before changing more settings. Those paths have their own certificate handling. For a company or staging CA, install the CA in the environment running the browser and keep strict validation enabled. Playwright project configuration helps when you need different policies for local, staging, and production projects.

What the Error Actually Means

net::ERR_CERT_AUTHORITY_INVALID is a Chromium network error. The browser received a certificate but could not build a trusted path from that certificate to a root CA it accepts. The certificate may be self-signed, issued by a private CA absent from the browser's trust environment, or served without an intermediate certificate. The message describes trust, not whether your page locator or assertion is correct.

The first useful distinction is where the exception begins. page.goto() and resource load failures come from a browser context. An apiRequestContext.get() failure comes from Playwright's API request client. A failure while Playwright starts a configured web server happens before a test obtains its page fixture. Installing NODE_EXTRA_CA_CERTS can help Node-based operations such as Playwright's browser download behind an intercepting proxy, but it is not a substitute for trusting a CA in the browser environment. Similarly, use.ignoreHTTPSErrors does not repair a separate webServer.url probe.

Treat a certificate warning as diagnostic evidence. A redirect may send the browser from a correctly configured host to another host with a different certificate. An HTTPS-inspecting proxy may replace the server's public certificate with one issued by your organization. A container may have a different trust store from your host. Record the failing URL and the step that generated it before choosing a fix.

Root-Cause Decision Table

Use a single failing URL throughout the checks. The examples below use TARGET_URL; set it to your actual test endpoint. A Playwright debugging guide can help you inspect the call that fails before you change certificate policy.

1. Fix Playwright ERR CERT AUTHORITY INVALID on Local HTTPS

A development server often creates a certificate that the browser has never been told to trust. For a deliberately temporary endpoint, bypassing verification in one Playwright project is the fastest fix. Keep a second project with normal validation so the exception cannot silently spread to all environments. The project names make the policy visible in CI output.

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  projects: [
    {
      name: 'local-https',
      use: {
        ...devices['Desktop Chrome'],
        ignoreHTTPSErrors: true,
      },
    },
    {
      name: 'strict-chromium',
      use: {
        ...devices['Desktop Chrome'],
        ignoreHTTPSErrors: false,
      },
    },
  ],
});

// tests/tls.spec.ts
import { test, expect } from '@playwright/test';

const targetURL = process.env.TARGET_URL;
if (!targetURL) throw new Error('Set TARGET_URL to your HTTPS test URL');

test('opens the HTTPS target', async ({ page }) => {
  const response = await page.goto(targetURL);
  expect(response).not.toBeNull();
  expect(response?.ok()).toBe(true);
  await expect(page).toHaveURL(targetURL);
});

Verify with TARGET_URL=https://localhost:8443/ npx playwright test tests/tls.spec.ts --project=local-https. Replace the URL with the origin your server actually uses. A passed test confirms the scoped bypass; it does not prove the certificate is trusted. Run --project=strict-chromium against the same endpoint as a control. It should still report the trust failure until you install an approved local CA.

If your team owns the local server, issue its certificate from a development CA trusted by the test machine instead. Match the certificate's Subject Alternative Name (SAN) to the URL you navigate: a certificate for localhost does not automatically cover 127.0.0.1. Avoid committing a local private key. The Playwright test runner tutorial covers how project selection affects test execution.

2. Trust a Private CA Used by a Company Proxy or Staging Site

An HTTPS-inspecting proxy presents a newly signed certificate for the requested hostname. Your browser may trust the company's root CA because device management installed it, while the Playwright container or clean CI worker does not. Export the approved root CA certificate, not a private key, and verify the certificate with your security or platform team. Do not fetch an arbitrary certificate from the failing site and treat it as a root.

On a Debian or Ubuntu runner, install the PEM-encoded CA in the OS trust store. These commands assume the approved certificate is available as certs/company-root-ca.crt in the build context. The .crt file must contain a CA certificate in PEM form.

sudo install -m 0644 certs/company-root-ca.crt /usr/local/share/ca-certificates/company-root-ca.crt
sudo update-ca-certificates
openssl s_client -connect staging.example.test:443 -servername staging.example.test -verify_return_error </dev/null

The verification command should report Verify return code: 0 (ok) when the remote endpoint supplies a complete chain and the OS store trusts its issuer. If it does not, compare the issuer shown by openssl s_client with the CA you installed. The trust store used by a browser can vary by engine and operating system, so run the strict Playwright navigation test after the OpenSSL check. An OpenSSL pass alone does not prove that Chromium, Firefox, and WebKit will all accept the site.

For Playwright browser downloads behind an intercepting proxy, Node may also need the same root CA. Set NODE_EXTRA_CA_CERTS before npx playwright install, as documented for Playwright's browser installation. This setting addresses that Node process and does not turn off TLS checks.

NODE_EXTRA_CA_CERTS="$PWD/certs/company-root-ca.crt" npx playwright install chromium
TARGET_URL=https://staging.example.test/ npx playwright test tests/tls.spec.ts --project=strict-chromium

If the browser test fails while OpenSSL passes, investigate the browser's trust configuration in that runner instead of adding more global bypass flags. The secrets management in CI guide explains how to deliver sensitive test configuration; a public CA certificate can usually be distributed without storing a private key.

3. Repair a Broken Chain, Hostname, or Redirect

A trusted root on the runner cannot compensate for a server that sends the wrong certificate or omits an intermediate CA. Inspect the exact host that Playwright visits, including any redirected host. Use curl to see the final URL and openssl s_client to see the presented chain. The -servername option sends Server Name Indication (SNI), which matters when one IP serves multiple HTTPS sites.

curl -sS -I -L -o /dev/null -w 'final_url=%{url_effective} http_code=%{http_code}\n' https://staging.example.test/
openssl s_client -connect staging.example.test:443 -servername staging.example.test -showcerts -verify_return_error </dev/null

If curl reports a redirect to login.staging.example.test, inspect that host separately. A certificate's SAN must cover the hostname in the URL after the redirect. An expired certificate usually produces a date-related error rather than ERR_CERT_AUTHORITY_INVALID, but record the dates while inspecting the chain. When the server is missing an intermediate, configure it to serve the leaf certificate plus required intermediates in the correct chain. Do not install a leaf certificate as a root CA to hide a server mistake.

A simple strict Playwright check confirms the repair from the browser's point of view:

TARGET_URL=https://staging.example.test/ npx playwright test tests/tls.spec.ts --project=strict-chromium

Check the test report for the URL it actually loaded. If the final URL legitimately differs from TARGET_URL, adjust the test's toHaveURL assertion to the expected destination before interpreting an assertion failure as another TLS failure. An HTTP status failure and a certificate authority failure are different problems. The former means the connection was made and the server responded; the latter stops the secure connection before an HTTP response is available.

4. Fix Playwright ERR CERT AUTHORITY INVALID in CI and Docker

A green local run and red container run usually means the two environments trust different roots. Use a Playwright image tag that matches the installed Playwright package version; substitute your installed version for the placeholder below. The official image supplies browsers and system dependencies, while your project supplies @playwright/test. Add your approved CA to the image at build time and preserve strict browser validation.

# Replace <your-playwright-version> with the version installed by npm ci.
FROM mcr.microsoft.com/playwright:v<your-playwright-version>-noble
USER root
COPY certs/company-root-ca.crt /usr/local/share/ca-certificates/company-root-ca.crt
RUN update-ca-certificates
WORKDIR /work
COPY package.json package-lock.json ./
RUN npm ci
COPY playwright.config.ts ./
COPY tests ./tests
CMD ["npx", "playwright", "test", "tests/tls.spec.ts", "--project=strict-chromium"]

Build and run from the project root. Use the same image tag for the runner and installed package; a mismatch can produce browser executable errors unrelated to TLS. The following is a verification command, with the placeholder replaced by your installed version when you build the image:

npm ls @playwright/test
# Edit the FROM tag to match that installed version.
docker build -t playwright-ca-check .
docker run --rm -e TARGET_URL=https://staging.example.test/ playwright-ca-check

For hosted CI without Docker, install the approved CA in the job before running npx playwright test. An Ubuntu GitHub Actions step can execute sudo install -m 0644 certs/company-root-ca.crt /usr/local/share/ca-certificates/company-root-ca.crt followed by sudo update-ca-certificates. Then run the strict project with TARGET_URL set to the staging endpoint. If the job uses a proxy, make sure the CA is available to the browser process launched inside that job, not only to the shell that downloaded dependencies.

Prefer an image layer or managed runner configuration over a test hook that mutates trust during each test. It makes the certificate policy reproducible and keeps parallel workers consistent. Review Docker for Playwright for the broader browser image setup.

5. Configure API Requests Separately From Browser Pages

page.goto() and Playwright's API request client can expose similar certificate failures, but they are separate paths. A browser context's ignoreHTTPSErrors option affects pages created in that context. A standalone API request context created with request.newContext() has its own ignoreHTTPSErrors option. A test that uses the built-in request fixture should be checked against its project use settings, but an explicitly created context should be configured at creation.

Use the following isolated test only for a controlled local API endpoint with an intentionally untrusted certificate. Set API_URL to a real HTTPS endpoint that returns success. The test disposes the context when finished.

// tests/api-tls.spec.ts
import { test, expect, request } from '@playwright/test';

const apiURL = process.env.API_URL;
if (!apiURL) throw new Error('Set API_URL to your HTTPS API URL');

test('calls a local API with a temporary certificate', async () => {
  const api = await request.newContext({ ignoreHTTPSErrors: true });
  try {
    const response = await api.get(apiURL);
    expect(response.ok()).toBe(true);
  } finally {
    await api.dispose();
  }
});

Verify with API_URL=https://localhost:8443/health npx playwright test tests/api-tls.spec.ts --project=local-https. For a staging or production API, remove the bypass and install the CA instead. You can also set ignoreHTTPSErrors on an individual api.get(url, { ignoreHTTPSErrors: true }) call, but that spreads exceptions across tests and makes it harder to audit certificate policy. Playwright APIRequestContext explains the request client's lifecycle and cookie behavior.

Do not confuse server CA trust with mutual TLS. clientCertificates supplies a certificate from the client when a server requests client authentication. It does not make the client trust the server's certificate. If your API requires both, configure the client certificate and fix server trust independently. A failed API response assertion after TLS succeeds is not evidence that the certificate option was ignored.

6. Fix the HTTPS webServer Readiness Probe

Playwright Test can start a local app with webServer and poll a URL before running tests. If the URL is HTTPS with a temporary local certificate, this poll can fail even when use.ignoreHTTPSErrors would allow pages to navigate. The webServer object has its own ignoreHTTPSErrors setting because it checks readiness outside the browser page context.

For an existing local server command, update only the readiness configuration. This example assumes npm run dev:https starts a server on port 8443 and responds at /health; use the actual command and health URL from your project.

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  webServer: {
    command: 'npm run dev:https',
    url: 'https://localhost:8443/health',
    ignoreHTTPSErrors: true,
    reuseExistingServer: !process.env.CI,
  },
  use: {
    baseURL: 'https://localhost:8443',
    ignoreHTTPSErrors: true,
  },
});

Verify the server's health URL directly, then run a test with the configured server. For example, curl -k -f https://localhost:8443/health checks that the endpoint responds, and TARGET_URL=https://localhost:8443/ npx playwright test tests/tls.spec.ts checks the page path. curl -k is only a local probe; remove -k when validating a properly trusted staging certificate. Playwright webServer configuration covers readiness URLs and process lifecycle.

If the local server has an ordinary HTTP health endpoint, prefer that for readiness and keep the HTTPS page navigation test strict once the local CA is trusted. Avoid changing webServer when the first failing call is page.goto(); those are different operations and require different evidence.

How to Verify the Fix

Run a strict check from the same environment that previously failed. A local laptop pass does not verify a Docker image or CI worker. Use the project's strict Chromium configuration and the failing URL, then repeat for each browser project you actually support. Preserve the initial error log so you can compare the operation and hostname before and after the change.

TARGET_URL=https://staging.example.test/ npx playwright test tests/tls.spec.ts --project=strict-chromium --reporter=line

A complete verification has three parts. First, the certificate inspection reports a trusted chain for the intended host. Second, the Playwright test reaches an HTTP response and passes its status and URL assertions. Third, a negative control shows that your certificate bypass is not active in the strict project. You can use a disposable self-signed local server for that control; do not direct it at an external service you do not operate.

If the site depends on secondary HTTPS origins, observe browser request failures too. The initial navigation can pass while a script, iframe, or API call from another origin fails. Add a temporary listener to a focused test and inspect request.failure()?.errorText for the failed URL:

// Add inside a test before page.goto(targetURL).
page.on('requestfailed', request => {
  console.log(request.url(), request.failure()?.errorText);
});

A failed subresource may have a different CA chain or proxy route. Remove noisy diagnostic logging after identifying it, then add a targeted assertion for the critical resource if the application depends on it. The Playwright network traffic guide gives additional ways to inspect page requests.

Prevent It From Coming Back

Keep certificate ownership explicit. The application or platform team should renew the leaf and intermediate chain, and the test infrastructure should install only approved trust roots. Track which environments use local development CAs, private staging CAs, and public CAs. When the CA rotates, update runners and containers before switching the server certificate, then run the strict smoke test in both old and new images during the transition.

Separate Playwright projects by environment so a local bypass cannot follow a test into staging. Review changes to ignoreHTTPSErrors, webServer.ignoreHTTPSErrors, and request context creation as security-sensitive configuration changes. A code search such as rg 'ignoreHTTPSErrors|NODE_TLS_REJECT_UNAUTHORIZED|--ignore-certificate-errors' . helps find accidental global bypasses. Do not use NODE_TLS_REJECT_UNAUTHORIZED=0 as a blanket workaround; it disables Node TLS verification for the process and does not establish trust for a browser page.

Put a small HTTPS smoke test early in CI. It should navigate one stable page through the same network path as the full suite and fail with a clear endpoint if trust breaks. Avoid letting retries mask the certificate problem: repeating a handshake with the same missing CA cannot fix it. Pin the container image tag to the package version your lockfile installs and rebuild the image when your approved CA bundle changes. For broader CI design, see add CI to a test framework.

Interview Questions and Answers

Q: What does net::ERR_CERT_AUTHORITY_INVALID tell you? It says the browser could not establish a trusted certificate chain for the HTTPS endpoint. I would inspect the issuer, chain, hostname, and the runner's trust store before touching test assertions.

Q: When is ignoreHTTPSErrors acceptable? I use it for a disposable local endpoint or a narrowly scoped test project when trust setup is temporarily out of scope. I do not enable it for production checks because it hides a real certificate failure.

Q: Why might Playwright pass locally and fail in Docker? The container has its own CA store and may not inherit roots installed on the host. I would add the approved CA to the image, rebuild, and run a strict browser test inside that image.

Q: Does NODE_EXTRA_CA_CERTS solve page navigation errors? It adds roots for Node TLS operations, such as a browser download behind a corporate proxy. I would still verify the browser's own trust behavior with a strict page.goto() test.

Q: Why can webServer fail before any tests run? Its readiness probe is a separate HTTPS client. For a local self-signed server, I can set webServer.ignoreHTTPSErrors or use a trusted health endpoint, then verify page navigation independently.

Q: How do you distinguish a bad chain from a bad locator? A certificate failure occurs before an HTTP response or DOM interaction. I inspect the failing URL and TLS chain; a locator failure instead reports an assertion or wait against a loaded page.

The structured interview answers below add examples about redirects, API requests, and mutual TLS that you can use in a Playwright interview practice session.

Common Mistakes

• Setting use.ignoreHTTPSErrors globally and treating a passing test as proof that the server certificate is valid. Run a strict project to verify actual trust.
• Installing a leaf certificate as a root CA. Trust the approved CA certificate and have the server serve its proper intermediate chain.
• Copying a laptop CA bundle into CI without checking its provenance or rotation process. Use the CA distributed by your organization.
• Fixing page.goto() settings when the failure is in request.get() or webServer.url. Read the first failing operation in the log.
• Assuming NODE_EXTRA_CA_CERTS changes browser trust. It configures Node's TLS roots for the process using it.
• Forgetting redirects and secondary origins. Inspect the final URL and any failed requests, not just the starting address.
• Pinning a Playwright Docker tag that differs from the installed package. Match the image tag to the lockfile's Playwright version.
• Using curl -k as the final validation. That flag skips verification; use a strict curl or OpenSSL check and a strict Playwright run.

Conclusion

The reliable fix for Playwright's certificate authority error starts with the failing operation and hostname. A scoped ignoreHTTPSErrors option can unblock controlled local HTTPS, while staging and CI should trust the approved CA and receive a complete server chain. Run the strict browser test from the same runner that failed, then keep a focused HTTPS smoke check in CI so a CA rotation or image change is caught early.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• How to Fix Playwright "Element is not attached to the DOM"
• How to Fix Playwright locator resolved to hidden element
• How to Fix Playwright waiting for element to be visible enabled and stable
• How to Fix "Cannot find module '@playwright/test'" in Playwright
• How to Fix "Cypress failed to start" and cypress verify Errors
• How to Fix "Playwright Test did not expect test() to be called here"