Review PTC Prerequisites and Installation Script

Prerequisites

Before configuring PTC, ensure the following requirements are met.

Zscaler Requirements

ZIA Admin Portal Access: You need administrative access to the Zscaler Internet Access (ZIA) Admin Portal to create URL categories, SSL inspection rules, and URL filtering rules.

Zscaler Client Connector (ZCC): ZCC must be deployed on all developer workstations that will be part of the PTC solution. ZCC routes network traffic through Zscaler for inspection.

Z-Tunnel Mode and SSL Inspection (Zscaler): PTC depends on ZIA being able to SSL-inspect the HTTPS flows to the public registries you intercept so URL filtering can redirect those requests to Artifactory. Confirm tunnel mode, forwarding behavior, and SSL inspection eligibility with Zscaler. For example, see About Z-Tunnel 1.0 and Z-Tunnel 2.0. If SSL inspection cannot be applied to the relevant client traffic, the redirect flow will not work as intended.

CA Certificate: The Zscaler CA certificate is already distributed to the developer machine by ZCC. However, some package managers and applications still need the certificate in an application-specific trust store or PEM path. MDM is optional: use MDM (for example, Intune and Jamf), other deployment tooling, or controlled manual steps, especially for labs and pilots. At enterprise scale, automated distribution is strongly recommended. The certificate file must be copied to a location with user-level read access, not a root-only location (see Before Step 2: Verify trust stores for your package clients for details).

Workstation install scripts, environment variables, OS coverage, MDM notes, and “configure without the script” minimums are maintained in the repository README under scripts/ (see Installation Script).

For detailed instructions, see: Adding Custom Certificate to an Application-Specific Trust Store

Target Group (Scoped Deployments Only): If you plan to scope PTC to a specific group (for example, R&D), ensure the target group exists in Zscaler. Groups can be configured via:

• Directory Sync / SCIM: Synced from your identity provider
• Local: Created manually under Administration > User Management > Groups in the ZIA Admin Portal

JFrog Artifactory Requirements

Artifactory Instance: You need a running JFrog Artifactory deployment. PTC (Package Reroute) availability follows your JFrog license and entitlements, often aligned with Enterprise X or Enterprise+, but verify your exact SKU and feature flags with your JFrog account team rather than assuming from tier names alone.

Hostname and URL: Use the same HTTPS host your developers and automation use to reach Artifactory. For JFrog Cloud this is typically https://<your-subdomain>.jfrog.io (for example https://acme.jfrog.io). Self-hosted installations use the hostname (and optional context path) your organization configured. That value is what you substitute for <YOUR_ARTIFACTORY_URL> elsewhere in this guide.

Artifactory must have the appropriate repository layout for each package type you intend to serve through PTC, not only npm. The npm registry below is one example. Repeat the same pattern (correct Artifactory package type, upstream URL, Package Reroute repo_key, and matching ZIA URL category entries) for every ecosystem you enable (for example PyPI, Docker/OCI, and Hugging Face, per Supported Package Types (GA) and Package Reroute Config API).

A remote repository is required for PTC — it proxies the public registry upstream and is the target of the repo_key in the Package Reroute configuration. Virtual repositories are not supported as the PTC repo_key.

• Example — npm: A remote npm repository whose upstream is https://registry.npmjs.org.

Curation Best Practice: When you use JFrog Curation, enable Curation directly on the remote repository configured as repo_key.

JFrog Curation (Optional): Enabling Curation on the relevant remote repositories is not mandatory for PTC. The redirect, repository resolution, and caching flow works without Curation. If Curation is off, you do not get JFrog Catalog policy evaluation, Compliant Version Selection (CVS), or Curation audit entries for those downloads. Only standard Artifactory repository behavior applies. Turn on Curation when you want that governance layer.

Anonymous Access: Enable Allow Anonymous Access at the platform level, then grant the anonymous user Read and Deploy/Cache (per package type) on the remote repository configured as repo_key in Package Reroute, so anonymous users can fetch and cache from the upstream registry. Use a permission target scoped to that remote (for example npm-remote-registry), not broad anonymous access.

Checklist

• ZIA Admin Portal access confirmed
• ZCC deployed on target developer workstations, with tunnel mode and ZIA forwarding suitable for SSL inspection on the registry traffic you intercept (confirm with Zscaler—see About Z-Tunnel 1.0 and Z-Tunnel 2.0)
• Zscaler CA certificate and client trust configuration applied on target workstations (MDM optional)
• Target group defined in Zscaler (if using scoped deployment)
• JFrog Artifactory instance hostname known
• Repositories created for each package type you roll out (npm, PyPI, Docker, and Hugging Face)
• JFrog Curation enabled on remote repositories (optional—required only if you want Catalog policy checks and Curation audit for that path)
• Anonymous access configured on Artifactory

Installation Script

Important: This is not JFrog-specific. The certificate installation described in this section is a general requirement for Zscaler SSL inspection to work properly on any workstation. Any application or CLI tool that makes HTTPS calls through a Zscaler-inspected network must trust the Zscaler root CA certificate. This applies regardless of whether JFrog Artifactory or PTC is involved. For the authoritative reference on Zscaler SSL inspection certificate deployment, see Zscaler's official documentation: Adding Custom Certificate to an Application-Specific Trust Store.
PTC relies on workstation certificate installation you deploy with the approach that fits your organization (MDM is not required—endpoint management, imaging, scripts, or manual steps are all valid). The scripts extract or reference the Zscaler CA and set environment variables so Node.js (npm and related clients) and Python/pip trust TLS through SSL inspection, as an example.

Installation scripts may require customer-specific adjustments. Every organization's endpoint configuration, certificate chain, MDM tooling, and security policies differ. Review and adapt scripts to your environment before broad rollout.
This product documentation does not duplicate the script README. For authoritative detail, use:

• Repository root overview: README.md (links to the script guide)
• Scripts and full documentation: scripts/README.md in the package-reroute repository.

That README includes: supported OSes, package clients (npm, pnpm, yarn via Node; pip/pipenv/uv with validation notes), environment variables with version applicability, flowchart, test coverage, MDM validation on Action1 (other MDMs may need adjustment), which clients require env-based configuration (typically older npm/Python) vs. which may not need extra environment variables when the OS trust store is sufficient, and the minimum variables needed if you implement the same behavior without the scripts.

For example, you can validate the certificate path used by client tooling:

openssl x509 -in "<ZSCALER_CA_PATH>" -noout -issuer

Where:

• <ZSCALER_CA_PATH> is the full path to the Zscaler CA certificate file used by your package client.

For example:

openssl x509 -in "/opt/certs/zscaler.pem" -noout -issuer

At a Glance

Run the installation before ZIA rules that intercept registry traffic are activated (see Deployment Sequence).

Frequently Asked Questions

This section provides answers to frequently asked questions about PTC prerequisites and installation scripts.

Related Topics

• Package Traffic Controller (PTC) overview
• Deployment and Rollout
• Configure Artifactory for PTC