Gestione dei certificati in VMware 6.5 (for dummies)

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 :

#chsh –s /bin/bash root

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:

- Stop dei servizi

- Start dei servizi

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).