Deploy certificates to Linux hosts from Google CA

[kc9wwh]

• Unpacked: TODO: Head of Product Design (HPD) checks this box when the request goes through "Unpacking the why": https://fleetdm.com/handbook/product-design#unpacking-the-why
• Gong snippet: https://us-65885.app.gong.io/call?id=3768846169144578334&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A1922%2C%22to%22%3A2083%7D%5D

Interpretation

How do you interpret the customer's words?

The customer needs to deploy mTLS certificates from Google CA (Google Cloud Certificate Authority Service) to Linux hosts. Arch Linux is the immediate target. They use a homegrown shell-based solution today because Fleet has no path that fits their CA. Google Chrome on these hosts presents the certificate for client-cert auth to internal applications. The same certs will cover network access (Wi-Fi, wired 802.1X, VPN) next.

They're flexible on protocol. An internal team has reopened ACME work, but they're keeping SCEP open too. Whichever Fleet ships first is fine. Linux is the priority because it's the harder problem in their environment.

What's Fleet missing?

Fleet supports certificate delivery on macOS, iOS, iPadOS, Android, and Windows (for device identity). On Linux, Fleet supports Hydrant and custom EST today, but neither covers this customer's stack:

1. No first-class Google CA integration. Customers using Google Cloud Certificate Authority Service have to front it with custom SCEP or custom EST, and neither matches how the customer wants to issue certs.
2. No ACME support. ACME sits on the TPM-identity roadmap but isn't available as a CA protocol for end-user or application certificates. The customer's internal team is pushing toward ACME, and Google CA supports it.
3. No Google-CA-aware certificate template flow for Linux. Even with EST available, fleetd on Linux lacks the templated subject, SAN, and trust-store delivery path macOS has via configuration profiles.

Fleet needs to add Google CA as a CA integration (or ACME as a generic protocol), and give fleetd on Linux the template-driven request, install, and renew loop macOS already has via MDM.

What does the customer's ideal workflow look like?

1. The admin connects Fleet to Google CA (or any ACME-reachable CA) the same way they connect DigiCert or Smallstep today.
2. The admin defines a certificate template covering subject, SAN, key usage, and target trust store, using Fleet variables ($FLEET_VAR_HOST_HARDWARE_SERIAL, $FLEET_VAR_HOST_END_USER_IDP_USERNAME, etc.) for per-host values.
3. The admin assigns the template to a Linux team or all Linux hosts.
4. fleetd on each host generates a key pair, builds a CSR from the template, requests a certificate from the configured CA, and installs it where the host needs it (system trust store for Chrome client auth, NetworkManager or wpa_supplicant for 802.1X).
5. Fleet shows issued date, expiration, CA, and renewal state per host in host details, alongside the existing certificate inventory.
6. Fleet renews certificates before expiration and surfaces failures with the retry behavior the macOS path uses today.