Please use Google Translator button on the right to convert from Italian to your language
In questo articolo andremo a cambiare il certificato del cluster di NSX includendo il Common Name del VIP e i SAN corrispettivi dei vari nodi (oltre allo stesso VIP).
Il primo step consiste nel preparare un file per generare il CSR
#vi ssl-nsx-s2-all.conf
[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
x509_extensions = usr_cert
req_extensions = req_ext
prompt = no
[ req_distinguished_name ]
countryName = IT
stateOrProvinceName = Lombardy
localityName = Milan
organizationName = Nested vLabs
organizationalUnitName = Nested vLabs
commonName = nsx-s2-vip.nvlabs.local
[ usr_cert ]
extendedKeyUsage = serverAuth
[ req_ext ]
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = nsx-s2-vip.nvlabs.local
DNS.2 = nsx-s2-01.nvlabs.local
DNS.3 = nsx-s2-02.nvlabs.local
DNS.4 = nsx-s2-03.nvlabs.local
IP.1 = 192.168.20.24
IP.2 = 192.168.20.21
IP.3 = 192.168.20.22
IP.4 = 192.168.20.23
Generiamo il CSR
#openssl req -out nsx-s2-all.csr -newkey rsa:2048 -nodes -keyout nsx-s2-all.key -config ./ssl-nsx-s2-all.conf -sha256
A questo punto è necessario mandare il CSR alla CA per generare il certificato e una volta ottenuto si dovrà concatenarlo con quello della CA
#cat RootCA.cer >> nsx-s2-all.cer
Ora bisogna aprire la la pagina dei certificati dal VIP di NSX (come da immagine seguente) per importare la private key e la chain dei certificati.
E’ importate che il flag “Service Certificate” sia impostato a NO
Se tutto è andato bene verrà caricato il nuovo Cert.
Cliccare sul campo ID per prendere nota del valore del certificato
Una volta effettuato questo passaggio è necessario validare il certificato caricato prima di pubblicarlo.
Collegarsi in ssh come root sul primo manager per verificare se il certificato è valido utilizzando ID preso in precedenza
#curl -k -H ‘X-NSX-Username:UC’ -H ‘X-Nsx-Groups:superusers’ -X GET http://localhost:7440/nsxapi/api/v1/trust-management/certificates/f60d704d-cd03-4964-9975-3a8f2e5a796c?action=validate
E’ possibile che validazione la validazione dia un errore
{
“status” : “REJECTED”,
“error_message” : “Certificate was rejected: CRL check failed: Couldn’t get LDAP context from URI ldap:///CN=nvlabs-DC-S1-01-CA(1),CN=dc-s1-01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=nvlabs,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint”
}
Per validarlo è necessario lanciare una post per verificare il valore che ci restituisce l’errore
#curl -k -H ‘X-NSX-Username:UC’ -H ‘X-Nsx-Groups:superusers’ -X GET http://localhost:7440/nsxapi/api/v1/global-configs/SecurityGlobalConfig
{
“crl_checking_enabled” : true,
“ca_signed_only” : false,
“eku_checking_enabled” : true,
“resource_type” : “SecurityGlobalConfig”,
“id” : “07c8dac6-e3f7-49a4-861b-efd949c8940f”,
“display_name” : “07c8dac6-e3f7-49a4-861b-efd949c8940f”,
“_create_user” : “system”,
“_create_time” : 1599511835194,
“_last_modified_user” : “system”,
“_last_modified_time” : 1627742517927,
“_system_owned” : false,
“_protection” : “NOT_PROTECTED”,
“_revision” : 47
La stringa “crl_checking_enabled” verrà messa a false
Prendere nota della “_revision” dal post di prima e creare un json cambiando il revision id
#vi crl.json
{
“crl_checking_enabled” : false,
“resource_type” : “SecurityGlobalConfig”,
“_revision” : 47
}
Lanciare un post per cambiare il valore
#curl -k -H ‘X-NSX-Username:UC’ -H ‘X-Nsx-Groups:superusers’ -H ‘Content-Type:application/json’ -X PUT http://localhost:7440/nsxapi/api/v1/global-configs/SecurityGlobalConfig -d@./crl.json
{
“crl_checking_enabled” : false,
“ca_signed_only” : false,
“eku_checking_enabled” : true,
“resource_type” : “SecurityGlobalConfig”,
“id” : “07c8dac6-e3f7-49a4-861b-efd949c8940f”,
“display_name” : “07c8dac6-e3f7-49a4-861b-efd949c8940f”,
“_create_user” : “system”,
“_create_time” : 1599511835194,
“_last_modified_user” : “UC”,
“_last_modified_time” : 1627757544608,
“_system_owned” : false,
“_protection” : “NOT_PROTECTED”,
“_revision” : 48
Rilanciare il post di validazione che darà OK
#curl -k -H ‘X-NSX-Username:UC’ -H ‘X-Nsx-Groups:superusers’ -X GET http://localhost:7440/nsxapi/api/v1/trust-management/certificates/f60d704d-cd03-4964-9975-3a8f2e5a796c?action=validate
{
“status” : “OK”
}
Ora che abbiamo la certezza della validità, andiamo ad aggiornare il certificato del Cluster e dei 3 NSX Manager (le seguenti chiamate devono essere fatte usando l’IP o Hostname dei server utilizzando lo user admin con relativa password)
Certificato del Cluster
#curl -k -u admin:’PASSWORD’ -X POST ‘https://localhost/api/v1/cluster/api-certificate?action=set_cluster_certificate&certificate_id=f60d704d-cd03-4964-9975-3a8f2e5a796c‘
Certificato dei 3 nodi
#curl -k -u admin:’PASSWORD’ -X POST ‘https://nsx-s2-01.nvlabs.local/api/v1/node/services/http?action=apply_certificate&certificate_id=f60d704d-cd03-4964-9975-3a8f2e5a796c‘
#curl -k -u admin:’PASSWORD’ -X POST ‘https://nsx-s2-02.nvlabs.local/api/v1/node/services/http?action=apply_certificate&certificate_id=f60d704d-cd03-4964-9975-3a8f2e5a796c‘
#curl -k -u admin:’PASSWORD’ -X POST ‘https://nsx-s2-03.nvlabs.local/api/v1/node/services/http?action=apply_certificate&certificate_id=f60d704d-cd03-4964-9975-3a8f2e5a796c‘
A questo punto ci rimane solo di verificare con un browser che il VIP e i 3 Manager ci propongano il certificato appena caricato.
Nested vLabs 