Veeam KB4895 describes standalone AIX and Solaris agents that can no longer connect after the backup server certificate changes twice. The server retains the current and previous certificate, while a dormant agent may still trust an older one. A formally successful PKI change can therefore leave legacy systems outside the backup control plane.
Why it matters in production
The inventory should identify every standalone Unix agent, its last successful session, stored trust state, owner, network path, job schedule, and business recovery requirement. Rarely connected systems deserve priority because their silence makes them easiest to miss before the second rotation removes the remaining trust overlap.
Certificate changes need a synchronization window. Bring agents online, refresh trust, verify job execution, and monitor disconnects before rotating again. If an agent cannot participate, document the supported recovery procedure and the exact credentials and access required instead of discovering it during an outage.
Monitoring should distinguish an intentionally idle agent from one that has lost trust. Alert on missed backup windows and stale management contact, retain certificate-change records, and include AIX and Solaris owners in the approval and validation chain.
Practical takeaway
The practical conclusion is that certificate rotation is an application event, not only a PKI event. Every client that pins or stores trust must cross the rotation boundary. For old Unix estates, that proof belongs in the change before the previous certificate disappears.