Su vSphere Foundation i certificati non vivono in un posto solo, e nemmeno il ciclo di vita. Ci sono due piani: quello di vSphere — vCenter, ESX, vSAN — con la sua PKI storica, e quello del fleet, dove VCF Operations fa da console unica per certificati e aggiornamenti. Capire quale piano tocca quale oggetto è metà dell’obiettivo 4.2.

La PKI di vSphere: VMCA, VECS e le modalità di gestione

vCenter porta con sé la VMware Certificate Authority (VMCA), che provvede i componenti di vCenter e gli host ESX, e il VMware Endpoint Certificate Store (VECS), il repository locale lato client dove stanno certificati, chiavi private e trusted root. I certificati che contano sono tre famiglie: il machine SSL (la connessione TLS che vedi nel browser), i solution user (con cui i servizi si autenticano a vCenter Single Sign-On) e i certificati degli host ESX.

Le modalità sono quattro. Nella predefinita, VMCA è la root CA di tutto. Nella seconda, VMCA viene firmata da una CA aziendale e diventa CA intermedia: la catena risale alla tua PKI, ma l’emissione resta automatica. Nella terza — full custom — ogni nodo riceve un certificato emesso dalla tua PKI o da una CA esterna, con la catena di firma completa. La quarta è ibrida: machine SSL custom, solution user lasciati a VMCA.

Nel vSphere Client visualizzi e sostituisci machine SSL, VMCA root, trusted root e STS, aggiungi nuove trusted root e generi CSR personalizzate. Quando il flusso è più pesante — rigenerare la root VMCA e ri-emettere tutto, rendere VMCA intermedia, sostituire tutto con certificati custom — si passa all’utility a riga di comando /usr/lib/vmware-vmca/bin/certificate-manager sulla vCenter appliance, che ha anche le due opzioni che salvano la giornata: il revert dell’ultima operazione e il ripristino di tutti i certificati a VMCA.

Fleet Management > Certificates

Da VVF 9.0 la vista d’insieme sta altrove. Ti colleghi a https://<vcf_operations_fqdn> con ruolo Administrator e vai in Fleet Management → Certificates, dove i certificati sono raggruppati in VCF Management (i componenti di gestione, validi per tutto il fleet) e VCF Instances (i componenti core, per istanza o dominio). Il toggle Show ESX Hosts mostra o nasconde gli host, i filtri lavorano su tipo, stato e componente, e Certificate Alerts raccoglie gli avvisi.

Prima di rinnovare qualsiasi cosa con una CA reale devi fare Configure CA. Attenzione alla dissimmetria: i componenti di gestione VCF supportano solo Microsoft Certificate Authority, mentre i componenti d’istanza accettano Microsoft CA e OpenSSL. Per Microsoft CA servono CA Server URL (deve iniziare con https:// e finire con certsrv), utenza di servizio, password e Template Name; per OpenSSL i campi del subject (Common Name, Organization, Organization Unit, Locality, State, Country). Prerequisiti banali ma letali: raggiungibilità della CA e orologi sincronizzati.

Con la CA configurata hai tre strade. Renew Certificate sul singolo componente rinnova certificati VMCA, Microsoft CA, OpenSSL o self-signed — ma le root non si rinnovano. Il toggle Activate Auto-renewal automatizza il rinnovo, che scatta 60 giorni prima della scadenza, sui componenti che reggono un aggiornamento non disruptivo. Per una CA esterna il percorso è più lungo: Generate CSR (key size 2048 o 4096, ma sugli host ESX solo 2048, con i SAN corretti), Download CSR, firma presso la tua CA, Import Certificate — testo PEM incollato oppure catena caricata in .crt, .cer, .pem, .p7b, .p7c — poi Validate, Save e infine Replace With Imported Certificate. Se la CA è configurata in VCF Operations salti il giro e usi Replace With Configured CA Certificate.

Le sostituzioni falliscono quasi sempre per gli stessi motivi, e sono requisiti scritti: il SubjectAltName deve contenere DNS Name=FQDN della macchina, niente wildcard, solo RSA per i certificati emessi ai server, chiavi da 2048 a 8192 bit in PEM, Extended Key Usage vuoto oppure Server Authentication, algoritmi di firma deboli (sha1WithRSAEncryption, md5, dsaWithSHA1) rifiutati, e per una VMCA intermedia il CRL signing abilitato sulla root.

Ciclo di vita: due livelli, un ordine

Anche il lifecycle è a due livelli. I VCF management components (VCF Operations, VCF Operations fleet management, VCF Operations for Logs) si gestiscono a livello di fleet; i VCF core components (in VVF: vCenter, ESX, vSAN) a livello di istanza. Le release sono quattro tipi: Major (9.0.0.0), Minor (9.1.0.0), Maintenance (9.0.1.0) e Patch (9.0.1.0100). Vale una regola secca: puoi aggiornare solo verso una versione rilasciata dopo la data di rilascio di quella che hai. E un ordine: la VCF Operations fleet management appliance va aggiornata o patchata per prima, prima di qualsiasi altro componente di gestione.

I binari passano da Fleet Management → Lifecycle → Binary Management, con tre modelli di depot: online verso il portale Broadcom (serve un download token), offline su un web server tuo, offline locale per i dark site — popolato dal VCF Download Tool, la CLI dedicata. Scegli tipo di binario (install, upgrade o patch), versione e componente, poi DOWNLOAD; l’icona del cestino rimuove quelli che non servono più. L’upgrade planner (Fleet Management → Lifecycle → VCF Instances → dominio → Updates) esegue i precheck, ti fa scegliere le versioni target per singolo componente — è il flexible BOM upgrade — e genera la sequenza da rispettare.

Immagini, host e vCenter

Gli host li aggiorna vSphere Lifecycle Manager, che dal deploy di vCenter è già attivo nel vSphere Client. L’unità di lavoro è l’immagine: ESX base image più vendor add-on, firmware and drivers addon e componenti aggiuntivi; definisce lo stack software esatto di tutti gli host del cluster. Il ciclo è compliance check → staging → remediation pre-check → remediation. L’Image Library è il repository centralizzato delle specifiche desiderate in una istanza vCenter, esportabili e importabili in JSON verso altri vCenter — non confonderlo con il depot, che contiene i bit. Su hardware eterogeneo un’immagine composita ammette fino a quattro definizioni aggiuntive, assegnate a host specifici o automaticamente in base alle informazioni BIOS. In un ambiente VVF le immagini si creano nel vSphere Client e si importano nell’istanza con VCF Operations. Gli hardware compatibility check validano l’hardware contro la Broadcom Compatibility Guide e la vSAN HCL: di norma un’incompatibilità non impedisce la remediation, ma vLCM si può configurare perché la blocchi.

Su vCenter, il Reduced Downtime Upgrade è basato su migrazione: viene distribuita una nuova appliance e vi si copiano dati e configurazione, con un disservizio sotto i cinque minuti in condizioni ideali (per esempio da vSphere 8.0 Update 3 a 9.0). Non sostituisce il processo di upgrade classico. E prima di qualunque aggiornamento: backup file-based dalla vCenter Management Interface, verso FTP, FTPS, HTTP, HTTPS, SFTP, NFS o SMB, anche schedulato; il restore si fa con il GUI installer, che distribuisce una nuova appliance e vi riversa il backup.

Trappole tipiche d’esame

  • I nomi di menu sono condivisi con VCF, i componenti no. In Fleet Management → Certificates leggi «VCF Management» e «VCF Instances» anche su vSphere Foundation, e le pagine generiche citano SDDC Manager e NSX Manager: in VVF non esistono, non ci sono workload domain e non c’è nulla di NSX da rinnovare. I componenti che vedi sono vCenter, ESX, vSAN e gli appliance di gestione.
  • «Rinnova» non vale per tutto. I root certificate non si rinnovano; l’auto-renewal parte a 60 giorni dalla scadenza e solo sui componenti che tollerano un aggiornamento non disruptivo. Una domanda su «certificato root in scadenza fra 30 giorni, attivo l’auto-renewal» ha risposta negativa.
  • Microsoft CA e OpenSSL non sono intercambiabili. I componenti di gestione accettano solo Microsoft CA; OpenSSL è ammesso solo sui componenti d’istanza. E il CA Server URL che finisce con certsrv è un dettaglio che l’esame chiede alla lettera.
  • Image Library ≠ depot. La prima conserva le specifiche delle immagini (esportabili in JSON fra vCenter), il secondo i binari. Allo stesso modo, in VVF le immagini si creano nel vSphere Client e si importano con VCF Operations: invertire i due verbi è la risposta sbagliata classica.
  • Ordine e prerequisiti. La fleet management appliance si aggiorna per prima, si può salire solo verso release più recenti della data di rilascio dell’attuale, e un hardware fuori dalla Broadcom Compatibility Guide di per sé non blocca la remediation a meno che tu non abbia configurato vLCM perché lo faccia.