Every "make Zscaler work with X" task starts the same way: you need the root CA certificate as a file, in PEM form, before you can add it to anything. This note is only about obtaining that file and confirming it is the right one. What you do with it afterwards is per-platform.

The file is commonly named ZscalerRootCertificate-2048-SHA256.crt, but the name means nothing on its own. Two things actually matter: which CA is signing your intercepted traffic, and whether the file is PEM or DER.

First, work out which certificate you need

This is the step people skip, and it is the reason a correctly-installed certificate sometimes changes nothing.

Zscaler SSL/TLS Inspection can sign intercepted traffic with either of two things:

  • Zscaler's own root CA, the default. This is the ZscalerRootCertificate-2048-SHA256 case.
  • A custom intermediate CA that your organization generated and signed with its own internal PKI. Plenty of enterprises do this so that inspection chains up to a CA their machines already trust.

If your org uses a custom intermediate, the Zscaler public root is the wrong file and trusting it accomplishes nothing. You need your organization's root (and often the intermediate as well).

Find out which one you are dealing with by looking at who signed a certificate you were just served. Run this from anywhere behind the proxy:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject

The issuer is what is signing on Zscaler's behalf. If it names Zscaler, you want the Zscaler root. If it names your company, you want your company's root. To see the whole chain the proxy presents:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Note that the root itself is normally not in the chain (servers send the leaf and intermediates, not the root), so this tells you which root to go get. It does not hand you the root. Getting it is the rest of this note.

Route 1: ask your administrator

The dull answer and usually the fastest. Zscaler's documentation explicitly frames it this way: end users should get the root CA from their administrator, and administrators are expected to distribute it. If your org uses a custom intermediate CA, this is the only reliable route, because that certificate exists nowhere public.

Ask for it in PEM, and ask for the intermediate too if there is one.

Route 2: download it from the ZIA Admin Console

An administrator can pull the certificate from the Admin Console, from the SSL/TLS inspection configuration where the signing CA is chosen. Zscaler documents this under Choosing the CA Certificate for SSL/TLS Inspection. The exact menu path shifts between console versions, so navigate by that setting rather than by a memorized path.

For large fleets Zscaler's guidance is to push the certificate with an MDM solution rather than have people install it by hand. If you are writing a runbook for more than a handful of machines, that is the right shape.

Route 3: export it from the Windows trust store

If Zscaler Client Connector is installed, the certificate is already on the machine, in Trusted Root Certification Authorities. This route works even when you cannot reach an admin, and it is the one to use when you need the cert right now on a dev box.

GUI

  1. Run certmgr.msc
  2. Open Trusted Root Certification Authorities → Certificates
  3. Find the Zscaler entry (it may be named "Zscaler Root CA", "Zscaler Intermediate Root CA", or your organization's CA name)
  4. Right-click → All Tasks → Export
  5. Choose Base-64 encoded X.509 (.CER), which is PEM
  6. Save it as zscaler.crt

Picking Base-64 here is what makes this route produce PEM directly, so it needs no conversion.

PowerShell

Exports whatever Zscaler certificates are present, usually a root and an intermediate:

Get-ChildItem Cert:\LocalMachine\Root |
  Where-Object { $_.Subject -like "*Zscaler*" } |
  ForEach-Object { Export-Certificate -Cert $_ -FilePath "$env:USERPROFILE\zscaler-$($_.Thumbprint).cer" }

The $($_.Thumbprint) in the filename is deliberate. If Where-Object matches both the root and the intermediate, a fixed filename would leave you with only whichever got written last; the thumbprint keeps them distinct.

For a custom organizational CA, swap the filter (-like "*YourCompany*"), or drop the filter and list everything to find it:

Get-ChildItem Cert:\LocalMachine\Root | Select-Object Subject, Thumbprint, NotAfter

Export-Certificate writes DER, not PEM, so this route needs the conversion below.

Convert DER to PEM

Export-Certificate and most "export" buttons produce DER, which is binary. Nearly everything you will feed the certificate to wants PEM, which is text.

In PowerShell, using the built-in certutil, so there is no need for OpenSSL or to switch shells:

certutil -encode .\zscaler-<thumbprint>.cer zscaler.crt

Or with OpenSSL anywhere:

openssl x509 -inform der -in zscaler.cer -out zscaler.crt

Convert each certificate separately if you exported more than one.

Confirm you have the right file

Two checks, both worth running before you install anything. First, that it is genuinely PEM: the file must begin with the BEGIN line.

head -1 zscaler.crt        # -----BEGIN CERTIFICATE-----

A .crt or .cer extension says nothing about encoding, so do not infer PEM from the filename. This matters more than it sounds: some trust stores will accept a DER file with a PEM-ish name and quietly break, rather than reject it.

Second, that it is the certificate you think it is, and that it is a CA and still valid:

openssl x509 -in zscaler.crt -noout -subject -issuer -enddate -ext basicConstraints

What to look for:

  • subject matches the issuer you saw from s_client earlier. This is the check that catches the wrong-CA mistake.
  • A root has subject equal to issuer (self-signed). If they differ, you have an intermediate, and you will usually want both it and the root above it.
  • basicConstraints shows CA:TRUE. A leaf certificate is not a trust anchor and installing one does nothing useful.
  • enddate is in the future. Expired anchors fail in confusing ways.

If openssl x509 refuses to parse the file at all, it is still DER; go back and convert it.

Where to go next

The file is platform-agnostic; installing it is not.

Keep the PEM somewhere durable. You will need it again on every new VM, container image and WSL distro, and re-exporting it from scratch each time gets old quickly.