Skip to main content
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:
The most common errors are: 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 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.
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.