---
title: "Certificate validation"
description: "Handle TLS certificate errors in browser sessions"
image: "https://help.agent.mq/og.svg"
---

> Documentation Index
> Fetch the complete documentation index at: https://help.agent.mq/llms.txt
> Use this file to discover all available pages before exploring further.

# Certificate validation

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

### Node.js

```typescript SDK
  import Browsers from "@agentmq/browsers";

  const browsers = new Browsers({ apiKey: process.env.AGENTMQ_TOKEN! });

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

  const session = createSession();
```

### Python

```python SDK
  from agentmq.browsers import Browsers
  import os

  browsers = Browsers(api_key=os.environ["AGENTMQ_TOKEN"])

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

  session = createSession()
```

> **Caution**
>
> `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.

## 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](/browsers/api).

Source: https://help.agent.mq/browsers/security/certificate-validation/index.mdx