PKCS#11 Certificate Authentication for Prisma Agent on Linux
Learn how Prisma Agent on Linux uses PKCS#11 to authenticate with hardware-backed
certificates stored in a TPM 2.0 chip.
| Where Can I Use This? | What Do I Need? |
|
|
- Minimum Prisma Agent version 26.4
- Linux endpoint with a TPM 2.0 chip and
tpm2-pkcs11 installed
- Client Certificate authentication configured in Cloud Identity
Engine
|
Enterprise and regulated organizations require Linux endpoints to use hardware-bound
private keys. These keys must be non-exportable and cryptographically tied to the device
so they can't be copied or extracted. Storing private keys as files on disk doesn't
satisfy this requirement. Prisma® Agent on Linux uses the standard PKCS#11 interface to
read client certificates and perform authentication signing operations directly inside
the TPM 2.0 chip, keeping private keys hardware-locked at all times.
When certificate authentication is configured on your deployment, the agent automatically
detects the TPM 2.0 PKCS#11 module on a Linux endpoint. The agent checks the TPM for a valid client certificate before consulting
file-based certificate stores. If a matching TPM certificate is found, it is used for
authentication. If no TPM certificate matches the configured criteria, the agent falls
back to file-based certificates. If certificate authentication fails entirely and a
fallback method is configured, the agent falls back to SAML.
The agent applies the same certificate filtering rules to TPM certificates as to
file-based certificates: the certificate must be currently valid, must match the
Extended Key Usage (EKU) OID (defaulting to client authentication, OID
1.3.6.1.5.5.7.3.2), and must match any issuer or subject criteria you configure through
certificate selection settings. When the agent
finds a matching certificate, it prompts the user to enter their hardware PIN, if applicable, to unlock
the private key. Signing operations happen inside the TPM. No key material leaves the
hardware. The PIN is cached for the duration of the session.
On deployments where GlobalProtect also uses certificate authentication on a shared
gateway, the agent reuses an active PIN session rather than prompting users again,
avoiding redundant authentication prompts.