Deploy/delete certificates on Android hosts via UI/API

[noahtalerman]

Note: This story has expanded beyond its initial scope and is now primarily comprised of leftover work from previous Android stories. It can be split into multiple stories if needed.

Goal

User story
As an IT admin,
I want to deploy certificates from my certificate authority (CA) to Android hosts via UI/API and confirm that they're deployed by visiting the Host details page
so that I can connect my end users to the corporate Wi-Fi or VPN.

Roadmap item

📄 Deploy certificates for Wi-Fi and VPN on personal mobile devices (iOS/iPadOS, Android) and company-owned Windows, & Linux computers

Original requests

#13420

Resources

None.

Changes

Product

• UI changes: Figma link
• CLI (fleetctl) usage changes: No changes.
• YAML changes: No changes.
• REST API changes: [API] Deploy certificates on Android hosts via UI/API #36625
  • Add certificates array under host.mdm.os_settings. It should include operation_type
  • Example:

  •  "mdm": {
       "os_settings": {
         "certificates": [
           {     
             "name": "wifi-certificate",
             "status": "verified",
             "operation_type": "install",
             "detail": ""
           },
           {     
             "name": "vpn-certificate",
             "status": "pending",
             "operation_type": "remove",
             "detail": "<error from Fleet Android agent>"
           }
         ]  
       }
     }

• Fleet's agent (fleetd) changes: No changes.
• GitOps mode UI changes: See Figma link above.
• GitOps generation changes:
  • Make sure to export controls.android_settings.certificates as part of the gitops generate command
• Activity changes: [Activity changes] Deploy certificates on Android hosts via UI/API #35199
• Permissions changes: Already covered by "Edit/view OS settings" rows in permissions.
• Changes to paid features or tiers: Fleet Premium (adding certificate authority is required, which isa premium feature).
• My device and fleetdm.com/better changes: No changes.
• Usage statistics: No changes.
• Other reference documentation changes: No changes.
• First draft of test plan added
• Once shipped, the requester has been notified
• Once shipped, dogfooding issue has been filed. Dogfood: Deploy/delete certificates on Android hosts via UI/API #41143

Engineering

• Test plan is finalized
• Contributor API changes: Android app to communicate delete status
• Feature guide changes: #36699
  • Document that in order to install certificates, if the host is enrolled prior to 4.78, it must be re-enrolled
• Database schema migrations: Yes
• This is a premium only feature: Yes

ℹ️  Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

QA

Risk assessment

• Requires load testing: No (because we don't have the infrastructure)
• Risk level: Low (customer requires support for 1000 devices initially)

Test plan

Make sure to go through the list and consider all events that might be related to this story, so we catch edge cases earlier.

UPDATE: Since Dogfood has 4.79 RC, please do part of the QA on Dogfood. At the very least, try the happy path flow.

UI

• Make sure a new page for certificates is available in Fleet Premium at /controls/os-settings/certificates, and in Fleet Free, we show "Premium" message.
• Verify that the user can add a certificate by filling out the form in the Add certificate modal.
• Verify that the user sees a validation error on the name input field if using unsupported characters or name is too long.
• Verify that the user sees a validation error if provides name that is used by existing certificate on the same team.
• Verify that the user can't create a certificate if all fields aren't present.
• Make sure that once the certificate is added, the user can see the certificate name, CA name, and the uploaded at timestamp on /controls/os-settings/certificates page.
  • This should be tested a few times on a fully loaded loadtest instance because it uses replica DB. Dev note: @jacobshandling Are we using the old read after write pattern here? We know it fails if the replication lag is large. Should we try to not actively use this pattern going forward?
• Verify that when the user adds a certificate, the number of pending hosts in the summary section above the certificate list is increased by the number of hosts in that team. It should be increased right after the upload.
• Verify that once the certificate is added to the team, on the host details page (OS settings modal), the certificate is listed with the name that the user provided and pending status.
• Verify that when the certificate is actually installed on the Android host, the status is verified.
• Verify that a certificate template can't be saved if we use a non-existing Fleet variable (e.g., $FLEET_VAR_BOZO)
• Verify that the status on the host details page is failed if the user provides an IdP variable that is not available for that host.
• Make sure that the user can delete a certificate on the /controls/os-settings/certificates page, and that the user sees a confirmation modal.
• Verify that when the user deletes a certificate, the number of pending hosts in the summary section above the certificate list is increased by the number of hosts in that team. It should be increased right after the upload.
• Verify that once the certificate is deleted from the team, on the host details page (OS settings modal), the certificate is listed with the name that the user provided and pending status. (Removing enforcement)
• Verify that the certificate is actually deleted on the host when it's deleted in Fleet UI/API.
• Verify that if certificate is uninstalled, it's removed from the list.
• Verify that activities are generated when the user adds or deletes the certificate.
• Make sure that the Certificates page under Settings > Integrations is renamed to "Certificate authorities"

API

• Verify that the user can add a certificate via POST /api/v1/fleet/certificates
• Verify that the user can list added certificates via GET /api/v1/fleet/certificates
• Verify that the user can get a certificate's details via GET /api/v1/fleet/certificates/:id
• Verify that the user can delete a certificate via DELETE /api/v1/fleet/certificates/:id
• Verify that when a user is adding a certificate via POST /api/v1/fleet/certificates, Fleet validates the name and returns an error if the user specifies non-supported characters, or a too-long name, or a duplicate name.
  • Bug: /fleet/certificates validation missing #37761
• Verify that operation_type and status are returned in each certificate object under host.mdm.certificates (GET /host/:id endpoint).

Scenarios

• Add cert to a host; delete cert from host
• Add cert to a host; delete cert template; cert should be deleted from host
• Add cert to a host; delete CA; cert should remain on host
  • blocked by Cannot delete Certificate Authority due to Android cert templates #37739
• Move host from a team with cert(s) to a team with none
• Move host from a team without cert(s) to a team with some
• Move host from a team with certs(s) to a team with cert(s)
  • Have the certs on one team have the same names as the certs on the other team

GitOps

• Certs deleted via GitOps also get deleted on Android host

Testing notes

Confirmation

1. Engineer: Added comment to user story confirming successful completion of test plan.
2. QA: Added comment to user story confirming successful completion of test plan.