Nuova architettura per la gestione dei certificati
Prima di accedere alla console, alla GUI o immergersi nella
KB cerchiamo di capire la nuova architettura sulla quale si basa il vCenter
6.x. Nelle precedenti versioni di vCenter Server, ogni componente aveva il
proprio certificato:
Nella nuova architettura VMware, tutti questi certificati
sono stati rimpiazzati da solo quattro certificati (tecnicamente definiti
Solution Users (SU)). Ogni certificato dedicato è responsabile di un insieme di
servizi e componenti. La Platform Services Controller (PSC) è responsabile
della firma e delle memorizzazioni dei certificati in questa nuova
architettura. La PSC può essere sia embedded (stessa appliance del vCenter) che
external (appliance diversa dal vCenter).
In questa guida faccio riferimento ad una PSC esterna
(tuttavia le operazioni sono le medesime per quella interna).
Anche se non è il focus di questo documento, riporto di
seguito quelli che sono i vecchi ed i nuovi servizi forniti dalla PSC:
·
VMware Single Sign-On
o
Secure Token Service (STS)
o
Identity Management Service (IdM)
o
Directory Service (VMDir)
·
VMware
Certificate Authority (VMCA)
· VMware Endpoint Certificate Store (VECS)
·
VMware Licensing Service
·
Authentication Framework Daemon (AFD)
·
Component Manager Service (CM)
·
HTTP Reverse Proxy
A partire da vSphere 6.0, come servizio della PSC è stata
introdotta la “VMware Certificate Authority” (VMCA) con lo scopo di migliorare
il ciclo di vita dei certificati SSL ed agevolarne la gestione.
Con il passare del tempo, i certificati in ambiente vSphere
sono diventati sempre più importanti per quello che concerne la comunicazione
tra i vari servizi, soluzioni, utenti.
Come impostazione
predefinita, la VMCA funge da Certification Authority principale per l’intera
infrastruttura.
La VMCA è il punto centrale in cui i certificati possono
essere distribuiti in un ambiente vSphere senza dover creare manualmente
richieste di firma dei certificati (CSR) o installare manualmente i certificati
una volta generati.
La VMCA opera in combinazione con il nuovo archivio per il
salvataggio dei certificati chiamato VMware Endpoint Certificate Store (VECS). Il
VECS è dove vengono archiviati tutti i certificati all'interno della PSC, con
l'unica eccezione dei certificati ESXi che vengono memorizzati localmente sugli
host vSphere.
Riassumendo:
Dal momento che la VMCA opera come Certification Authority
quali sono i possibili scenari che mi si presentano?? Come posso utilizzare
questo tool??
Non è scopo di questo documento l’approfondimento di ogni
punto indicato nel diagramma precedente [14] [15] [16]; tuttavia intendiamo
approfondire l’utilizzo di VMCA come “Root CA” e come “Intermediate CA” per il
rilascio e la gestione dei certificati (punti 1 e 2).
Gli scenari 1 e 2 sono simili: la VMCA è la CA che rilascia
certificati per tutti i Solution Users (SU), l'unica differenza è che nello
scenario 1 la VMCA è la CA principale e sarà necessario distribuire il
certificato Root CA in modo che sia Trusted da tutti i browser aziendali,
mentre nello scenario 2 la VMCA diventa parte di un PKI esistente come CA
subordinata che ti rilascia la Trust.
Inoltre in vSphere 6.0 è stato aggiunto un servizio reverse
proxy per le comunicazioni server verso i servizi dl vCenter Server, la
comunicazione viene fatta tramite la porta 443 e garantita dal certificato SSL
Machine del server vCenter. Il certificato SSL della macchina diventa il modo
principale in cui gli utenti proteggono le comunicazioni verso il vCenter
Server e la PSC.
Per dovere di cronaca, riporto che è possibile impostare le
modalità con la quale deve operare vCenter per quello che riguarda la gestione
dei certificati. Sempre a partire da vSphere 6.0, gli host ESXi vengono forniti
di default con certificati rilasciati dalla VMCA. È tuttavia possibile utilizzare
la modalità di certificazione Custom, o per scopi di debug la modalità legacy
thumbprint mode.
Nella maggior parte dei casi, cambiare la modalità di
operare della VMCA è “disruptive” e non necessario. Se si richiede un cambio di modalità,
esaminare l'impatto potenziale prima di iniziare. La chiave da modificare per
cambiare la modalità di operare per la gestione dei certificati si imposta
negli “Advanced Settings” del vCenter Server modificando la chiave
“vpxd.certmgmt.mode” (come indicato nell’immagine di seguito). I valori che
posso inserire sono “vmca”, “custom”, “thumbprint”.
Riassumendo le modalità :
ESXi Certificate
Management Modes
-
VMCA Authority Mode
-
Custom Mode
-
Thumbprint Mode
Per maggiori informazioni consultare [1]
Gestione dei Certificati: VMCA utilizzata come una CA
intermedia.
Dopo la breve spiegazione sui vari ruoli delle componenti, vediamo
in questa sessione come sostituire il certificato self-signed generato di
default in fase di installazione della PSC e del vCenter Server e quello dei
nodi ESXi.
In questa breve descrizione passo-passo diamo per scontati
di disporre di una CA (Certification Autority) con un template valido da
applicare per il rilascio del certificato come indicato in questa KB VMware [19].
Post installazione il nodo ESXi ha un certificato
autogenerato salvato localmente sotto la directory “/etc/vmware/ssl”. Quando l’Host viene
aggiunto al vCenter, la VMCA rilascia al nodo ESXi un certificato firmato con
tutta la catena fornita dalla VMCA. Con le nuove versioni di vSphere il rinnovo
dei certificati può essere effettuato direttamente da vSphere Web Client o
tramite PowerCLI [14].
ATTENZIONE: se si utilizza la
VMCA come Enterprise Subroutine CA; il certificato (firmato) utilizzato (dalla
VMCA) deve avere una data valida e deve essere stato generato 24 ore prima del
rilascio, in questo modo è possibile rinnovare i certificati degli host ed/o
aggiungere nuovi host al vCenter.
Successivamente il rinnovo o il refresh dei certificati con
le nuove versione di ESXi (dalla 6.0 in poi) è possibile effettuarlo
direttamente dal client web cliccando sull’ HOST -> Certificates
-> Renew Certificate come
indicato dall’immagine sotto.
Di seguito Step-by-Step per far diventare la VMCA una
“Intermediate CA”
Per prima cosa connettersi via SSH alla PSC (come detto in
precedenza in questo caso la PSC è esterna al vCenter) ed abilitare la Shell
(in questa guida è stata utilizzata una PSC versione 6.0.0 nulla cambia per le
versioni future).
Command> shell.set –enable True
Command> shell
|
Cambiare la shell di login in bash così da poter accedere
direttamente al sistema come indicato di seguito tramite il comnado :
Spostarsi sotto la directory “/usr/lib/vmware-vmca/bin” e
lanciare il comando “./certificate-manager”
psc#
cd /usr/lib/vmware-vmca/bin
psc:/usr/lib/vmware-vmca/bin/#
./certificate-manager
|
Selezionare prima l’opzione “2” (Replace VMCA Root
certificate with Custom Signing Certificate and replace all Certificates),
inserire la Password di SSO e quindi selezionare l’opzione “1” (Generate
Certificate Signing Request(s) and Key(s) for VMCA Root Signing certificate)
come indicato in figura sotto.
In questo modo siamo in grado di generare la richiesta di
certificato per una SUB-CA, a sua volta in grado di verificare e firmare i
certificati rilasciati da vCenter/PSC agli altri componenti.
Inserire un percorso temporaneo dove posizionare il file di
richiesta certificato da far firmare alla CA. Nel nostro caso “/tmp/”.
Generata dal sistema la richiesta di certificato con la
relativa chiave come indicato di seguito:
Copiare entrambi i file generati “root_signging_cert.csr” e
“root_signing_cert.key” localmente (utilizzando qualsiasi tipo di tool in grado
da copiare dalla PSC ad un sistema linux/windows/mac) per poterli poi
sottoporre alla firma della CA. Ad esempio utilizando WinSCP.
Una volta copiati i file localmente editare con un notepad il
file “root_signing_cert.csr” selezionarne tutto il contenuto come di seguito ed
…
incollarlo nella CA. Nel nostro caso utilizziamo una CA
Microsoft precedentemente configurata come indicato nella seguente KB2112009
[19]. Selezionare quindi il template creato in precedenza.
Scaricarsi il certificato in formato “Base 64 encoded”
Rinominare il file salvato in “root_signing_cert.cer” scaricarsi quindi il certificato di root CA
sempre “Base 64” e rinominarlo “root.ca.cer”
Posizionarsi nella directory dove sono stati scaricati i due
certificati ed effettuare una copia del certificato “root_signing_cert.cer” e rinominarlo in “root_signing_chain.cer” in modo da ottenere tre certificati come
indicato nell’immagine sotto:
A questo punto occorre creare un certificato con unico Root
CA – Signed; nel seguente modo:
-
Editare con un notepad il certificato “root.ca.cer”, selezionare e copiare
tutto il contenuto.
-
Quindi editare con il notepad il certificato “root_signing_chain.cer” scendere in
fondo ed incollare quanto precedentemente copiato (come mostrato dalla figura
sotto).
-
Salvare ed uscire.
Copiare ora i certificati e
chiavi; ma nello specifico i certificati “root_signing_cert.cer”
e “root_signing_chain.cer” nella
directory /tmp della PSC, in modo da avere una situazione simile a quella
indicate di seguito.
Ritornare sulla schermata della PSC e procedere scegliendo
l’opzione “1”; indicando in primis il certificato valido per identificare la
Root CA “/tmp/root_signing_chain.cer”
e quindi la chiave “/tmp/root_signing_cert.key”.
Caricati i certificati, ci viene richiesto se rimpiazzare il
certificate di Root con quello “Custom” appena caricato ed andare a rimpiazzare
tutti gli altri certificati. Premere “Y”.
Compilare tutti i campi indicati per generare e firmare
automaticamente (dalla nuova Root) un nuovo certificato per la PSC. Vedi di
seguito.
IMPORTANTE: il campo indicato in rosso inserire l’FQDN della
PSC.
Se tutto si è completato con successo; il nuovo certificate
di Root è stato caricato ed il nuovo certificate per la PSC generato. Per renderli
attivi occorre riavviare i servizi come indicato dall’immagine sopra
(connettendosi al vCenter Server).
Connettiamoci al vCenter Server, attiviamo la shell come
indicato in precedenza e riavviamo i servizi come indicato di seguito:
riavviati i servizi, dobbiamo procedere con la sostituzione
dei certificati con i nuovi forniti dalla VMCA.
Sostituzione “Machine SSL certificate” con quelli
della VMCA Certificate
Andiamo quindi a rimpiazzare tutti i certificasti con quelli
nuovi generati dalla VMCA.
Posizionarsi come per la PSC in “/usr/lib/vmware-vmca/bin” e lanciare il comando “./certificate-manager” e scegliere
l’opzione “3” ed inserire la password di SSO.
Indicare come “valid Infrastructure Server IP” l’FQDN della PSC, compilare tutti i campi come
indicato di seguito ed indicando come “Proper value for Hostname” l’FQDN del
vCenter (vedi sotto).
Proseguiamo con la ri-generazione dei certificati SSL
Machine usando la VMCA premendo “Y”.
Sostituzione “Solution User certificate” con quelli
della VMCA Certificate
Essendo posizionati nel vCenter Server nella directory “/usr/lib/vmware-vmca/bin” lanciare il
comando “./certificate-manager” e
scegliere l’opzione “6” ed inserire la password di SSO.
Indicare quindi come “valid Infrastructure Server IP”,
l’FQDN della PSC. Scegliere l’opzione “Y”. Effettuare il logout dal vCenter
Server (vedi immagine sotto).
Verifica dei certificati
Ri-aprendo il browser, possiamo verificare la validità dei certificati
sia per la PSC che per il vCenter Server.
I certificati sono stati sostituiti con successo.
---------------------------------------------------
Link Utili
[1] vSphere
Security
vsphere-esxi-vcenter-server-651-security-guide.pdf
Disclaimer:
Le immagini utilizzate in questa pagina appartengono ai legittimi proprietari.
----------------------------------------------------