Quando si gestiscono più sottodomini avere un certificato SSL wildcard è una delle soluzioni più comode per semplificare la configurazione e mantenere tutto protetto con un solo certificato.

In questo scenario l’accoppiata tra Nginx Proxy Manager, Let’s Encrypt e Cloudflare rappresenta una soluzione pratica, moderna ed efficace, soprattutto se si vuole automatizzare il rilascio e il rinnovo dei certificati senza impazzire con configurazioni manuali.

In questo articolo vedremo come configurare un certificato wildcard Let’s Encrypt in Nginx Proxy Manager utilizzando Cloudflare tramite DNS Challenge, una procedura particolarmente utile quando i servizi non sono esposti direttamente in pubblico oppure quando si desidera una gestione più pulita e flessibile dei sottodomini.

Ti guiderò passo dopo passo nella configurazione spiegando non solo cosa fare, ma anche perché farlo, così da ottenere un setup affidabile, sicuro e facilmente replicabile.

PREREQUISITI

• Dominio gestito su Cloudflare
• Nginx Proxy Manager funzionante
• Accesso admin a Cloudflare
• Possibilità di creare un API Token Cloudflare con permessi DNS minimi

Per i token Cloudflare, la combinazione raccomandata è:

Zone – DNS – Edit

Zone – Zone – Read

Cloudflare documenta la creazione dei token, e questa coppia di permessi è anche quella normalmente richiesta dai client ACME che usano Cloudflare.

CONFIGURARE IL DOMINIO SU CLOUDFLARE

Accedere a Cloudlfare

Cliccare su Add quindi selezionare Connect a Domain

Inserire il nome del dominio quindi selezionare l’opzione Import DNS records automatically. We will scan for common DNS records and import them for you.

Quindi cliccare Continue

Selezionare il piano. Nel mio caso selezionerò quello Free

In questa fase verificare che siano stai creati tutti i record DNS presenti sul provider di origine.

Quindi cliccare Continue to Activation al fondo della pagina

A questo punto sostituire sul provider i Nameservers inserendo quelli di Cloudflare e quindi:

annabel.ns.cloudflare.com

nash.ns.cloudflare.com

Trovare e disattivare l’impostazione di sicurezza DNS (DNSSEC), se è attiva. Potremo riattivarla in seguito tramite Cloudflare.

Consentire al tuo server di origine solo gli indirizzi IP di Cloudflare

Quindi cliccare I updated my nameservers

In questa schermata siamo in attesa che il registrar propaghi i nuovi nameserver

E’ in corso la verifica che il tuo dominio punti a Cloudflare.

In genere sono necessarie 1-2 ore, ma potrebbero volerci fino a 24 ore, a seconda del tuo registrar. Lo stato viene controllato periodicamente.

Cliccare check nameservers now per verificare lo stato

Al termine della propagazione dovremmo visualizzare una schermata come quella sovrastante che ci dice che il dominio ora è protetto da Cloudflare.

A questo punto sarà possibile gestire i record DNS da Cloudflare

CREAZIONE DEL TOKEN API SU CLOUDLFLARE

Dalla Dashboard di Cloudlfare

Cliccare su My Profile → API Tokens → Create Token

Utilizzare il template tipo Edit zone DNS e poi restringilo al tuo dominio.

Cliccare Use Template

Sopra un immagine che mostra le impostazioni consigliate da impostare sul template

Impostazioni consigliate del token:

Permissions

Zone / DNS / Edit

Zone / Zone / Read

Zone Resources

Include / Specific zone / tuodominio.it

Quindi cliccare su Continue to Summary

ATTENZIONE: Questo è meglio della vecchia Global API Key che Cloudflare sconsiglia in favore degli API token.

Cliccare su Create Token

Quando Cloudflare ti mostra il token copiarlo subito, conservalo in modo sicuro e non condividerlo con nessuno

CONFIGURAZIONE DI NGINX PROXY MANAGER

Aprire Nginx Proxy Manager

Cliccare su Certificates nel menù in alto quindi Add Certificate e selezionare Let’s Encrypt via DNS

A questo punto inserire i nomi di dominio corretti.

Nel campo domini inserire: *.tuodominio e tuodominio.it

In questo modo il certificato:

*.tuodominio.it copre app.tuodominio.it, home.tuodominio.it, vpn.tuodominio.it

tuodominio.it copre il dominio principale

ATTENZIONE: Ricorda che *.tuodominio.it non copre tuodominio.it

Questa è una caratteristica normale dei wildcard certificate. Il DNS-01 serve proprio a validare questo tipo di richiesta.

Impostare come Key Type: RSA 2048

Come DNS Provider impostare: Clouflare

Nella sezione Credential File Content: dns_cloudflare_api_token=IL_TUO_TOKEN

Nella sezione Propagation Seconds: impostare i secondi da attendere per la propagazione. Lasciarlo vuoto per usare la propagazione di default.

Cliccare Save

Se è andato tutto a buon fine dovremmo visualizzare una schermata come quella sovrastante con il provider di emissione del certificato e la data di scadenza.

A questo punto NPM prova a:

• chiedere il certificato a Let’s Encrypt
• creare via API su Cloudflare il record TXT _acme-challenge
• attendere la propagazione DNS
• completare la validazione DNS-01
• salvare il certificato e configurarne il rinnovo automatico

NOTA BENE: Let’s Encrypt conferma che il DNS-01 funziona creando TXT record di validazione e che è il metodo richiesto per i wildcard.

ATTENZIONE: Per capire se il record viene creato davvero:

da fuori: controlla _acme-challenge con Resolve-DnsName o nslookup
da dentro: controlla i log del container NPM
non fidarti solo della UI di Cloudflare, perché il TXT può essere temporaneo e sparire subito

ASSEGNAZIONE DEL CERTIFICATO AI PROXY HOST

Quando il certificato compare in SSL Certificates andare sul Proxy Host e:

• aprire il proxy host
• posizionarsi nella scheda SSL
• seleziona il certificato wildcard appena creato
• abilitare Force SSL, HTTP/2 Support e HSTS Enabled solo se sai di volerlo davvero

Salvare la configurazione.

Da quel momento i sottodomini coperti dal certificato useranno quel wildcard.

Se è tutto OK dovremmo visualizzare una schermata come quella sovrastante.

CONTROLLO DEL FUNZIONAMENTO DEL CERTIFICATO

Di seguito una serie di controlli rapidi per verificare che tutto funzioni.

In NPM → SSL Certificates il certificato deve risultare valido

Aprendo https://app.tuodominio.it il browser deve mostrare certificato valido

Nel certificato devono comparire i SAN:

*.tuodominio.it e tuodominio.it

ERRORI PIU’ COMUNI E COME RISOLVERLI

1) Permessi token insufficienti

Sintomo:

• errore tipo 403
• impossibilità di leggere la zone o creare il TXT

Controllare il token Cloudflare:

• Zone:DNS:Edit
• Zone:Zone:Read
• limitato alla zone corretta

2) Hai impostato solo *.tuodominio.it

Risultato:

• i sottodomini funzionano
• https://tuodominio.it non funziona

Per coprire anche il dominio base devi aggiungere anche tuodominio.it. Il wildcard da solo non basta.

3) Il dominio non usa davvero Cloudflare DNS

Sintomo:

• Cloudflare accetta il token
• ma il challenge non si completa

Se i nameserver del dominio non puntano davvero a Cloudflare, NPM può non riuscire a pubblicare il TXT dove Let’s Encrypt lo cerca.

4) Propagazione DNS o pre-check fallito

Sintomo:

• errori su TXT non trovato

Il DNS-01 dipende dalla visibilità pubblica del record TXT. Let’s Encrypt verifica via DNS pubblico, non tramite richieste HTTP al server.

Spesso basta:

• rifare la richiesta
• attendere un po’
• controllare che non ci siano problemi di permessi/token

5) Hai usato la Global API Key invece del Token

Può funzionare in alcuni flussi legacy ma Cloudflare raccomanda gli API token al posto della Global API Key.

Buone pratiche:

• usare un token limitato a una sola zone
• non usare la Global API Key
• includere sia *.tuodominio.it sia tuodominio.it
• non cancellare il certificato dopo averlo associato ai proxy host
• controllare ogni tanto che il rinnovo automatico continui a funzionare

C’è anche un aspetto di sicurezza: Let’s Encrypt segnala che nel DNS-01 le credenziali API restano sul server quindi vanno trattate con attenzione.

UniFi OS Server rappresenta una soluzione sempre più interessante per chi desidera centralizzare la gestione della propria infrastruttura di rete in modo semplice, moderno e scalabile.

Installarlo su Ubuntu 24.04 permette di sfruttare una piattaforma stabile, aggiornata e adatta sia ad ambienti domestici evoluti sia a contesti professionali di piccole e medie dimensioni.

In questo articolo vedremo come eseguire l’installazione e la configurazione base di UniFi OS Server su Ubuntu 24.04, partendo dai prerequisiti fino ai primi passaggi fondamentali per rendere il sistema operativo e pronto alla gestione dei dispositivi UniFi.

L’obiettivo è fornire una guida pratica e lineare, utile per chi vuole avvicinarsi a questa piattaforma senza perdersi in configurazioni complesse fin dall’inizio.

Al termine della procedura avrai un’istanza funzionante di UniFi OS Server, configurata correttamente e pronta per essere personalizzata in base alle esigenze della tua rete.

ATTENZIONE: oggi UniFi OS Server è il metodo nuovo e consigliato da Ubiquiti per il self-hosting, e sostituisce il vecchio UniFi Network Server. Su Linux, Ubiquiti richiede Ubuntu 23.04+ e usa Podman + slirp4netns per l’installazione. L’ultima release che risulta disponibile è UniFi OS Server 5.0.6 for Linux (x64).

PREREQUISITI

Ubiquiti indica la seguente configurazione per Linux:

• Ubuntu 23.04 o superiore
• CPU x86-64
• almeno 2 GB RAM
• almeno 10 GB liberi
• podman 4.3.1+ e slirp4netns 1.2+

AGGIORNAMENTO DEL SISTEMA

sudo apt update
sudo apt full-upgrade -y
sudo reboot

Dopo il riavvio rientrare via terminale/SSH.

INSTALLAZIONE DI PODMAN E SLIRP4NETNS

Questo è il passaggio ufficiale richiesto da Ubiquiti per Linux.

sudo apt-get update
sudo apt-get install -y podman slirp4netns

Controllare le versioni installate con i seguenti comandi:

podman --version

Dovremmo visualizzare un output simile al seguente:

podman version 4.9.3

Quindi eseguire il comando:

slirp4netns --version

Dovremmo visualizzare un output simile al seguente:

slirp4netns version 1.2.1
commit: 09e31e92fa3d2a1d3ca261adaeb012c8d75a8194
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.5

DOWNLOAD DELL’INSTALLAER DI UNIFI OS SERVER

Ubiquiti indica di prendere il link diretto del file Linux x64 dalla pagina download o dalle release, poi scaricarlo con curl o wget, renderlo eseguibile ed eseguirlo.

Apri la pagina download di UniFi OS Server e copia il link dell’ultima release Linux (x64) disponbile.

https://ui.com/download/software/unifi-os-server

NOTA BENE: al momento della stesura del seguente articolo l’ultima versione disponibile è la UniFi OS Server 5.0.6 for Linux (x64)

Sul server Ubuntu eseguire i comandi di seguito risporati sostituendo l’URL con quello copiato:

cd /tmp
wget "https://fw-download.ubnt.com/data/unifi-os-server/1856-linux-x64-5.0.6-33f4990f-6c68-4e72-9d9c-477496c22450.6-x64"

Controllare il nome del file scaricato con il comando:

ls -lh

Dovremmo trovare il seguente file:

1856-linux-x64-5.0.6-33f4990f-6c68-4e72-9d9c-477496c22450.6-x64

RENDERE IL FILE ESEGUIBILE E AVVIARE L’INSTALLAZIONE

Eseguire il comando:

chmod +x 1856-linux-x64-5.0.6-33f4990f-6c68-4e72-9d9c-477496c22450.6-x64

Quindi avviare l’installazione con il comando:

sudo ./1856-linux-x64-5.0.6-33f4990f-6c68-4e72-9d9c-477496c22450.6-x64

Alla domanda:

You are about to install UOS Server version 5.0.6. Proceed? (y/N):

Premere Y

Se è andato tutto a buon fine dovremmo visualizzare il seguente output:

INFO Installing UOS Server 5.0.6...
INFO Checking compatible podman runtime available...
INFO Checking disk space for required directories...
INFO - /home/: Requires 15.00 GB, available 28.17 GB
INFO - /var/lib/uosserver/: Requires 1.00 GB, available 28.17 GB
INFO - /usr/local/bin/: Requires 0.12 GB, available 28.17 GB
INFO - /tmp/: Requires 2.00 GB, available 28.17 GB
INFO - /var/tmp/: Requires 2.00 GB, available 28.17 GB
INFO All disk space requirements met.
INFO Checking ports...
INFO Adding uosserver user and group...
INFO Adding user 'root' to 'uosserver' group...
INFO Creating /var/lib/uosserver dir...
INFO Creating /var/lib/uosserver/logs dir...
INFO Creating /var/lib/uosserver/bin dir...
INFO Creating /home/uosserver/tmp dir...
INFO Setting up /usr/local/bin/uosserver binary...
INFO Setting up /usr/local/bin/uosserver-purge binary...
INFO Setting up /var/lib/uosserver/bin/discovery binary...
INFO Setting up /var/lib/uosserver/bin/pasta binary...
INFO Setting up /var/lib/uosserver/bin/uosserver-service service binary...
INFO Setting up /var/lib/uosserver/bin/updater-service binary...
INFO Initializing podman conf...
INFO Allowing raw socket execution...
INFO Creating file /var/lib/uosserver/server.conf...
INFO Config set UOS_UUID=8ad0470d-bf8d-595f-85a4-6adaac647f51
INFO Config set CONTAINER_VERSION=0.0.54
INFO Config set UOS_SERVER_VERSION=5.0.6
INFO Config set NETWORK_MODE=pasta
INFO Creating systemd services...
INFO Loading container image...
INFO [podman] Getting image source signatures
INFO [podman] Copying blob sha256:b7fe3d1983242adf9765bc16155a1dc9d621b7e54d32060f806fc121a65fd637
INFO [podman] Copying blob sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1
INFO [podman] Copying blob sha256:632a1a8daa7590599cc733470c6fa2cf39735430febf72016f33ed37a943e237
INFO [podman] Copying blob sha256:cf4be161aa1de3cf14fa15d9611898552c9cc01c18563acb37324d19077afbd6
INFO [podman] Copying blob sha256:9dedd62b9228b7f8a7c95677425772d778033ce15f979d2b08ec9e95d71eac10
INFO [podman] Copying blob sha256:0fb3170f3e0f99ca912f8d5768fedfac1b8ce6c99ce530eb38885cf3dd36961e
INFO [podman] Copying blob sha256:f7604bf526f0462afa853691be9d2e087358a1331bfa1a8e7f442c9350ac1fb9
INFO [podman] Copying blob sha256:41c4718d584d57ba2f4060f80b2afc40ddd79869da751ca66435acbf2fd32035
INFO [podman] Copying config sha256:0faf0b7f0e4ebcbbae964ab0876fab00e47c166d67e649daa4143f7c53e62977
INFO [podman] Writing manifest to image destination
INFO [podman] Loaded image: docker.io/library/uosserver:0.0.54
INFO Config set CONTAINER_IMAGE_NAME=docker.io/library/uosserver:0.0.54
INFO Starting container...
INFO 6972ac2043407a0ab6d699d312ad3a4f219e4f0078fa4610d7e866b39f72ab74
INFO run --detach --pids-limit 65536 --systemd=always --cap-add=NET_RAW --cap-add=NET_ADMIN --name uosserver --restart unless-stopped --health-cmd curl --fail http://127.0.0.1/api/ping || exit 1 --health-interval 60s --health-timeout 5s --health-retries 3 --network pasta:--ns-ifname,eth0,--map-host-loopback,203.0.113.113,--dns-forward,203.0.113.113 --add-host host.docker.internal:203.0.113.113 --add-host host.containers.internal:203.0.113.113 --dns 203.0.113.113 -e UOS_UUID=8ad0470d-bf8d-595f-85a4-6adaac647f51 -e UOS_SERVER_VERSION=5.0.6 -e FIRMWARE_PLATFORM=linux-x64 -v uosserver_persistent:/persistent -v uosserver_var_log:/var/log -v uosserver_data:/data -v uosserver_srv:/srv -v uosserver_var_lib_unifi:/var/lib/unifi -v uosserver_var_lib_mongodb:/var/lib/mongodb -v uosserver_etc_rabbitmq_ssl:/etc/rabbitmq/ssl -p 11443:443 -p 5005:5005 -p 9543:9543 -p 6789:6789 -p 8080:8080 -p 8443:8443 -p 8444:8444 -p 3478:3478/udp -p 5514:5514/udp -p 10003:10003/udp -p 11084:11084 -p 5671:5671 -p 8880:8880 -p 8881:8881 -p 8882:8882 docker.io/library/uosserver:0.0.54
INFO Config set CONTAINER_ARG_HASH=6972ac2043407a0ab6d699d312ad3a4f219e4f0078fa4610d7e866b39f72ab747689b15fbc14594ed82584a1393c33c78b2ab638c1cf7c0648f8cfb901c18913
INFO Waiting for container 'uosserver' to start (timeout: 60s)
INFO Container 'uosserver' is running. (elapsed: 0.0s)
INFO Waiting for systemd to be ready (timeout: 60s)
INFO Systemd is ready. (elapsed: 7.8s)
INFO Starting uosserver systemd service...
INFO Waiting for UOS Server to start...
WARN Timeout: Unifi-core did not start within 60 seconds.
WARN
!!! INSTALLATION COMPLETE !!!
To grant permission for a user to run 'uosserver' commands:
-> Add the user to the 'uosserver' group:
usermod -aG uosserver <username>
-> Then log out and log back in for the changes to take effect.
To get started with available commands, run:
uosserver help

WARNING: UOS Server startup timed out after 60 seconds. On low-powered devices, the web interface can take a few minutes to be accessible. Try opening it at: 192.168.1.120:11443

CONTROLLARE CHE IL SERVIZIO SIA ATTIVO

Ubiquiti indica che il servizio systemd si chiama uosserver.

Verificare lo stato con il comando:

systemctl status uosserver --no-pager

Se è tutto OK dovremmo un output simile al seguente:

● uosserver.service - Unifi OS Service
Loaded: loaded (/etc/systemd/system/uosserver.service; enabled; preset: enabled)
Active: active (running) since Sun 2026-03-22 13:23:30 UTC; 2min 39s ago
Main PID: 3096 (uosserver-servi)
Tasks: 8 (limit: 2262)
Memory: 8.0M (peak: 19.7M swap: 3.2M swap peak: 3.2M)
CPU: 3.866s
CGroup: /system.slice/uosserver.service
├─3096 /var/lib/uosserver/bin/uosserver-service
└─3111 /var/lib/uosserver/bin/discovery

Per abilitarlo all’avvio eseguire il comando:

sudo systemctl enable uosserver

Per riavviare il servizio eseguire il comando:

sudo systemctl restart uosserver

Per fermarlo/avviarlo manualmente eseguire i comandi:

sudo systemctl stop uosserver
sudo systemctl start uosserver

ACCESSO DA INTERFACCIA WEB

Per il login locale ai self-hosted Network Server, Ubiquiti indica la porta 11443.

Apri da un qualsiasi browser il seguente link:

https://IP_DEL_SERVER:11443

Accettare l’eventuale avviso del certificato e completare il wizard.

RIMOZIONE DI UNIFI OS SERVER

Di seguito una sequenza completa per rimuovere i residui di UniFi OS Server, compresi servizio, processi, container, binari, utente e gruppo uosserver.

Eseguire tutti i comandi come root oppure con sudo.

sudo systemctl stop uosserver 2>/dev/null || true
sudo systemctl disable uosserver 2>/dev/null || true
sudo pkill -f uosserver || true
sudo pkill -u uosserver 2>/dev/null || true

podman rm -f $(podman ps -aq) 2>/dev/null || true
podman image prune -a -f 2>/dev/null || true

sudo rm -f /usr/local/bin/uosserver
sudo rm -f /etc/systemd/system/uosserver.service
sudo systemctl daemon-reload

sudo rm -rf /var/log/uosserver
sudo rm -rf /var/lib/uosserver
sudo rm -rf /opt/uosserver
sudo rm -rf /usr/local/share/uosserver
sudo rm -rf /home/uosserver

sudo userdel -r uosserver 2>/dev/null || sudo userdel uosserver 2>/dev/null || true
sudo groupdel uosserver 2>/dev/null || true

sudo cp /etc/passwd /etc/passwd.bak
sudo cp /etc/shadow /etc/shadow.bak
sudo cp /etc/group /etc/group.bak
sudo cp /etc/gshadow /etc/gshadow.bak

sudo sed -i '/^uosserver:/d' /etc/passwd
sudo sed -i '/^uosserver:/d' /etc/shadow
sudo sed -i '/^uosserver:/d' /etc/group
sudo sed -i '/^uosserver:/d' /etc/gshadow

getent passwd uosserver
getent group uosserver
id uosserver
grep '^uosserver:' /etc/passwd /etc/shadow /etc/group /etc/gshadow

Al termine dell’esecuzione dei comandi se è andato tutto a buon fine dovremmo visualizzare il seguente output:

nessun output per getent

Negli ultimi anni l’automazione dell’infrastruttura è diventata un elemento fondamentale per semplificare la gestione degli ambienti IT, migliorare la coerenza delle configurazioni e ridurre i tempi operativi.

In questo contesto AWX la versione open source di Ansible Tower rappresenta una soluzione particolarmente interessante per centralizzare playbook, job template, credenziali e workflow di automazione attraverso un’interfaccia web intuitiva.

Allo stesso tempo l’adozione di distribuzioni Kubernetes leggere come K3S ha reso possibile eseguire workload containerizzati anche in ambienti più snelli, di laboratorio o edge, senza rinunciare ai vantaggi dell’orchestrazione.

Se a questo aggiungiamo Rancher, otteniamo un livello ulteriore di semplificazione nella gestione del cluster grazie a una console centralizzata e a strumenti pratici per il deployment e il monitoraggio delle applicazioni.

In questo articolo vedremo come eseguire l’installazione di AWX su K3S utilizzando Rancher analizzando i prerequisiti, i componenti necessari e i passaggi principali per arrivare a una piattaforma di automazione funzionante, moderna e facilmente amministrabile.

L’obiettivo è costruire un ambiente solido e replicabile utile sia per test che per scenari più strutturati.

PREREQUISITI

Un server Ubuntu 24.04 con queste caratterstiche:

• almeno 4 vCPU / 8 GB RAM come minimo pratico;
• meglio 8 vCPU / 16 GB RAM se vuoi usare Rancher + AWX senza sofferenze

un FQDN

porte aperte: 22, 80, 443

un utente con privilegi di sudo

Per Rancher su K3s conviene scegliere una versione Kubernetes supportata.

La matrice Rancher corrente indica supporto per K3s da v1.32 a v1.34, quindi in questa guida fisserò una release K3s v1.32.x per stare in zona sicura.

AGGIORNAMENTO DI UBUNTU E INSTALLAZIONE DEGLI STRUMENTI BASE

Aggiornare Ubuntu con i seguenti comandi:

sudo apt update && sudo apt -y upgrade
sudo apt -y install curl wget git vim jq apt-transport-https ca-certificates gnupg lsb-release

Controllare l’IP del server con il comando:

hostname -I

Supponiamo che l’IP sia 192.168.1.50.

Per il laboratorio puoi usare questi hostnames:

rancher.test.lab – 192.168.1.50

awx.test.lab – 192.168.1.50

INSTALLAZIONE DI K3S

Rancher documenta l’installazione di K3s con cluster-init anche su singolo nodo, così mantieni una via semplice verso una futura migrazione HA.

K3s installa anche i link a kubectl di default se non già presenti nel PATH.

Installare K3s fissando una release supportata con il comando:

curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="v1.32.6+k3s1" sh -s - server --cluster-init

Verificare che tutto sia ok con i seguenti comandi:

sudo systemctl status k3s --no-pager
sudo kubectl get nodes -o wide
sudo kubectl get pods -A

Configurare il kubeconfig per il tuo utente con i seguenti comandi:

mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $USER:$USER ~/.kube/config
export KUBECONFIG=~/.kube/config
echo 'export KUBECONFIG=~/.kube/config' >> ~/.bashrc

Verificare i nodi con il comando:

kubectl get nodes

Dovremmo visualizzare un output simile al seguente:

NAME STATUS ROLES AGE VERSION
vm-srv-ubu-awx Ready control-plane,etcd,master 76s v1.32.6+k3s1

CONTROLLO DI TRAEFIK E DELLO STORAGE CLASS

K3s include di default l’ingress controller. Per Rancher non serve installarne uno extra su K3s.

Verificare che Traefik sia presente con i comandi:

kubectl get pods -n kube-system | grep traefik
kubectl get svc -n kube-system

Verificare lo storage class di default con il comando:

kubectl get storageclass

Su K3s normalmente trovi local-path come default sufficiente per una AWX con database interno in ambiente lab.

INSTALLAZIONE DI HELM

Rancher richiede Helm 3.

Eseguire i comandi per installare Helm:

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod +x get_helm.sh
sudo ./get_helm.sh
helm version

Dovremmo visualizzare il seguente output:

version.BuildInfo{Version:"v3.20.0", GitCommit:"b2e4314fa0f229a1de7b4c981273f61d69ee5a59", GitTreeState:"clean", GoVersion:"go1.25.6"}

INSTALLAZIONE DI CERT-MANAGER

La documentazione cert-manager raccomanda l’installazione via chart Helm/OCI e con crds.enabled=true.

La release indicata nella documentazione corrente è v1.19.4.

Eseguire i comandi:

helm install cert-manager oci://quay.io/jetstack/charts/cert-manager \
--version v1.19.4 \
--namespace cert-manager \
--create-namespace \
--set crds.enabled=true

Aspettare che sia pronto quindi eseguire i comandi:

kubectl rollout status deployment -n cert-manager cert-manager
kubectl rollout status deployment -n cert-manager cert-manager-webhook
kubectl rollout status deployment -n cert-manager cert-manager-cainjector
kubectl get pods -n cert-manager

INSTALLAZIONE DI RANCHER

Rancher si installa via Helm nel namespace cattle-system esposto tramite Ingress HTTPS.

Il chart supporta opzioni come bootstrapPassword, hostname e ingress.tls.source.

Aggiungere il repository e creare il namespace con i seguenti comandi:

helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
helm repo update
kubectl create namespace cattle-system

Opzione più semplice per lab: certificato generato da Rancher

Usa ingress.tls.source=rancher che è il default del chart Rancher. Il chart supporta anche bootstrapPassword.

Eseguire i comandi:

helm upgrade --install rancher rancher-latest/rancher \
--namespace cattle-system \
--set hostname=rancher.192.168.1.50.sslip.io \
--set bootstrapPassword='AdminTemp!2026' \
--set replicas=1

Dovremmo visualizzare il seguente output:

Rancher Server has been installed. Rancher may take several minutes to fully initialize.

Please standby while Certificates are being issued, Containers are started and the Ingress rule comes up.

Check out our docs at https://rancher.com/docs/

## First Time Login

If you provided your own bootstrap password during installation, browse to https://rancher.mypsx.net to get started.
If this is the first time you installed Rancher, get started by running this command and clicking the URL it generates:

```
echo https://rancher.mypsx.net/dashboard/?setup=$(kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}')
```

To get just the bootstrap password on its own, run:

```
kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}{{ "\n" }}'
```

Happy Containering!

A questo punto eseguire il rollout con i seguenti comandi:

kubectl rollout status deployment -n cattle-system rancher
kubectl get pods -n cattle-system
kubectl get ingress -n cattle-system

Controllare l’URL di bootstrap con il comando:

echo "https://rancher.192.168.1.50.test.lab/dashboard/?setup=$(kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}')"

Aprire l’URL nel browser. Al primo accesso accettare il certificato self-signed quindi inserire la password

Cliccare su Login with Local User

Inserire l’URL del server corretto

Rancher richiede HTTPS e la sua documentazione mostra hostname come parametro fondamentale del chart.

Cliccare Continue

Se tutto è andato bene dovremmo visualizzare la Dashboard del Rancher

Quando si accede in Rancher la prima cosa che si vede è il cluster locale.

Questo cluster può ospitare anche AWX.

Per un lab va bene usare il local cluster.

In produzione di solito si separa il cluster di management da quello dei workload.

INSTALLAZIONE DI AWX OPERATOR

L’AWX Operator si installa nel cluster e gestisce il ciclo di vita di AWX nello stesso namespace.

L’installazione ufficiale base usa Kustomize con una kustomization.yaml che punta al tag dell’operator.

Creare il namespace con il comando:

kubectl create namespace awx

Creare una cartella di lavoro con il comando:

mkdir -p ~/awx-operator-install
cd ~/awx-operator-install

Creare kustomization.yaml con il comando:

NOTA BENE: Consiglio di usare un tag esplicito invece del branch devel. La doc ufficiale mostra proprio questo schema con github.com/ansible/awx-operator/config/default?ref=<tag>.

cat > kustomization.yaml <<'EOF'
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- github.com/ansible/awx-operator/config/default?ref=2.7.2

images:
- name: quay.io/ansible/awx-operator
newTag: 2.7.2

namespace: awx
EOF

Applicare con il comando:

kubectl apply -k .

Verificare con i seguenti comandi:

kubectl get pods -n awx
kubectl get deployments -n awx
kubectl get crd | grep awx

Dovremmo vedere il seguente output:

kubectl get pods -n awx
kubectl get deployments -n awx
kubectl get crd | grep awx
NAME READY STATUS RESTARTS AGE
awx-operator-controller-manager-59669d4d4-6wcck 0/2 ErrImagePull 0 20s
NAME READY UP-TO-DATE AVAILABLE AGE
awx-operator-controller-manager 0/1 1 0 20s
awxbackups.awx.ansible.com 2026-03-08T16:54:22Z
awxrestores.awx.ansible.com 2026-03-08T16:54:22Z
awxs.awx.ansible.com 2026-03-08T16:54:22Z
root@vm-srv-ubu-awx:~/awx-operator-install# kubectl get pods -n awx
NAME READY STATUS RESTARTS AGE
awx-operator-controller-manager-59669d4d4-6wcck 1/2 ImagePullBackOff 0 36s
root@vm-srv-ubu-awx:~/awx-operator-install# kubectl get deployments -n awx
NAME READY UP-TO-DATE AVAILABLE AGE
awx-operator-controller-manager 0/1 1 0 44s
root@vm-srv-ubu-awx:~/awx-operator-install# kubectl get crd | grep awx
awxbackups.awx.ansible.com 2026-03-08T16:54:22Z
awxrestores.awx.ansible.com 2026-03-08T16:54:22Z
awxs.awx.ansible.com 2026-03-08T16:54:22Z

CREAZIONE DI AWX

L’operator supporta servizi ClusterIP, LoadBalancer e NodePort; per ingress di default non crea nulla finché non imposti ingress_type.

Supporta ingress_type: ingress e campi come ingress_class_name, ingress_hosts, ingress_annotations.

Di seguito riporto una configurazione pulita con:

• service interno ClusterIP
• Ingress gestito da Traefik
• hostname dedicato
• storage class local-path
• admin password predefinita in Secret
• Crea la password admin

La documentazione AWX chiarisce che admin_password_secret deve essere un Secret Kubernetes; se non lo si passa, l’operator genera <resourcename>-admin-password.

Eseguire il comando:

cat > awx-admin-secret.yaml <<'EOF'
apiVersion: v1
kind: Secret
metadata:
name: awx-admin-password
namespace: awx
stringData:
password: "AwxAdmin!2026"
EOF

Applicare con il comando:

kubectl apply -f awx-admin-secret.yaml

Creare il manifest di AWX con il comando:

cat > awx.yaml <<'EOF'
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
name: awx
namespace: awx
spec:
admin_user: admin
admin_email: admin@example.local
admin_password_secret: awx-admin-password

service_type: ClusterIP

ingress_type: ingress
ingress_class_name: traefik
ingress_annotations: |
kubernetes.io/ingress.class: traefik
ingress_hosts:
- hostname: awx.mypsx.net

projects_persistence: true
projects_storage_class: local-path
projects_storage_size: 5Gi

postgres_storage_class: local-path
postgres_storage_requirements:
requests:
storage: 8Gi

web_resource_requirements:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 1
memory: 2Gi

task_resource_requirements:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 1
memory: 2Gi
EOF

Applicare con il comando:

kubectl apply -f awx.yaml

Controllare l’avanzamento con il comando:

kubectl get pods -n awx -w

Quando i pod sono pronti eseguire i comandi:

kubectl get awx -n awx
kubectl get svc -n awx
kubectl get ingress -n awx
kubectl get pvc -n awx

RECUPERARE LA PASSWORD DI AWX

Se hai usato il Secret che ti ho fatto creare in precedenza la password è già quella impostata.

In ogni caso la doc ufficiale AWX indica che la password è leggibile dal secret <resourcename>-admin-password.

Nel nostro caso eseguire il comando:

kubectl get secret awx-admin-password -n awx -o jsonpath="{.data.password}" | base64 --decode ; echo

Aprire quindi il seguente link da qun qualsiasi browser:

http://awx.mypsx.net

oppure se il tuo ingress forza HTTPS in base alla configurazione del controller/certificato aprire il seguente link:

https://awx.mypsx.net

Se è tutto corretto dovremmo visualizzare la pagina di accesso di AWX

AWX NON RISPONDE SUBITO: COSA FARE?

Controlli rapidi da eseguire:

kubectl describe awx awx -n awx
kubectl logs -n awx deployment/awx-operator-controller-manager
kubectl get events -n awx --sort-by=.metadata.creationTimestamp
kubectl describe ingress -n awx
kubectl describe pvc -n awx

I problemi più comuni sono questi:

hostname non risolto: verifica ping awx.test.lab

pod postgres in errore: quasi sempre storage/PVC

Ingress creato ma la pagina non si apre: verificare che Traefik sia attivo in kube-system

AWX ancora Progressing: aspettare qualche minuto, il primo deploy scarica molte immagini e ci va tempo

AGGIORNAMENTI FUTURI

K3s: usa una versione supportata dalla matrice Rancher prima di aggiornare Rancher o Kubernetes.

cert-manager: aggiornalo con Helm, mantenendo una release supportata.

AWX Operator: usa tag espliciti e non devel in produzione/lab stabile. La doc base dell’operator è proprio costruita attorno al concetto di tag/versione.

In questa guida vedremo come installare e configurare un Server AI completo e replicabile basato su Ubuntu 24.04 LTS e hardware Intel N100, ottimizzato per ambienti domestici o piccoli laboratori IT.

ARCHITETTURA E PREREQUISITI

L’infrastruttura prevede:

Ollama per l’esecuzione dei modelli LLM locali
Open-WebUI come interfaccia web moderna stile ChatGPT
Agent AI (RAG Server) per estendere le funzionalità con documenti, embedding e automazioni
Nginx con HTTPS per un accesso sicuro
Ottimizzazioni CPU, RAM (zram), LVM e hardening di base
La guida è completamente replicabile, strutturata passo-passo e pensata per ottenere un sistema:
Performante anche su hardware a basso consumo e Sicuro (zero porte AI esposte)

Pronto per utilizzo personale o laboratorio professionale

Al termine avrai un’infrastruttura AI locale stabile, organizzata e pronta per essere integrata nella tua rete (anche su VLAN dedicata).

Base: Ubuntu 24.04 LTS minimal
Hardware: Intel N100 – 16/32GB RAM – NVMe

INSTALLAZIONE DEL SISTEMA BASE

Aggiornamento sistema

sudo apt update
sudo apt upgrade -y
sudo apt autoremove -y

OTTIMIZZAZIONE N100

Governor performance

sudo apt install cpufrequtils -y
echo 'GOVERNOR="performance"' | sudo tee /etc/default/cpufrequtils
sudo systemctl restart cpufrequtils

ZRAM

sudo apt install zram-tools -y
sudo nano /etc/default/zramswap

Impostare la percentuale della memoria adeguata (es 50%)

sudo systemctl restart zramswap

INSTALLAZIONE DOCKER

sudo apt install docker.io -y
sudo systemctl enable docker
sudo systemctl start docker
sudo usermod -aG docker $USER
newgrp docker

INSTALLAZIONE OLLAMA

curl -fsSL https://ollama.com/install.sh | sh

Procedere con l’Hardening Ollama:

sudo systemctl edit ollama

Inserire il seguente output:

ini
[Service]
Environment="OLLAMA_NO_CLOUD=true"
Environment="OLLAMA_HOST=127.0.0.1"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_QUEUE=8"
Environment="OLLAMA_KEEP_ALIVE=5m"

Poi:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Scaricare i modelli consigliati

ollama pull phi3
ollama pull mistral
ollama pull deepseek-coder:6.7b-instruct-q4_K_M
ollama pull nomic-embed-text

INSTALLAZIONE OPEN-WEBUI

Creare una cartella persistente con i seguenti comandi:

sudo mkdir -p /data-ai/openwebui
sudo chown -R $USER:$USER /data-ai

Avviare il container sicuro con il comando:

docker run -d --name open-webui -p 127.0.0.1:3000:8080 -e OLLAMA_BASE_URL=http://127.0.0.1:11434 -e CORS_ALLOW_ORIGIN=https://ai.local -v /data-ai/openwebui:/app/backend/data --restart always ghcr.io/open-webui/open-webui:main

INSTALLAZIONE DI NGINX PER HTTPS

sudo apt install nginx -y
sudo mkdir -p /etc/nginx/ssl

Generare un certificato self-signed con i seguenti comandi:

sudo openssl req -x509 -nodes -days 3650 -newkey rsa:4096 \
-keyout /etc/nginx/ssl/ai.key \
-out /etc/nginx/ssl/ai.crt

Procedere con la configurazione del vhost:

sudo nano /etc/nginx/sites-available/ai

Contenuto completo da copiare all’interno del file di configurazione:

nginx
server {
listen 80;
server_name ai.local;
return 301 https://$host$request_uri;
}

server {
listen 443 ssl;
server_name ai.local;

ssl_certificate /etc/nginx/ssl/ai.crt;
ssl_certificate_key /etc/nginx/ssl/ai.key;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;
add_header X-XSS-Protection "1; mode=block";
server_tokens off;

location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}

Attivare il sito con i comandi:

sudo ln -s /etc/nginx/sites-available/ai /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

FIREWALL BASE

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 443/tcp
sudo ufw allow from 192.168.3.0/24 to any port 22
sudo ufw enable

VERIFICA FINALE

ss -tulnp

Deve risultare:

0.0.0.0:443
0.0.0.0:80
0.0.0.0:22
127.0.0.1:3000
127.0.0.1:11434

BACKUP CONFIGURAZIONE

sudo mkdir -p /data-ai/backups

sudo tar -czf /data-ai/backups/ai_stack_backup_$(date +%F).tar.gz /etc/nginx /etc/systemd/system/ollama.service.d /data-ai /home/$USER/.ollama

Negli ultimi anni l’infrastruttura iperconvergente (HCI) è diventata uno standard di riferimento per chi desidera ambienti IT più semplici, scalabili e performanti.

Tra le soluzioni più interessanti in questo ambito troviamo Nutanix Community Edition (CE) 2.1, la versione gratuita pensata per laboratori, test e ambienti di apprendimento.

Installare Nutanix CE su VMware ESXi 8 rappresenta un’ottima opportunità per sperimentare concretamente le funzionalità della piattaforma Nutanix senza dover disporre di hardware dedicato.

Grazie alla virtualizzazione nested, è possibile creare un laboratorio completo direttamente sopra ESXi, ideale per amministratori di sistema, consulenti IT e appassionati che vogliono approfondire il funzionamento di AOS, Prism e dei principali componenti dell’ecosistema Nutanix.

In questo articolo vedremo passo dopo passo come installare e configurare correttamente Nutanix Community Edition 2.1 su VMware ESXi 8, partendo dai prerequisiti fino alla prima configurazione base del cluster, con suggerimenti pratici per evitare gli errori più comuni e ottenere un ambiente stabile e funzionante sin dal primo avvio.

PREREQUISITI

I requisiti per Nutanix CE sono:

Minimo 32GB di memoria
Minimo 4 core CPU
Minimo 64GB di Boot Disk
Minimo 200GB di disco Hot Tier
Minimo 500GB di disco cold Tier

Download della ISO Nutanix Community Edition al seguente link:

Download Nutanix Community Edition

ATTENZIONE: per scaricare la ISO è necessaria la registrazione con una mail aziendale

CREAZIONE E CONFIGURAZIONE DELLA VM SU VSPHERE

Accedere al vCenter o all’host ESXi singolo quindi selezionare New Virtual Machine

Selezionare l’opzione Create a new virtual machine quindi cliccare Next

Inserire il nome della VM, scegliere la location quindi cliccare Next

Selezionare l’Host quindi cliccare Next

Selezionare il Datastore quindi cliccare Next

Selezionare la compatibilità quindi cliccare Next

Configurare i seguenti parametri come di seguito:

Guest OS Family: Linux

Guest OS Version: CentOS 7 (64-bit)

Cliccare Next

Impostare l’Hardware della VM come da Prerequisiti quindi agganciare la ISO di Nutanix CE. Cliccare Next

ATTENZIONE: dato che è un installazione Nested è indispensabile attivare l’opzione relativa alla CPU Expose hardware assisted virtualization to the guest OS

Selezionare l’opzione CPU Expose hardware assisted virtualization to the guest OS quindi cliccare OK

Leggere il riepilogo quindi cliccare Finish per terminare la creazione della VM

Selezionare l’Host dove abbiamo creato la Vm quindi vSwitch → Security → Edit

Sul Virtual Switch dove è collegata la VM è necessario abilitare:

Promiscuous Mode → Accept

MAC Address Changes → Accept

Forged Transmits → Accept

Al termine avviare la VM

INSTALLAZIONE DI NUTANIX

Dopo aver avviato la VM attendere la schermata di configurazione

In questa fase è indispensabile definire:

• Disk Selection: il disco dove andremo ad installare Nutanix
• Host IP Address: AHV (Acropolis Hypervisor) è l’hypervisor di Nutanix. Lo si utilizza per l’Accesso SSH all’host, per la Gestione di basso livello e per il Troubleshooting tecnico
• CVM IP Address: CVM (Controller Virtual Machine) è una VM speciale che gira sopra AHV. Il CVM si occupa di:

Storage distribuito (Nutanix Distributed Storage Fabric)

• Replica dati
• Compressione e deduplicazione
• Gestione del cluster
• Servizi di storage per tutte le VM

Quindi cliccare Next Page per proseguire

Accettare l’EULA quindi cliccare Start

ATTENZIONE: scrollare fino in fondo il testo della licenza altrimenti l’installazione andrà in errore

Attendere qualche minuto fino al termine dell’installazione

Rimuovere la ISO dalla VM quindi premre Y per riavviare il server

Poiché non abbiamo specificato i server DNS durante la creazione del cluster, Community Edition configurerà due server DNS di Google.

CONFIGURAZIONE DEL CLUSTER

Accedere in SSH al Controller Virtual Machine (CVM)

Le credenziali di accesso sono:

USER: nutanix

PASSWORD: nutanix/4u

Verificare lo stato del cluster con il comando:

cluster status

Dovremmo visualizzare il seguente output:

863Z CRITICAL MainThread cluster:3241 Cluster is currently unconfigured. Please create the cluster.

Questo messaggio vuol dire che Nutanix CE è installato ma il cluster non è stato ancora creato.

Per creare il cluster eseguire il comando:

cluster -s IP_CVM create

NOTA BENE: al posto di IP_CVM inserire l’IP

A questo punto attendere dai 5 ai 10 minuti fin quando non visualizziamo il seguente output:

The state of the cluster: start
Lockdown mode: Disabled

CVM: 192.168.80.30 Up, ZeusLeader
Xmount UP [67112, 67311, 67312, 67364]
IkatProxy UP [66890, 67063, 67064, 67065]
Zeus UP [62547, 62606, 62607, 62608, 62617, 62635]
Scavenger UP [67121, 67358, 67359, 67360]
SysStatCollector UP [72320, 72450, 72451, 72452]
IkatControlPlane UP [72497, 72632, 72633, 72634]
SSLTerminator UP [72543, 72918, 72919]
SecureFileSync UP [73035, 73425, 73426, 73427]
Medusa UP [76451, 76594, 76595, 76608, 76940]
DynamicRingChanger UP [81714, 81831, 81832, 81878]
Pithos UP [81767, 81980, 81981, 81995]
InsightsDB UP [81861, 82101, 82102, 82117]
Athena UP [82039, 82283, 82284, 82285]
Mercury UP [82109, 82410, 82411, 82427]
Mantle UP [82436, 83305, 83306, 83342]
VipMonitor UP [84502, 84503, 84504, 84505, 84512]
Stargate UP [84708, 84993, 84994, 85053, 85054]
InsightsDataTransfer UP [85983, 86901, 86902, 86924, 86925, 86926, 86927, 86928, 86929]
GoErgon UP [86486, 87087, 87088, 87102]
Cerebro UP [86946, 87182, 87183, 87327]
Chronos UP [87097, 87266, 87267, 87320]
Curator UP [87488, 89412, 89413, 89871]
Prism UP [89195, 90404, 90405, 90544, 91212, 91335]
Hera UP [90080, 91028, 91029, 91030]
AlertManager UP [90500, 91141, 91142, 91261]
Arithmos UP [91407, 91715, 91716, 91752]
Catalog UP [91631, 91862, 91863, 91864, 91880]
Acropolis UP [92300, 93155, 93156, 96895]
Castor UP [93282, 94130, 94131, 94170, 94390]
Uhura UP [93378, 94355, 94356, 95233]
NutanixGuestTools UP [94347, 95269, 95270, 95317, 95468]
MinervaCVM UP [102317, 103168, 103169, 103171]
ClusterConfig UP [102778, 103459, 103460, 103461, 103480]
APLOSEngine UP [103370, 103972, 103973, 103975]
APLOS UP [107523, 108515, 108516, 108517]
PlacementSolver UP [108130, 108742, 108743, 108744, 108761]
Lazan UP [108424, 109136, 109137, 109138]
Polaris UP [109259, 110216, 110217, 110416]
Delphi UP [109699, 110725, 110726, 110727, 110748]
Security UP [110843, 111542, 111543, 111545]
Flow UP [111445, 112690, 112691, 112692, 112708]
Anduril UP [112736, 113445, 113446, 113447, 113481]
Narsil UP [113309, 114179, 114180, 114181]
XTrim UP [113492, 114735, 114736, 114738]
ClusterHealth UP [114066, 115634, 116420, 116423, 116431, 116446, 116603, 116604, 116613, 116619, 116620, 116735, 116736, 116743, 116753, 116754, 116755, 116756, 116757, 116766, 116955, 116956, 117043, 117044, 117133, 117134, 117148, 117149]
2026-02-22 11:31:09,341Z INFO MainThread cluster:1745 Running CE cluster post-create script
2026-02-22 11:31:27,377Z INFO MainThread cluster:3465 Success!

ACCESSO ALLA GUI WEB DI NUTANIX

Il cluster è accessibile da un qualsiasi browser tramite https://<cvm_ip>:9440.

Accedere con le seguente credenziali:

USER: admin

PASSWORD: nutanix/4u

Procedere con il cambio password

Accedere con la nuova password

Inserire le credenziali creare in fase di registrazione al portale Nutanix

Se abbiamo fatto correttamante dovremmo visualizzare la Dashboard di Nutanix come mostrato nell’immagine sovrastante

CONCLUSIONI

L’installazione e la configurazione base di Nutanix Community Edition (CE) 2.1 su VMware ESXi 8 rappresentano un’ottima opportunità per approfondire in modo pratico il funzionamento dell’ecosistema Nutanix senza la necessità di disporre di hardware dedicato.

Attraverso pochi passaggi mirati è possibile creare un ambiente di laboratorio funzionale ideale per test, formazione e sperimentazione.

Abbiamo visto come preparare correttamente la macchina virtuale su ESXi configurare le risorse in modo adeguato e completare la fase di bootstrap del cluster.

Una corretta pianificazione iniziale soprattutto in termini di CPU, RAM e storage è fondamentale per garantire stabilità e performance accettabili, anche in un contesto nested.

Nutanix CE 2.1 consente di esplorare funzionalità chiave come AHV, Prism e la gestione dello storage distribuito, offrendo un’esperienza molto vicina a quella di un ambiente enterprise.

Sebbene non sia pensata per ambienti di produzione rimane uno strumento estremamente potente per chi desidera acquisire competenze concrete sull’infrastruttura iperconvergente.

Il passo successivo? Approfondire funzionalità avanzate come la creazione di macchine virtuali su AHV, la gestione delle reti virtuali, snapshot, replica e integrare il laboratorio con altre tecnologie per simulare scenari reali.

INTRODUZIONE

UEFI E Secure Boot

La tecnologia UEFI ha rimpiazzato da molti anni il BIOS classico e sfrutta la crittografia asimmetrica per validare l’integrità del boot loader prima della sua esecuzione.
Il metodo di validazione si basa su una catena di fiducia (Chain of Trust):

• Il certificato PK (Platform Key), installato dal produttore della scheda madre, rappresenta la radice di fiducia dell’hardware.
• Mediante la PK viene autorizzata la KEK (Key Exchange Key), che identifica i produttori di sistemi operativi autorizzati a modificare i database delle firme.
• La KEK permette di aggiornare i database DB (Authorized Signature) e DBX (Forbidden Signature), che contengono i certificati o gli hash dei boot loader e dei driver effettivamente autorizzati all’avvio.

Microsoft, in quanto leader di mercato dei sistemi operativi per i PC, agisce come Autorità di Certificazione (CA) principale e le sue chiavi sono pre-installate nella quasi totalità dei dispositivi.
Di conseguenza, anche i sistemi Linux dipendono da questa infrastruttura: Microsoft firma digitalmente i componenti shim (piccoli boot loader intermedi), i quali a loro volta gestiscono una lista locale di chiavi chiamata MOK (Machine Owner Key).
Questo sistema a ponte permette alle distribuzioni Linux di aggiornare il proprio kernel senza dover richiedere una nuova firma a Microsoft per ogni rilascio.

Scadenza Microsoft Corporation UEFI CA 2011

Il certificato Microsoft Corporation UEFI CA 2011, utilizzato per oltre un decennio per firmare la quasi totalità dei boot loader e driver UEFI (inclusi quelli Linux), è giunto a fine vita naturale.
La scadenza non implicherà immediatamente il fallimento del boot dei sistemi operativi, poiché finché esso non verrà revocato, aggiungendolo al database DBX, i sistemi già installati potranno comunque avviarsi.
Tuttavia, verrà inibita la possibilità di installazione di nuovi sistemi operativi e non sarà più possibile applicare patch critiche per il boot loader, poiché le nuove versioni (firmate con la CA 2023) verrebbero considerate non attendibili dal firmware non aggiornato.
La sostituzione del vecchio certificato con la nuova CA 2023 non è una semplice operazione software, ma richiede un duplice intervento: l’aggiornamento delle variabili EFI attive (tramite patch del sistema operativo) e l’aggiornamento delle variabili di default (tramite aggiornamento del firmware BIOS/UEFI o caricamento manuale).
Il mancato aggiornamento, oltre alle limitazioni operative descritte, impedisce la revoca del vecchio certificato tramite DBX.
Questo lascia il parco macchine vulnerabile a boot loader compromessi o obsoleti, che possono essere sfruttati da malware di nuova generazione (come BlackLotus) per bypassare integralmente le protezioni del Secure Boot.

AUDITING

Prefazione

Prima di poter procedere con le operazioni correttive è necessario mappare lo stato attuale della propria flotta di dispositivi con Secure Boot attivo.
Tutti i comandi proposti in questo paragrafo necessitano dei diritti amministrativi (root o membro di Administrators) per poter essere eseguiti.
Le modifiche sul portale Microsoft Intune necessitano che l’utente abbia attivo il ruolo di Intune Administrator o di Global Administrator.

Audit dello stato del Secure Boot

Con i seguenti comandi è possibile verificare se il Secure Boot è abilitato e su Windows lo stato della CA 2023:

Audit dello stato del Secure Boot mediante Intune

Microsoft Intune include una funzionalità che analizza i dispositivi gestiti e genera un report dello stato del Secure Boot.
La funzionalità è disponibile solamente se si ha attivato la telemetria sul tenant, per farlo navigare su Tenant administration e poi cliccare su Connectors and tokens:

Selezionare Windows data ed abilitare Enable features that require Windows diagnostic data in processor configuration:

Affinché la modifica venga applicata è possibile che siano necessari fino a tre giorni.
Per visualizzare il report, navigare su Reports e selezionare Window quality update, navigare su Reports e selezionare Secure boot status:

Nella pagina successiva viene mostrato il report:

Mediante il pulsante Export è possibile esportarlo in un file CSV.
L’aggiornamento dello stato dei dispositivi può richiedere diverse ore da quando viene applicato a quando viene mostrato sul portale.

Audit dello stato delle variabili EFI

Di seguito viene riportata una tabella con i comandi necessari a verificare lo stato delle variabili EFI, al fine di evitare regressioni future, è necessario evidenziare la distinzione tra le variabili nello stato Active e quelle nello stato Default:

• Le variabili Active sono salvate nella NVRAM, vengono caricate durante il Secure Boot per essere utilizzate per la validazione del boot loader e possono venir aggiornate dal sistema operativo.
• Le variabili Default sono memorizzate nel chip BIOS/UEFI dal produttore della scheda madre, vengono utilizzate per sovrascrivere le variabili Active durante il ripristino alle impostazioni di fabbrica e per modificarle è necessario l’aggiornamento del firmware o l’upload manuale (dove applicabile).

Audit della firma del boot loader

Successivamente, viene riportata una tabella con i comandi per verificare l’autorità emittente (issuer) che ha firmato il boot loader (o shim) in uso:

Audit della firma dei drivers

Nella seguente tabella sono riportati i comandi per verificare l’autorità emittente (issuer) che ha firmato i drivers installati:

Su Linux generalmente non è necessario verificare che la firma dei drivers sia stata effettuata dalla nuova CA, poiché lo shim funge da intermediario nella catena di fiducia.

PROCEDURE DI RIMEDIO

Prefazione

Le procedure correttive descritte in questo capitolo si concentrano sull’inserimento della nuova CA 2023 in DB e sull’aggiornamento del boot loader.
In base al produttore dell’hardware e a quello del sistema operativo la procedura da applicare varia, si consiglia di procedere inizialmente seguendo i passaggi necessari per l’aggiornamento del firmware (dove applicabile) e successivamente all’applicazione della patch del sistema operativo.
Per i produttori di hardware per cui in questo documento non è stata fornita una procedura specifica è, tipicamente, possibile procedere effettuando l’aggiornamento del BIOS/firmware, oppure manualmente iniettando la CA direttamente in DB o in PK.
L’ultimo step consigliato è quello della revoca della CA 2011 inserendola in DBX, alcuni produttori, come HP, sconsigliano di procedere, poiché hanno implementato altre misure di sicurezza per mitigare i rischi legati ai rootkit come BlackLotus e perciò la procedura non porterebbe benefici reali.

Avvertenze sulla revoca

Le procedure manuali di revoca della CA 2011 rappresentano un’operazione distruttiva e irreversibile per la catena di avvio se eseguite prematuramente.
Non procedere con la revoca finché non è stata verificata l’intera catena di boot (boot loader, kernel, driver UEFI e firmware hardware).
L’applicazione del DBX su sistemi non pronti causerà un Secure Boot Violation, rendendo il sistema incapace di avviarsi.

Aggiornamento delle variabili di default e della firma del firmware

Macchine Virtuali

Proxmox

Le VM su Proxmox supportano il Secure Boot mediante il BIOS chiamato OVMF (UEFI) e l’aggiunta del disco EFI, in cui vengono memorizzare le variabili PK, DB, DBX e KEK attive.
Per una scelta di design del firmware OVMF, le variabili di default non sono disponibili all’interno delle VM, perciò è normale che venga restituito un errore quando si eseguono i rispettivi comandi indicati nella tabella di auditing.
Dalla versione 8.2 di Proxmox VE è stata introdotta una nuova funzionalità che consente agli amministratori di iniettare la nuova CA nelle variabili memorizzate nel disco EFI delle VM direttamente dalla Web UI.
Selezionare la VM da modificare, navigare nel menù Hardware, cliccare sul disco EFI e successivamente su Disk Action, nel menù a tendina che viene aperto è possibile selezionare Enroll Updated Certificates:

Si dovrebbe aprire una finestra di dialogo che avverte che la modifica delle variabili EFI potrebbe causare la finestra di ripristino BitLocker all’avvio successivo e che consiglia un comando da eseguire su PowerShell:

In realtà, il problema non è limitato al BitLocker, poiché qualsiasi strumento di sblocco automatico di partizioni cifrate mediante PCR 7 e TPM viene impattato (es. LUKS con systemd-cryptenroll) e perciò è necessario procedere con cautela.
Su alcune VM con BitLocker attivo potrebbe non essere richiesto effettuare questa operazione poiché lo sblocco mediante BitLocker utilizza dei profili di validazione diversi (es. PCR 0,2,4,11) che non includono
lo stato del database delle firme (PCR 7), ma per cautela si consiglia di procedere comunque.
Su Windows è possibile eseguire il seguente comando:

Suspend-BitLocker -MountPoint "C:" -RebootCount 1

A differenza del commando proposto da Proxmox, questo impatta solo il primo riavvio.
Su Linux non esiste un comando che sospende la protezione perciò è necessario rimuovere lo slot dal TPM, riavviare la VM e ricrearlo.
Per rimuoverlo, se si utilizza systemd-cryptenroll, è possibile eseguire il seguente comando (sostituire sda3 con la partizione cifrata):

systemd-cryptenroll --wipe-slot=tpm2 /dev/sda3

Sia su Windows che su Linux è fortemente consigliato effettuare il backup della chiave di ripristino BitLocker/LUKS prima di procedere e di non far affidamento solamente al TPM.

VMware 7 e precedenti

Su VMware 7 e precedenti non è disponibile la versione di virtual hardware necessaria per l’aggiornamento automatico delle variabili EFI.
A causa di questa limitazione si consiglia di procedere all’aggiornamento mediante la procedura specifica per il sistema operativo della macchina guest e di inserire una nota affinché nessuno effettui il reset delle variabili EFI dal BIOS della VM.
Se per qualche necessità specifica non fosse possibile procedere mediante patch del sistema operativo, Broadcom fornisce una procedura che permette di sostituire la PK della VM, permettendo quindi di iniettare la CA 2023.
La procedura prevede la creazione di un disco aggiuntivo, formattato in FAT32, in cui copiare la PK, in formato DER, scaricata dal repository ufficiale.
Al riavvio successivo, mediante la modifica di un parametro della VM, è possibile registrare la chiave.
KB di Broadcom: https://knowledge.broadcom.com/external/article/423919/manual-update-of-secure-boot-variables-i.html
Come per VMware 8 e successivi, è possibile aggiornare i VMware Tools alla versione 12.4 o superiore per garantire che i drivers siano firmati dalla nuova CA.

VMware 8 e successivi

Su VMware 8 e successivi è sufficiente aggiornare il virtual hardware per inserire tra le variabili EFI la nuova CA.
La versione hardware minima richiesta è la 21 che è stata introdotta con vSphere 8.0 Update 2:

Per far sì che anche i drivers vengano aggiornati, è necessario aggiornare i VMware Tools alla versione 12.4 o superiore, mediante il pacchetto ufficiale su Windows o il pacchetto open-vm-tools su Linux e BSD.

Macchine fisiche

PC

Prefazione

I produttori principali di PC hanno lavorato insieme a Microsoft per rendere la transizione alla nuova catena di fiducia il più trasparente possibile.
Nella maggior parte dei casi l’aggiornamento del BIOS, svolto manualmente o mediante la funzionalità Enterprise di Intune per l’aggiornamento del firmware, è sufficiente per aggiornare le variabili EFI di default, senza bisogno di disabilitare il BitLocker.

Dell

I PC Dell rilasciati dopo il 1° Gennaio 2026 includono già la nuova CA nelle variabili EFI, per quelli precedenti è necessario verificare sul sito del produttore se la versione del BIOS che si sta utilizzando è sufficientemente aggiornata.
Per effettuare questa verifica è possibile proseguire come segue:

• Navigare sul sito www.dell.com/support ed inserire il modello del proprio computer
• Navigare nella sezione “Driver e download” e scegliere BIOS come categoria
• Cliccare sulla versione del BIOS disponibile e selezionare “Leggi tutto” (Read More) sotto la voce Informazioni importanti (Important Information)
• Cercare la dicitura esatta: “This BIOS contains the new 2023 Secure Boot Certificates”

La presenza di questa frase conferma che i certificati sono integrati nell’aggiornamento.

HP

I PC HP rilasciati nel 2024 e successivi includono già la nuova CA nelle variabili EFI, per quelli precedenti, ma non ancora fuori ciclo vita (EOSL), è possibile aggiungerla mediante un aggiornamento del BIOS e per quelli non più supportati HP sta sviluppando un metodo di patching manuale per i sistemi operativi Windows client.
Quando il PC HP è pronto per proseguire con l’aggiornamento delle variabili EFI live, mediante Windows Update, l’output del seguente comando include la stringa SBKPFV3:

(Get-CimInstance -ClassName Win32_ComputerSystemProduct).Version

Se quella stringa non è presente, Windows non proverà ad eseguire l’aggiornamento delle variabili EFI in autonomia, però sarà comunque possibile forzarlo, a proprio rischio e pericolo, modificando la chiave di registro AvailableUpdates.
HP ha annunciato che non rilascerà un aggiornamento per la revoca della CA 2011 mediante DBX e sconsiglia di effettuare questa operazione manualmente.

Lenovo

Lenovo non fornisce una data dopo la quale i PC rilasciati ospitano già la nuova CA nelle variabili EFI, però fornisce una tabella che in base al modello indica la versione minima del BIOS richiesta.
La tabella è disponibile al seguente link: https://support.lenovo.com/us/en/solutions/HT518129

SERVERS

Prefazione

Analogamente a come avviene per i PC, mediante l’aggiornamento del BIOS è possibile aggiornare le variabili EFI di default dei servers della maggior parte dei produttori.
Molti produttori consentono l’iniezione manuale o mediante API dei certificati nelle variabili EFI, questa procedura è consigliata se non è disponibile un aggiornamento del firmware ufficiale.
Sui servers si raccomanda una maggiore cautela durante la revoca dei certificati, specialmente se non sono disponibili service pack recenti che includono gli aggiornamenti del firmware, poiché è più facile rompere la catena di fiducia rispetto che sui PC dove si trovano drivers più standard.

HPE

Per i server HPE, analogamente a come è avvenuto per gli altri produttori, sono stati rilasciati i service pack con l’aggiornamento del firmware per la transizione alla nuova catena di fiducia.
Inoltre, è possibile iniettare i nuovi certificati mediante le API Redfish delle iLO, nel caso in cui non si possa procedere con l’aggiornamento del firmware si debba procedere massivamente.

Aggiornamento delle variabili live e della firma del boot loader

Linux

Aggiornamento delle variabili live

Le variabili live su Linux vengono gestite diversamente in base a se si tratta di una macchina fisica o virtuale e nell’ultimo caso il comportamento varia in base al hypervisor.
Generalmente se non vengono modificate durante l’aggiornamento del firmware (o dell’hardware virtuale), ma le variabili di default risultano corrette, è possibile procedere dal BIOS al reset delle chiavi EFI, per far sì che esse vengano memorizzate in NVRAM sovrascrivendo le attuali variabili live.
In alternativa, è possibile provare ad aggiornarle eseguendo i seguenti comandi:

apt-get install -y fwupd
fwupdmgr refresh
fwupdmgr get-updates
fwupdmgr update

Come ultima spiaggia, se non sono presenti aggiornamenti firmware, è possibile iniettarle manualmente impostando il Secure Boot in modalità Setup Mode o Delete PK ed applicando a mano il file EFI Signature List (.esl).
Prima di procedere è necessario installare il pacchetto efitools, su Debian eseguire:

apt-get install -y efitools

Per applicare a mano la patch di DB eseguire:

efi-updatevar -a -f EFI_Signature_List_DB.esl db

Analogamente, per applicare a mano la patch di DBX eseguire:

efi-updatevar -a -f EFI_Signature_List_DBX.esl dbx

Se viene mostrato un errore simile al seguente, significa che non si ha autorizzato dal BIOS la modifica delle variabili EFI:

Failed to update db: Operation not permitted

Aggiornamento della firma dello shim

Su Linux è necessario mantenere aggiornato il pacchetto shim-signed o shim-x64 affinché la nuova CA venga aggiunta tra le autorità emittenti dello shim.
In alcuni sistemi è possibile che nonostante il Secure Boot sia abilitato, il pacchetto sia mancante, in questi casi è necessario installarlo.

Su Debian eseguire:

apt-get install -y shim-signed

Su RHEL eseguire:

dnf install -y shim-x64

Dal momento che il pacchetto viene installato sarà sufficiente installare gli aggiornamenti medianti package manager per mantenere la firma dello shim aggiornata.

Windows

Windows mediante Intune

Microsoft mediante Intune mette a disposizione tre policies per rimediare al problema della scadenza dei certificati:

Se si volesse procedere con l’aggiornamento delle variabili EFI mediante rollout automatico con Windows Update sarebbe importante assicurarsi di non aver configurato la policy Configure High Confidence Opt-Out o di averla configurata disabilitata.
Tutte le tre policies sono raggruppate nella stessa categoria, per configurarle recarsi sul portale Microsoft Intune, navigare su Devices, selezionare Windows e nella sezione Configuration, dopo aver cliccato su Create, selezionare New Policy:

Nel menù laterale selezionare la piattaforma Windows 10 and later ed il tipo Settings catalog, poi cliccare su Create per proseguire:

Assegnare un nome significativo alla policy e proseguire cliccando su Next:

Cliccare su Add settings, cercare Secure Boot e selezionare le policy desiderate.
Policy per il rollout automatico gestito da Microsoft (Configure Microsoft Update Managed Opt-In):

Policy per il rollout controllato dagli amministratori IT (Enable SecureBoot Certificate Updates):

Proseguire cliccando su Next, opzionalmente assegnare uno Scope tag e proseguire nuovamente cliccando su Next:

Nella schermata successiva è possibile assegnare la policy ad uno o più gruppi ed eventualmente prevedere delle esclusioni:

Dopo aver cliccato su Add groups è possibile selezionare il gruppo desiderato:

Proseguire cliccando su Next ed infine confermare cliccando su Create:

Aprendo la policy, cliccando su View report è possibile visualizzare il report per verificare su quali dispositivi è stata applicata:

Quando la policy viene applicata con successo viene mostrata la dicitura Success in prossimità del dispositivo che l’ha applicata:

Invece, in caso di errore, viene mostrata la dicitura Error in prossimità del dispositivo su cui la policy ha fallito:

Cliccando il nome del dispositivo viene mostrato il numero di errore:

Il codice 65000 indica un errore del CSP (Configuration Service Provider).
In ambienti virtualizzati come Proxmox, questo errore potrebbe venir causato dal firmware (OVMF) che blocca la scrittura delle variabili da parte del sistema operativo guest, poiché la gestione è delegata all’hypervisor.
Dopo qualche ora che la policy viene applicata ed il dispositivo viene riavviato, lo stato del certificato per il dispositivo sul report del Secure Boot cambia da Not up to date a Up to date.
Prima (Not up to date):

Dopo (Up to date):

Windows mediante GPO

In assenza di Intune, la distribuzione dell’aggiornamento può avvenire mediante GPO.
Queste policy operano secondo il principio del Desired State: il valore nel registro viene imposto in modo persistente (Registry Tattooing) e non viene rimosso automaticamente dal sistema operativo nemmeno a operazione conclusa.
Inoltre, su Intune le policies sono state tutte raggruppate in un’unica categoria, invece le GPO richiedono che venga abilitato l’aggiornamento degli altri prodotti Microsoft mediante una policy aggiuntiva (Windows Update for Business), che agisce sull’agente di Windows Update.
Infine, se si utilizza il WSUS (deprecato) è necessario assicurarsi che le classificazioni Updates e Security Updates siano sincronizzate e che non ci siano patch da approvare.

Di seguito una tabella riassuntiva delle policies:

Di seguito dove trovare le categorie interessate:

Aprire lo snap-in Group Policy Management, selezionare Group Policy Objects, effettuare click destro e cliccare su New:

Assegnare un nome alla policy e confermare cliccando su OK:

Selezionare la nuova policy, effettuare click destro e cliccare su Edit:

Navigare ai rispettivi percorsi indicati nella tabella precedente per configurare le policies.
Ad esempio, se si volesse configurare la policy per il rilascio immediato nella categoria Secure Boot bisognerebbe configurare come segue:

Inoltre, sarebbe necessario abilitare l’opzione Install updates for other Microsoft products nella policy Configure Automatic Updates:

È probabile che l’organizzazione abbia già configurato la policy nell’immagine precedente per gli aggiornamenti automatici, in questo caso è necessario abilitare l’opzione indicata in quella policy.
Se invece si utilizzasse la policy Certificate Deployment via Controlled Feature Rollout, per il rilascio controllato, essa richiederebbe che venga abilitata la telemetria required:

Dopo aver configurato le opzioni desiderate, selezionare la OU alla quale la si vuole assegnare, effettuare click destro e cliccare su Link an Existing GPO…:

Selezionare la policy e confermare cliccando su OK:

La rimozione della GPO non comporta la pulizia automatica del registro.

Windows mediante chiavi di registro

Se non sono disponibili strumenti di gestione remota come Intune e le GPO, è possibile intervenire direttamente sul registro.
Tutti i valori delle chiavi presenti delle seguenti tabelle riassuntive sono di tipo REG_DWORD.
Tabella riassuntiva per la chiave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot:

Per il rilascio immediato delle patch per il Secure Boot si consiglia di impostare il valore 0x5944 della chiave AvailableUpdates.

RISOLUZIONE DEI PROBLEMI

Analisi del registro

Quando viene configurata la policy di Intune per l’aggiornamento automatico, la chiave AvailableUpdates viene impostata a 0x5944, nelle fasi successive la chiave viene decrementata dei valori bitmask delle rispettive fasi, ad esempio il valore 0x4400 significa che gli aggiornamenti di DB, KEK e della firma del boot loader sono conclusi con successo e che è necessario procedere alla modifica di DBX (revoca).
Il valore della chiave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing chiamato UEFICA2023Status descrive lo stato dell’aggiornamento mediante delle stringhe (più user friendly delle bitmask):

• NotStarted
• InProgress
• Updated

Sempre la stessa chiave, nella fase InProgress, memorizza i valori chiamati UEFICA2023Error e UEFICA2023ErrorEvent che riportano rispettivamente il codice ed il numero dell’evento del primo errore che è stato riscontrato durante l’aggiornamento della CA 2023 (se non si è concluso con successo o se è richiesto un riavvio).
Inoltre, essa memorizza anche i valori chiamati BootMgrLastUpdateError e BootMgrLastUpdateErrorReason che riportano il codice e la ragione del primo errore che è stato riscontrato durante l’aggiornamento the Boot Manager (boot loader).
Durante la fase InProgress potrebbe essere richiesto un riavvio manuale, dato che l’aggiornamento delle variabili EFI non scatena il riavvio automatico del dispositivo.
Situazione del registro prima dell’aggiornamento:

Situazione del registro durante l’aggiornamento:

Situazione del registro dopo l’aggiornamento:

In questo caso il PC non ha ancora revocato la CA 2011.

Analisi dell’Event Viewer

Mediante l’Event Viewer è possibile consultare i logs di sistema per capire in che fase dell’aggiornamento si trova il PC ed analizzare le cause di eventuali errori.
Aprire l’Event Viewer, navigare su Windows Logs > Service e selezionare Filter Current Log…:

Filtrare mediante Event Source impostandola su TPM-WMI:

Di seguito una tabella riassuntiva degli eventi: