Certificates in an Enterprise Playwright Framework: SSL, TLS, CA, mTLS, Corporate Proxy, JFrog and Playwright

Introduction

When you work on a personal Playwright project, getting started may be as simple as running an install followed by the test command.

In a large enterprise environment, however, you may immediately encounter errors such as SELF_SIGNED_CERT_IN_CHAIN, UNABLE_TO_VERIFY_LEAF_SIGNATURE, unable to get local issuer certificate, CERT_HAS_EXPIRED, or unable to verify the first certificate. Your browser may simply display “Your connection is not private”.

You may also see files and configuration such as:

At first all of this can look like one big certificate problem. It is much easier once you understand that several different systems are involved, and each layer may have its own trust requirements.

This tutorial explains how certificates fit into that enterprise architecture.

What Is a Digital Certificate?

A digital certificate is an electronic credential used to prove the identity of a server, client, user, device, or service. A certificate normally contains a subject, an issuer, a public key, a serial number, validity dates, the domain or hostname it covers, a signature, and a set of extensions.

When your browser connects to https://qa.company.com, the server presents its certificate and the client decides whether that certificate should be trusted.

Why Do Companies Need Certificates?

Certificates provide four security properties at once: identity, encryption, trust and integrity. Without TLS protection, anyone on the network could potentially intercept traffic between Playwright and the application under test.

• Passwords and credentials stay protected in transit.
• Access tokens, cookies and session IDs cannot be read off the wire.
• Customer data and API payloads remain confidential.
• The client can verify it really is connected to api.company.com and not an impersonating server.

HTTP vs HTTPS, SSL vs TLS

Without TLS, traffic between client and server travels in plain text. With TLS, the same HTTP traffic is carried inside an encrypted connection — that is what the S in HTTPS means.

People still say “SSL certificate” even though modern HTTPS uses TLS. SSL 2.0 and 3.0 are obsolete; TLS 1.2 and TLS 1.3 are what you actually negotiate today. When an engineer says SSL certificate, they almost always mean a certificate used for TLS/HTTPS.

The Most Important Concept: Certificate Authority

A Certificate Authority (CA) is an organisation or internal service trusted to issue certificates. Your operating system already trusts a set of public CAs, which is why most internet sites simply work.

Enterprises usually also run their own internal Certificate Authority. A personal or freshly imaged machine may not automatically trust that company CA — and that is where most enterprise certificate problems begin.

Who Creates Enterprise Certificates?

Certificates are normally not created by Playwright developers. Depending on the organisation they are managed by the security team, PKI team, infrastructure or cloud platform team, DevOps, or a dedicated certificate management function.

PKI stands for Public Key Infrastructure. A PKI team typically manages root and intermediate CAs, certificate issuance, renewal and revocation, private keys, machine certificates and mTLS certificates.

Public CA vs Private Enterprise CA

For a public site such as https://www.example.com the certificate was issued by a CA your operating system already trusts, so usually nothing special is required.

For an internal host such as https://qa.internal.company.com the certificate may have been issued by the Company Root CA. Your browser or Node.js may not know that CA, and you will see “unable to get local issuer certificate”. The solution is to make the relevant system trust the company’s CA certificate — not to disable validation.

The Certificate Chain

Certificates are validated through a chain of trust.

The client verifies each link in turn:

If part of this chain is missing you get UNABLE_TO_VERIFY_LEAF_SIGNATURE or unable to verify the first certificate.

Root, Intermediate and Server Certificates

A root certificate sits at the top of the trust hierarchy, for example CompanyRootCA.pem. Organisations rarely use the root private key directly; instead the root signs intermediate CAs, and those intermediates sign the day-to-day server certificates. That reduces risk, which is why certificate bundles usually contain both a root and one or more intermediates.

A server certificate proves the identity of a server. For normal HTTPS only the server authenticates itself: Playwright connects, the server presents qa.company.com.crt, and the client validates it.

Client Certificates and mTLS

Sometimes the server also wants the client to prove its identity. The client presents its own certificate — identifying an automation service, application, machine or environment — and that leads to mutual TLS.

mTLS is common in banking, payments, healthcare, insurance, government, financial trading, internal microservices and B2B APIs. Instead of relying only on a username and password or a bearer token, the infrastructure additionally requires a trusted client certificate.

Even if someone knows the API URL, the server rejects requests unless a trusted client certificate is presented.

Common Certificate File Types

When you join an enterprise Playwright project you will meet .pem, .crt, .cer, .key, .p12 and .pfx. They are related but not identical, and the extension alone does not always tell you the encoding or the content.

PEM (Privacy Enhanced Mail) is a text encoding. A PEM file can hold a single certificate, a full chain, a private key, or several of those together:

• .pem — certificate, key, or certificate chain in PEM text format.
• .crt — a certificate, usually PEM encoded, sometimes binary (for example company-root-ca.crt).
• .cer — another certificate extension, common on Windows, encoded as PEM or DER depending on export.
• .key — a private key, for example client.key. Extremely sensitive.
• .p12 / .pfx — PKCS#12 bundles containing the client certificate, its private key and the chain, often protected by a passphrase.

A PKCS#12 bundle is convenient: instead of shipping client.pem plus client.key you distribute a single client.p12 file.

Certificates Affect Different Parts of a Playwright Framework

This distinction is the single most useful thing in this tutorial. Certificate requirements can apply to the browser, Playwright’s APIRequestContext, Node.js itself, npm, JFrog Artifactory, Git, the corporate proxy, CI/CD, Docker and the internal APIs — and these systems do not necessarily share the same trust configuration.

A certificate trusted by your operating system browser does not automatically fix every Node.js request. Making Node trust a CA does not automatically fix a browser context configuration problem either. Always ask: which component is actually failing?

ignoreHTTPSErrors: Use It Deliberately

If a test navigates to an internal host and the browser reports a certificate problem, first ask whether the certificate is expected to be trusted, or whether the environment intentionally uses a self-signed development certificate. That difference decides the fix.

Client Certificates in Playwright

Modern Playwright supports TLS client certificate authentication for browser contexts and API requests. You configure either a cert plus key pair or a PFX/PKCS#12 bundle, and each entry is associated with an exact origin.

If your company hands you a PKCS#12 bundle instead, configure the pfx and its passphrase:

Enterprise Certificate Structure in the Repository

Keep a certs directory in the repository for documentation, but provision the actual private material externally.

CI retrieves the real certificates from a secret manager rather than storing them in Git.

Corporate Proxy and HTTPS Inspection

Many large companies do not allow developer machines to reach the internet directly. Traffic goes through a corporate proxy so the organisation can enforce security policy, filtering, monitoring, access control, malware scanning and compliance.

To inspect encrypted connections, an authorised enterprise proxy establishes separate TLS connections on each side. Your machine therefore sees a certificate issued by something like “Company Security CA” rather than the site’s original public chain. Unless your corporate CA is installed and configured, Node.js reports SELF_SIGNED_CERT_IN_CHAIN even though the proxy is working exactly as designed.

Why Does the Browser Work but npm Fails?

You open https://company.jfrog.io in Chrome and it works. You run npm install and get SELF_SIGNED_CERT_IN_CHAIN. The reason is simple: Chrome and Node.js/npm use different trust configuration. The browser trusts the corporate certificate through the operating system store; Node does not read that store the same way.

NODE_EXTRA_CA_CERTS

Node.js supports NODE_EXTRA_CA_CERTS to extend its trusted CA set with certificates from a PEM file. The value is read when the Node process starts.

Set it before the process launches rather than inside your code. Node documents that NODE_EXTRA_CA_CERTS is read at process start, so assigning process.env.NODE_EXTRA_CA_CERTS afterwards does not change the running instance’s CA configuration.

npm Certificate Configuration and .npmrc

npm has its own certificate configuration. The cafile setting points to a file containing one or more trusted Certificate Authority certificates.

npm also supports registry-scoped authentication settings such as tokens, client certificate files and key files. On Windows the cafile path simply uses the Windows path form, for example C:\certs\company-ca.pem.

What Is JFrog Artifactory and Why Do Companies Use It?

JFrog Artifactory is an artifact repository manager — a controlled enterprise storage and distribution system for software packages and build artifacts. Instead of every developer downloading directly from the public npm registry, the organisation routes package management through Artifactory.

Companies use Artifactory for security, centralised dependency management, access control, private packages, caching, availability, auditability, artifact governance and supply-chain control. Internal packages such as @company/test-utils, @company/api-client, @company/playwright-fixtures and @company/reporting live there rather than on the public registry.

Repository types

• Local repository (npm-local) — stores the company’s own packages, for example @company/playwright-framework.
• Remote repository (npm-remote) — proxies and caches an external registry such as registry.npmjs.org.
• Virtual repository (npm-virtual) — aggregates local and remote repositories behind one URL. JFrog recommends this as the default registry.

Authentication is provided through npm login or a token in .npmrc. Note that JFrog is an artifact repository platform, not a certificate mechanism — but because npm reaches it over HTTPS through the corporate proxy, JFrog setup is where certificate problems usually surface first.

How to Diagnose Certificate Problems

You clone the automation repository, run npm install, and it fails with SELF_SIGNED_CERT_IN_CHAIN. It is tempting to think Playwright is broken — but Playwright has not even started. The failure happened during dependency installation, a completely different layer from page.goto() inside a test.

npm install fails

Check NODE_EXTRA_CA_CERTS and the npm cafile setting. Do not touch Playwright configuration — Playwright is not involved yet.

Browser navigation fails

Walk the chain from the browser to the server certificate to the intermediate to the corporate CA, then decide whether to install the correct CA or — only for a deliberately insecure non-production environment — set ignoreHTTPSErrors.

mTLS API fails

A request to a secured endpoint returns 403 or the TLS handshake fails outright. The API probably requires a client certificate and private key, matched to the exact origin.

Environment-Specific Certificates and Secrets

An enterprise typically has separate DEV, QA, STAGE and PROD certificates. Rather than committing them per environment, resolve paths at runtime from environment variables.

This cleanly separates code from secrets.

Certificates in CI/CD and Docker

Your laptop may already trust the corporate CA, but a Jenkins agent, GitHub Actions runner or Docker container may not. That is why a suite passes locally and fails in the pipeline with a certificate error.

• Different operating system trust store on the agent.
• Certificate missing inside the container image.
• NODE_EXTRA_CA_CERTS not set in the job environment.
• Secret not injected, or client certificate / private key missing.
• Wrong file permissions on the key.
• Different JFrog configuration, or an expired certificate.

The certificates exist only for the duration of the job; once the workspace is destroyed they are gone. For containers, remember that your laptop trust store and the Docker trust store are two different things — the enterprise-approved CA must be installed or supplied inside the image.

Security: What Never Goes into Git

Never commit client.key, automation.p12 or automation.pfx. Anything containing a BEGIN PRIVATE KEY block is highly sensitive: do not email it casually, paste it in Slack, print it to the console, attach it to an Allure report, or write it into test logs.

• Store private keys in CI secrets, Vault, AWS Secrets Manager, Azure Key Vault, Kubernetes Secrets or an enterprise certificate service.
• A public .crt such as company-root-ca.crt is usually not secret, but company policy may still restrict where internal infrastructure material can be stored — follow your PKI/security policy.
• Certificate passphrases are secrets too: read them from process.env.CLIENT_CERT_PASSWORD, never from a literal in the config.

Certificate Expiration and Ownership

Certificates have validity periods. Once the end date passes you get CERT_HAS_EXPIRED and automation starts failing even though no Playwright code changed. That is why ownership and renewal processes matter.

Renewal usually belongs to the PKI, security, platform or DevOps team, or the application owner. The SDET’s job is to detect the issue, collect evidence, identify the certificate and the affected environment, and contact the certificate owner — not to create a random replacement certificate.

Common Certificate Errors and What They Mean

• SELF_SIGNED_CERT_IN_CHAIN — the chain contains a CA that Node/npm does not trust. Typical with a corporate proxy, internal CA or internal JFrog.
• UNABLE_TO_VERIFY_LEAF_SIGNATURE — usually a missing intermediate certificate or an incomplete chain.
• unable to get local issuer certificate — the client cannot find a trusted issuer for the presented certificate.
• CERT_HAS_EXPIRED — the validity period simply ended.
• Hostname mismatch — the certificate covers api.company.com but you connected to api-qa.company.internal.

What should an SDET check first?

1. Where exactly is it failing?
2. What URL is involved?
3. Is this npm, the browser, an API call, JFrog or CI?
4. Who issued the certificate?
5. Is the certificate expired?
6. Does the hostname match?
7. Is the CA trusted by that component?
8. Is an intermediate certificate missing?
9. Is a corporate proxy involved?
10. Is mTLS required?

What NOT to Do

Avoid reaching for these as reflex fixes whenever an install or test hits a certificate problem:

All three weaken certificate verification instead of solving the underlying trust issue. Use the systematic path instead: identify the failing component, inspect the server or registry, identify the certificate chain and issuing CA, verify trust, expiration, hostname and proxy, verify the client certificate if mTLS is in play, and fix the correct layer.

Certificates vs Tokens vs SSH Keys

Do not confuse a TLS certificate with an OAuth token, a JWT, an API key or a session cookie. They operate at different levels and a single request often needs both.

The certificate answers “is this a trusted client or system?”. The token answers “which user or service is this, and what are they allowed to do?”. SSH keys (id_rsa, id_ed25519) used for Git authentication are different again — same public/private key mathematics, entirely different mechanism from HTTPS TLS certificates.

Joining an Enterprise Playwright Project

Search the repository for these terms to map the trust architecture quickly:

• Files worth inspecting: README.md, package.json, playwright.config.ts, .env.example, .npmrc, Dockerfile, Jenkinsfile, .github/workflows/, certificate config utilities and CI scripts.
• Questions to ask the team: Do we use an internal CA? Is a corporate proxy involved? Is JFrog our npm registry? Does npm require NODE_EXTRA_CA_CERTS? Does the application use mTLS, and which APIs require client certificates? Who owns certificate renewal? How are certificates injected in CI? Where are private keys stored? Do environments use different certificates?

Reference Structure and Certificate Configuration

Enterprise Certificate Checklist

The Most Important Mental Model

When somebody says “Playwright has a certificate problem”, do not assume Playwright itself is at fault. Walk the whole chain and ask which connection is actually failing.

A complete enterprise run touches Git, npm and .npmrc, the corporate CA, JFrog Artifactory, dependency installation, Playwright startup, authentication, the browser and API clients, TLS or mTLS, the enterprise application, its microservices, the database or messaging layer, and finally validation. Understanding certificates means understanding where trust is required across that entire flow.

Final Takeaway

Enterprise Playwright automation is rarely just Playwright talking to a website. The real architecture runs from the developer or CI machine, through the corporate CA and JFrog, into Playwright’s browser and API clients, and out over TLS or mTLS to an API gateway and its microservices.

The concepts worth knowing cold are TLS/HTTPS, root and intermediate CAs, server and client certificates, private keys, mTLS, the PEM/CRT/CER and P12/PFX formats, corporate proxies, NODE_EXTRA_CA_CERTS, the npm cafile setting, JFrog Artifactory, and CI certificate management.

Once you internalise that principle, certificate errors stop looking like mysterious Playwright failures and become ordinary infrastructure problems you can diagnose systematically.