Skip to main content

MDM-delivered CA trust

By default, pavri-endpointd installs the CAP-2.4 egress-proxy CA into the OS trust store itself — LocalMachine\Root on Windows when running elevated, CurrentUser\Root as a fallback. This is the right choice for most fleets.

Some enterprise tenants want a different model: deliver the CA via MDM or configuration management, and have the agent verify presence rather than install it. This is useful when:

  • AppLocker or Windows Defender Application Control (WDAC) blocks third- party writes to the system trust store.
  • Defender Tamper Protection rejects per-user-root mutations.
  • The security team wants the cert lifecycle under MDM control rather than agent control.

How to enable​

  1. After pavri-endpointd has been installed and the egress proxy has been enabled on at least one endpoint, copy the generated CA PEM off that endpoint. The sensor runs as LocalSystem on Windows, so the PEM lives in the LocalSystem profile: C:\Windows\system32\config\systemprofile\.pavri\proxy\ca.pem. See the infra-side runbook at infra/mdm/intune/trust-profile/README.md for the recommended access mechanisms (PsExec, service stop, SYSTEM scheduled task).
  2. Run the profile-build script in the Pavri repo: infra/mdm/intune/trust-profile/build-ca-profile.sh --ca-pem ca.pem --out ./out.
  3. Upload out/pavri-ca-root.cer to Intune as a Trusted Certificate profile (Destination store: Computer certificate store - Root).
  4. Assign to the fleet group.
  5. On subsequent rollouts, pavri-endpointd will detect the cert is already present in LocalMachine\Root and skip its own install — no CertAddCertificateContextToStore call is made.
note

Step 5 requires pavri-endpointd ≥ CAP-3.7 Task 7 (agent-side MDM-presence detection). Earlier agent versions will still attempt their own trust-store write; the MDM-delivered cert is already present, so the agent's CERT_STORE_ADD_REPLACE_EXISTING write is a harmless no-op.

Full step-by-step (including both the Intune GUI flow and the Graph API two-call sequence) lives in the infra-side runbook at infra/mdm/intune/trust-profile/README.md.

Linux trust stores​

For Linux fleets, use the Ansible, Chef, or Puppet artifacts in infra/mdm/linux/ and pass the tenant-approved egress-proxy CA PEM through the artifact's CA variable:

  • Debian/Ubuntu: the CA is written to /usr/local/share/ca-certificates/pavri-egress-proxy.crt, then update-ca-certificates runs.
  • Fedora/RHEL family: the CA is written to /etc/pki/ca-trust/source/anchors/pavri-egress-proxy.crt, then update-ca-trust extract runs.

If the tenant does not distribute a shared managed CA, leave this field empty. The compensating control is process-scoped trust plus heartbeat posture for egress_proxy_trust_state; do not claim fleet-wide Linux system trust in that mode.

Caveat: ephemeral CA model​

The CAP-2.4 CA is currently per-endpoint ephemeral. The MDM path above works cleanly for tenants who are willing to lock the fleet to a single shared CA (extracted once from a canonical endpoint, deployed to all). A tenant-shared root CA with per-endpoint leaves is on the CAP-3.X follow-up roadmap and will eliminate this caveat.