Distribuire il certificato client SCCM sui PC Windows

Per distribuire un certificato client SCCM sui PC Windows non basta importare un file .pfx: serve decidere dove termina la fiducia, quale template emette il certificato, come il client lo recupera e in che punto la console o il deployment lo usano per autenticarsi verso i ruoli di Configuration Manager. La parte che crea più errori, in pratica, è quasi sempre la stessa: il certificato è valido ma non viene scelto dal client, oppure viene emesso con EKU o subject non compatibili con il metodo di autenticazione configurato.

In ambito SCCM il caso più comune è il client certificate usato per HTTPS o per autenticazione mutua verso Management Point, Distribution Point o altri ruoli esposti in modalità sicura. La regola operativa è semplice: prima si definisce l’identità del dispositivo, poi si abilita la richiesta del certificato, infine si verifica che il client lo presenti davvero nel contesto corretto. Se salti questo ordine, finisci a inseguire errori generici nei log con un certificato che “esiste” ma non viene mai selezionato.

Scelta dell’architettura: certificato per macchina, non per utente

Per i client Windows gestiti da SCCM, nella maggior parte degli scenari il certificato deve essere installato nel Computer Store, non nello store utente. Questo vale sia quando lo distribuisci via GPO sia quando lo ottieni tramite autoenrollment da Active Directory Certificate Services. Se il certificato finisce nello store sbagliato, il client non lo trova quando il servizio di Configuration Manager avvia la negoziazione TLS.

Il requisito minimo da controllare nel certificato è quasi sempre questo: Client Authentication EKU, chiave privata presente, soggetto o SAN coerenti con la strategia di enrollment, e catena di trust valida fino alla CA radice o intermedia. Se usi SCCM in HTTPS, il certificato deve essere compatibile anche con il modo in cui il sito identifica i client: per alcuni ambienti bastano criteri basati su subject/SAN; in altri conviene usare template dedicati e gruppi AD ben definiti per limitare l’emissione.

Prerequisiti lato CA e Active Directory

Se la tua infrastruttura usa Microsoft AD CS, il punto di partenza è il template. Duplica un template esistente per computer e imposta parametri espliciti, invece di lavorare sul template “Computer” standard. In questo modo separi i client SCCM dagli altri usi e riduci l’effetto collaterale di policy troppo generiche.

Controlla questi elementi prima di distribuire:

• Template con Client Authentication tra gli EKU.
• Permessi Enroll e, se serve, Autoenroll concessi al gruppo AD corretto.
• Chiave privata esportabile solo se hai un motivo operativo preciso; in produzione è meglio evitarlo.
• Subject name costruito da AD o da policy coerente con l’identità macchina.
• Catena CA distribuita ai client tramite GPO o trust già presente.

Se il template è mal configurato, il sintomo non è sempre “errore esplicito”. A volte il certificato viene emesso ma il client lo rifiuta perché manca l’uso previsto o perché il nome non soddisfa il controllo di matching. In pratica, il problema emerge quando Configuration Manager deve scegliere il certificato per autenticarsi e trova più certificati, nessuno dei quali è davvero adatto.

Distribuzione via Group Policy: la via più pulita per i computer domain-joined

Per PC Windows membri di dominio, la distribuzione via Group Policy è spesso la soluzione più lineare. Il vantaggio è che il certificato arriva nel computer store con il contesto corretto e senza dipendere da script custom o azioni manuali sui client. Se la tua organizzazione ha già AD CS, questa è di solito la strada con meno manutenzione nel tempo.

Il flusso tipico è questo:

1. Pubblica il template sulla CA.
2. Concedi i permessi di enroll al gruppo AD dei computer target.
3. Abilita l’autoenrollment via GPO per Computer Configuration.
4. Forza l’aggiornamento policy sui client.
5. Verifica la comparsa del certificato nello store macchina.

La policy si abilita in:

Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client - Auto-Enrollment.

Impostala su Enabled e attiva le opzioni per renewal, update e revocation. Dopo la replica della GPO, sul client esegui:

gpupdate /force

e poi verifica lo stato di autoenrollment con:

certutil -pulse

Se il certificato non compare, il primo controllo utile non è SCCM ma il log di enrollment del sistema. I riferimenti più pratici sono il Visualizzatore eventi sotto Applications and Services Logs → Microsoft → Windows → CertificateServicesClient → AutoEnrollment. Lì vedi se il client sta chiedendo il certificato, se la CA risponde e se c’è un rifiuto sul template.

Verifica del certificato sul client Windows

Dopo l’enrollment, controlla la presenza del certificato nel Computer Personal store. La verifica più rapida da shell è:

certutil -store my

Il risultato deve mostrare il certificato con il subject atteso, la chiave privata associata e l’EKU corretto. Se vuoi isolare un certificato specifico, puoi cercare l’impronta o il subject nel report. Il punto importante è che il certificato sia sotto Local Computer\Personal, non nel profilo utente.

Un controllo più visivo si fa con la console MMC:

1. Apri mmc.exe.
2. Aggiungi lo snap-in Certificates.
3. Seleziona Computer account.
4. Vai in Personal → Certificates.

Qui devi vedere il certificato con il simbolo della chiave privata. Se manca, il problema è a monte: enrollment incompleto, template errato o chiave non generata correttamente. Se è presente ma SCCM non lo usa, allora il problema è quasi sempre di selezione o di binding lato client.

Collegare il certificato al client SCCM

Il client Configuration Manager usa il certificato secondo criteri interni di selezione. In generale, se il client è in modalità HTTPS o mixed mode con requisiti di autenticazione, cerca un certificato macchina valido con la catena corretta e l’uso client authentication. Se ne trova più di uno, l’ambiguità può creare comportamento intermittente: un reboot o un renewal cambia quale certificato viene scelto.

Per questo conviene evitare template troppo aperti. Un template dedicato al parco SCCM dovrebbe avere:

• nome leggibile e stabile;
• validità coerente con la policy di rinnovo;
• subject costruito da AD o da regole prevedibili;
• EKU limitati al necessario;
• permessi solo ai gruppi realmente autorizzati.

Se stai usando PKI per client authentication verso Management Point in HTTPS, verifica anche che il certificato del server sia a posto e che il client si fidi della CA che lo ha emesso. Un client certificate perfetto non risolve una catena server rotta o un nome DNS non coerente con il certificato del server.

Diagnostica SCCM: i log che contano davvero

Quando il certificato è installato ma il client continua a non registrarsi o non autenticarsi, passa subito ai log di Configuration Manager. I file più utili, sul client, sono in genere sotto C:\\Windows\CCM\Logs. I nomi che contano di più dipendono dallo scenario, ma questi sono i primi da leggere:

• CcmMessaging.log per la comunicazione con i ruoli SCCM.
• ClientIDManagerStartup.log per registrazione e identificazione client.
• LocationServices.log per discovery dei ruoli e boundary.
• CertificateMaintenance.log se il client gestisce rinnovi o selezione certificati.

Se il problema è TLS o autenticazione, cerca errori come certificato non trovato, catena non valida, subject non accettato o handshake fallito. Il valore operativo non sta nel singolo messaggio, ma nel punto del flusso in cui si interrompe: prima del discovery, durante la registrazione, o quando il client prova a parlare con il Management Point.

Un controllo utile lato Windows è anche il registro eventi del sistema e del servizio SMS Agent Host. Se il servizio è attivo ma non completa il bootstrap, spesso il certificato è solo una delle cause; possono entrare in gioco DNS, boundary group, proxy o firewall. Non fermarti al certificato se il client non risolve correttamente il nome del site server.

Distribuzione con script o PowerShell: utile, ma solo se hai un motivo

La distribuzione via script ha senso quando non hai dominio, quando devi gestire un parco misto o quando il certificato arriva da un canale esterno e va importato localmente. In quel caso il file .pfx può essere installato nel computer store con PowerShell, ma devi trattare la password come segreto e non lasciarla in chiaro in script o task scheduler.

Un import standard, da eseguire con attenzione, è questo:

Import-PfxCertificate -FilePath