An Expired Prism Certificate, Broken PC-PE Trust, and a Secure Boot Audit
Northwind's estate is Prism Central plus nine AHV clusters. Certificates come from an internal Microsoft CA with 1-year validity and no renewal automation. Last month one cluster's Prism Element certificate expired: browsers showed warnings that admins clicked through, Prism Central lost trust to that cluster and showed it disconnected, and Flow policy pushes to it failed for 90 minutes until someone manually replaced the certificate. Two nodes added the same week registered with self-signed certificates. Separately, a regulated workload team requires UEFI Secure Boot on its VMs, and auditors have asked for evidence of boot integrity. Change windows are monthly; the CA team is a separate group with a two-week lead time.
1. Give the remediation order for the incident and explain why the browser warning was the least important symptom.
Read the worked answer
Order of work:
- Restore the Prism Element certificate from the internal CA: generate the CSR on the cluster, submit to the CA, import the signed certificate with the full issuing chain.
- Re-establish Prism Central ↔ Prism Element trust and confirm the cluster returns to a connected, manageable state.
- Verify the functions that silently degraded, not just the UI: policy/Flow propagation to that cluster, protection domain and replication status, alerting and inventory sync. A disconnected cluster in Prism Central is a visibility gap - you may have been blind to it for longer than the 90 minutes.
- Sweep the remaining eight clusters and Prism Central for certificates expiring inside the CA team's two-week lead time and raise those requests immediately.
Why the browser warning mattered least: the warning was visible but the damage was in the machine-to-machine trust. Admins clicking through a warning normalises bypassing the exact control that protects the management plane, and it hides the real failure - automation between Prism Central and the cluster had already stopped. The certificate is an availability control for the control plane before it is a user-experience issue.
2. Design the process so this cannot recur, given the CA team is separate and windows are monthly.
Read the worked answer
Build an inventory and a runway, not a reminder.
- Export every certificate in scope - Prism Central, each Prism Element, KMS client certificates, any load balancer or identity integration - with expiry dates into a tracked inventory with owners.
- Alert at 60/30/14/7 days to the platform team, and at 60 days automatically open the CA request, because the CA lead time is two weeks and the change window is monthly. The 60-day trigger, not the 14-day one, is what actually prevents recurrence.
- Include certificate expiry as a standing line item in the monthly change review; renew on a fixed cadence before expiry rather than reacting.
- Standardise on the internal CA-issued certificates with the correct SANs and full chain, and make self-signed certificates on newly added nodes a known, checked state rather than a surprise - add it to the node-add checklist.
- Forbid click-through: alert on any certificate warning or trust failure in the management plane as an incident.
Judgement call on automation: full automation of renewal is ideal but depends on a group you do not control. A monitored manual process with a 60-day runway is a defensible interim control; pretending a ticket in a backlog is a control is not.
3. The regulated team wants UEFI Secure Boot on their VMs and the auditors want evidence of boot integrity. Separate these two requests and say what each requires.
Read the worked answer
They are different controls with different scopes and different evidence.
1. Secure Boot for guest VMs. Enabled per VM on AHV using UEFI firmware with Secure Boot, and it only works where the guest OS and its boot chain support it. Plan: confirm guest OS support, enable on a pilot VM, validate boot and any drivers or hypervisor-level agents the workload uses, then roll out to the regulated VMs. Some legacy workloads will fail - capture them as documented exceptions with compensating controls rather than disabling the feature estate-wide for the sake of one appliance. Evidence: VM configuration showing UEFI Secure Boot enabled, plus the pilot test results.
2. Host boot integrity. Secure Boot on guests says nothing about whether the AHV hosts booted what you think they booted. That is covered by the cluster hardening baseline - firmware and image versions, signed images, controlled boot order, management-plane restrictions - and, where implemented, attestation of host boot state.
What to hand the auditor: the guest configuration evidence, the host hardening baseline with compliance results, firmware/image version inventory, and the exception list with justifications. Do not let the guest Secure Boot setting be presented as evidence for host integrity - an auditor who knows the difference will treat the whole submission as unreliable.