> ## Documentation Index
> Fetch the complete documentation index at: https://docs.browserbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Certificate Validation

> Handle TLS certificate errors in browser sessions

Browser sessions validate TLS certificates. When a host presents a certificate the browser does not trust, the request fails and your automation receives a Chromium certificate error:

```
page.goto: net::ERR_CERT_DATE_INVALID at https://example.com/
```

The most common errors are:

| Error                          | Meaning                                                                                           |
| ------------------------------ | ------------------------------------------------------------------------------------------------- |
| `ERR_CERT_AUTHORITY_INVALID`   | The browser does not trust the issuing certificate authority, such as a self-signed or private CA |
| `ERR_CERT_COMMON_NAME_INVALID` | The certificate does not cover the hostname you requested                                         |
| `ERR_CERT_DATE_INVALID`        | The certificate is expired or not yet valid                                                       |

Only top-level navigations raise an error your script can catch. A failing subresource, such as an analytics script on a page you are visiting, fails quietly unless you listen for the `requestfailed` event.

## Trusting a private certificate authority

If the certificate comes from an authority you control, such as a corporate egress proxy, an MITM appliance, or your own test CA, upload that CA to your project and reference it when creating a session. The browser trusts it like any public authority and validation stays on everywhere else.

See [Trusted CA certificates](/platform/identity/proxies#trusted-ca-certificates) for the upload and usage steps.

## Ignoring certificate errors

When the certificate belongs to a site you do not control, such as a target with an expired certificate that you still need to reach, set `ignoreCertificateErrors` to `true`. The session then accepts whatever certificate the host presents.

<Tabs>
  <Tab title="Node.js">
    <CodeGroup>
      ```typescript SDK theme={null}
      import Browserbase from "@browserbasehq/sdk";

      const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY! });

      async function createSession() {
        const session = await bb.sessions.create({
          browserSettings: {
            ignoreCertificateErrors: true,
          },
        });
        console.log(`Session URL: https://browserbase.com/sessions/${session.id}`);
        return session;
      }

      const session = createSession();
      ```
    </CodeGroup>
  </Tab>

  <Tab title="Python">
    <CodeGroup>
      ```python SDK theme={null}
      from browserbase import Browserbase
      import os

      bb = Browserbase(api_key=os.environ["BROWSERBASE_API_KEY"])

      def createSession():
          session = bb.sessions.create(
              browser_settings={
                  "ignoreCertificateErrors": True,
              },
          )
          print(f"Session URL: https://browserbase.com/sessions/{session.id}")
          return session

      session = createSession()
      ```
    </CodeGroup>
  </Tab>
</Tabs>

<Warning>
  `ignoreCertificateErrors` disables validation for the entire session, so an
  attacker can intercept or alter traffic without the browser detecting it.
  Upload a CA certificate instead when you control the issuer, and limit this
  setting to the sessions that need it.
</Warning>

## Choosing between the two

A CA upload only resolves `ERR_CERT_AUTHORITY_INVALID`, where the chain is valid but the browser does not know the issuer. Expired and hostname-mismatched certificates stay invalid no matter which authorities you trust, so those require `ignoreCertificateErrors`.

For a full list of session options and configuration fields, check out the [API reference for creating a session](/reference/api/create-a-session).