What is an intermediate CA certificate?
An intermediate CA certificate is the certificate of an intermediate certificate authority that issues certificates on behalf of a root CA. In Zscaler operations, it is the trust anchor for SSL/TLS inspection: for every inspected connection, Zscaler dynamically issues the client an inspection certificate signed by this intermediate CA. When end devices trust the intermediate CA, inspected connections run without warnings; when that trust is missing, or the certificate expires, certificate warnings pile up. The multi-level chain also protects the highly sensitive root CA, which as a result never has to sign directly in day-to-day operations.
Intermediate CA certificate in detail
Zscaler manages certificates on their own page in the admin interface. That is where you find either the default certificate Zscaler provides, or a custom intermediate CA belonging to the organisation, for example from its own PKI via a signed certificate request. Each certificate records details such as the validity start date, expiry date, key type and a fallback certificate; for protection types, the documentation distinguishes Software Protection from Cloud HSM Protection, where the private key sits in a hardware security module.
For the chain to hold, the certificate must be installed as trusted on every end device, usually distributed through device management or group policy. Applications with certificate pinning are the exception: they will not accept even a trusted intermediate CA, and need an inspection exception instead.
Why the intermediate CA certificate matters in Zscaler operations
Hardly any single object in the tenant has this much reach. If the certificate expires, the dynamically issued inspection certificates lose their valid signature, and every inspected connection is affected at once: certificate warnings, applications dropping out, a helpdesk under full load. Unlike a single faulty rule, this is never a small incident, it is a wide one from the start.
That is why the expiry date belongs in active monitoring with enough lead time: renewal or reissue, distributing trust to end devices, and testing with a pilot group all take time. Individual cases deserve attention too: if a single device shows warnings for inspected connections, that device is usually just missing trust in its certificate store, a classic finding on new or incompletely managed devices.
Common sources of error
- Expiry date without active monitoring: renewal only gets noticed once the first warnings start coming in.
- Trust distributed incompletely: certain device groups, such as BYOD or freshly installed machines, do not have the certificate in their store.
- Certificate warnings dismissed as a user problem by default: behind “the browser is complaining” can be the trust anchor for the entire tenant.
- Mistaking pinning cases for trust problems: pinned apps are not fixed by distributing the trust store, they need a documented exception.
Intermediate CA in practice: what CentaurNexus contributes
In CentaurNexus, Cert Horizon monitors when the ZIA intermediate CA expires and turns a quiet date into a visible operational state: the cockpit shows when the certificate runs out, giving you the lead time that renewal, distribution and testing genuinely need. If a single user reports certificate warnings, 360-degree user search supplies the context for it, without the helpdesk needing Zscaler admin rights. That keeps the difference between an isolated case and a wide-reaching risk visible at all times. How users can work out connection and certificate messages for themselves is shown in the article Zscaler self-service right in the browser.
Related terms
Frequently asked questions about the intermediate CA certificate
For every inspected connection, Zscaler dynamically issues the client a certificate signed by the intermediate CA. When end devices trust that intermediate CA, browsers and applications accept the inspected connections without warnings. The certificate is therefore the trust anchor for all decryption in the tenant.
By default, an intermediate certificate provided by Zscaler signs the inspection certificates. Alternatively, the organisation integrates its own intermediate CA from its own PKI, for example by requesting a certificate from its internal certificate authority. The advantage: end devices often already trust that chain, and the organisation keeps control of the trust anchor.
Then the dynamically issued inspection certificates lose their valid signature, and certificate warnings and dropped connections threaten across every inspected connection at once. Because that hits many users at the same time, the expiry date belongs in active monitoring with lead time for renewal, distribution and testing, not in a calendar note.
The certificate must be stored as trusted in the certificate store on end devices, usually distributed through device management or group policy. Where that trust is missing on a device, browsers there show certificate warnings for inspected connections. Cases like that are a classic helpdesk finding on new or incompletely managed devices.
Zscaler’s documentation distinguishes Software Protection from Cloud HSM Protection for the intermediate CA’s keys. With Cloud HSM, the private key sits in a hardware security module. Each certificate records details such as the validity start date, expiry date, key type and a fallback certificate; the default certificate cannot be deleted.
- Zscaler Help Portal: About Intermediate CA Certificates - help.zscaler.com
- Zscaler Help Portal: Choosing the CA Certificate for SSL/TLS Inspection - help.zscaler.com
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.